#sanderfish
pure junco
digital herald
we create the subscriptin via stripe.subscriptions.create (nodejs sdk)
coral lodge
You should avoid creating duplicate subscripitons when payment fails.
digital herald
So I should attempt to re-use the previously created subscription ID?
coral lodge
https://stripe.com/docs/billing/subscriptions/overview#build-your-own-handling-for-recurring-charge-failures this is how to handle failed payments
digital herald
that's later stage I think — preferably we'd just cancel (fail) subscriptions if the card validation fails, instead of moving to "trialing" state
coral lodge
No I don't think that's the proper way of handling failed payments
digital herald
Hm.. problem is this is a public checkout form and we do want to allow customers to start multiple subscriptions.
Currently we create the subscription, the call confirmCardPayment, which throws an error:
We are unable to authenticate your payment method. Please choose a different payment method and try again.
coral lodge
Hi! Can you share the request ID (req_xxx)? Here's how you can find it: https://support.stripe.com/questions/finding-the-id-for-an-api-request
digital herald
I believe the first 2 failed, then 3 went through. Then the customer purchased another subscription later (4)
- req_ZQERo2UsP3Av1q
- req_rE3U00uPmBTRUv
- req_xslAtpqkTG1aDd
- req_Y3wbR4ltwRobFy
but now all 4 subscriptions are in trialing state, and will be charged as a card was collected later
coral lodge
The response of first 2 requests are both 200.
And the invoice (in_1OZh8PEBIPmrEnxqQKK8qs7n) was paid successfully
digital herald
yes, the subscription creation goes through and the $0.00 invoice is "charged" as well. but no payment method is collected on the first 2 subscriptions
I'm reading this now https://stripe.com/docs/billing/subscriptions/overview#non-payment
Basically the issue is here on the right column, last card
even though the setup fails, the subscription becomes 'trialing'
coral lodge
https://stripe.com/docs/billing/subscriptions/overview#build-your-own-handling-for-recurring-charge-failures payment failure is a very comman scenario that your integraiton should handle. I'd highly recommend you go through this guide to learn how to handle it.
digital herald
We handle this already; we've been building subscription logic on top of Stripe for years. I'm specifically asking about handle subscriptions becoming 'trialing' even though the setup intent fails.
We do re-use the created subscription if user is still on session. But if the customer leaves and comes back later, they end up creating another subscription.
If the setup intent for that subscription goes through successfully, the card is stored at the customer level.
Which causes both subscriptions to be charged after trial ends.
coral lodge
Ok. I believe the doc has also provide details on how to handle this scenario, have you tried it?
digital herald
It handles everything before it (https://stripe.com/docs/billing/subscriptions/overview#authorization-failures), which we already handle. It doesn't provide details on the scenario I'm describing
coral lodge
Isn't it here https://stripe.com/docs/billing/subscriptions/overview#non-payment:~:text=To resolve these scenarios%2C call,pending_setup_intent to complete the flow. ?
digital herald
Only the positive scenario is there. In my scenario, it continues to fail and the customer leaves
idk, it's weird, Stripe manages to block these subscriptions within Stripe Checkout, there no subscription is created when 3D secure fails
maybe the issue is we're creating the subscription first and then handling the payment/setup intent?
but that's the recommended flow as per https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements#create-subscription so I'm not sure
