#gregers-Subscription
1 messages ยท Page 1 of 1 (latest)
The real root of the problem is that the incomplete subscription will be cancelled within 23 hours. Perhaps there is a way to disable this behaviour?
Hi, give me a few mins to catchup
Thank you! LMK if I can provide any additional context here ๐ '
Hi there, I believe incomplete is a new status made specifically for SCA, and it represents the first state of Subscription. I don't think there is a way to make it "unpaid" by default.
But before that, how problematic with it in your system?
You want to extend the 23 hours?
Yea ideally extend it indefinitely
We have an existing system which handles delinquent invoices. The idea is to use that to handle cases where a user triggers SCA and then later bounces
The concern is basically that if the subscription expires then our system will think they have a subscription when in fact the user does not
One idea I was considering for example was if we generated an invoice using upcoming (for the initial payment), then created the subscription with a different billing anchor (1 month in advance)
This would de-couple the initial invoice SCA behaviour from the subscription status... but ofc this is kinda hacky
I am afraid this 23 hours is by design
Customers have about 23 hours to make a successful payment. The subscriptions remains in status incomplete and the invoice is open during this time. If the customer pays the invoice, the subscription updates to active and the invoice to paid. If they donโt make a payment, the subscription updates to incomplete_expired and the invoice becomes void. This window exists because the customer usually makes the first payment for a subscription while on-session. If the customer returns to your application after 23 hours, create a new subscription for them.
With that said, to your scenario I feel that you can use SetupIntent to track the SCA process, then based on the result, decide to create Subscription later on
Ok cool did see that and thought it interesting.. let me take a closer look at that
I guess if SetupIntent does work we are basically guaranteed not to need SCA for the subscription payment right?
I see the use case was more specifically for when the first payment is expected to be off-session (Eg a trial) but we figure it could apply here eh?
It could, yes. SetupIntent is to separate the first Payment, and the Subscription creation. And in your case first Payment required SCA
Ok great this makes a lot of sense! Ty I'll take a closer look and might follow up with a question or two ๐
Sure!
Just seeing this reference: https://stripe.com/docs/payments/save-and-reuse?platform=web#web-test-the-integration
There is this scenario:
The card requires authentication for the initial setup and also requires authentication for subsequent payments.
I guess this ofc implies that even with setup intents there are no guarantees the customer will be shielded from subsequent SCA requirements
Just reduces the likelyhood I imagine right?
yes, because that's ultimatedly controlled and regulated by issuer bank
I believe it's not the common case
but issuer banks still hold the right to request 3DS whenever they want
Yea I guess we're talking corner case of corner case
Or not they wanted, but they are required by local law enforcement etc
Makes sense
So generally Stripe is telling merchants, to make their system resistant to SCA, meaning your system need to be able to handle SCA requirements whenever it happens
And we provide the test card to simulate the scenarios
So ultimately we will need to figure out this new subscription case to have the last line of defense
OK so I think it circles back to the original question then but I'll try to think of a more helpful way to ask it ๐ค
I am stepping down for the day. If you comes back feel free to post question to main channel, or request to unlock this thread and my colleagues should be able to continue assisting you!