#Wik-Sub

1 messages · Page 1 of 1 (latest)

unborn patrol
#

let me look into this in a few mins

#

Stripe does not consider this their first but second payment and though the payment failed, the subscription's status is not changed to incomplete but past_due
I would like to understand more about this part. You meant the first payment was the $0 trial one?

last gorge
#

Yes, the first payment for $0 was the trial one. User did not provide their CC details.

unborn patrol
#

I see, you used trial_end and cancel_at_period_end = true

#

yes so that's how trial works. It sounds a bit unnatural flow to me

last gorge
#

It sounds a bit unnatural flow to me
Which bit?

unborn patrol
#

Create a Sub has trial, suppose to end with trial end, but after collect PM then setting back cancel_at_period_end to false

#

But I understand because you don't want to collect CC upfront

last gorge
#

Yes

#

That is a business requirement

#

But we still need to protect ourselves from customer who are trailing and provide CC with insufficient funds

#

How can we do this?

unborn patrol
#

Would it be possible to create a trial subscription without paying for the $0 invoice? If I understand correctly, if we omit this step and user's attempt to pay is the first one, the subscription will be in incomplete state.
No you can't AFAIK. The Trial is meant to have the first $0 Invoice. I am thinking again the part of Subscription status around
though the payment failed, the subscription's status is not changed to incomplete but past_due

last gorge
#

Is there any way to suggest Stripe to set the first failed payment > 0 for trialing subscriptions to incomplete?

unborn patrol
#

Yeah that's to figure out. Do you have an example? sub_1L1OMcJA8pMPzFjlGrtKpJxZ is a succeeded one

last gorge
#

It shouldn't be. sub_1L1OMcJA8pMPzFjlGrtKpJxZ is the example of the situation I'm trying to avoid.

  1. user started a trial
  2. provided CC with insufficient funds
  3. stripe set status to past_due, while I'd like it to be incomplete
Screen_Shot_2022-05-20_at_09.43.02.png Screen_Shot_2022-05-20_at_09.43.12.png
unborn patrol
last gorge
#

Yes

#

Or rather, I'd prefer the subscription to be in incomplete state so our app knows how to process it

#

?

#

I understand it's a bit complex, just wondering if you're still there 🙂

rough lichen
#

👋 , I'm taking over for @unborn patrol, just give me a few minutes to catch up

last gorge
#

👋 sure, thank you

rough lichen
#

I have actually a workaround for you

#

basically you can have a trialing status on your end as well, and you don't change that before getting a successful payment on the first non-trial invoice (basically the second invoice)

#

in that case you could easily differentiate past_due from either a trialing subscriber or from a regular recurring customer

last gorge
#

Hm, correct me if I'm wrong but in such case, I'll have. a different subscription status in my db (trialing ) and in Stripe (past_due. Is that right?

rough lichen
#

the actual check would be before you change it

last gorge
#

I'm probably missing something, hence my confusion, but we're not setting status anywhere. We're using the status provided by Stripe.

#

I'm not using any rules to tell my API: this is active and this is past due. Instead I tell my API: use whatever it returns, it's always correct.

rough lichen
#

I mean you should compare the status you have in your db with the status coming from Stripe before updating the status

#

I'm not using any rules to tell my API: this is active and this is past due. Instead I tell my API: use whatever it returns, it's always correct.
That's why I said it's a workaround