#chris-m_api

1 messages · Page 1 of 1 (latest)

umbral frostBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1422607895761125508

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

naive dove
#

hi there, the request ID you provided looks like it succeeded, can you describe exactly where the problem is occurring in your flow?

prisma heron
#

Per the above, I try to pre-verify the incoming card as much as possible, and once it's begun and the first payment is collected two minutes later the Subscription status is "active" and the Invoice status is "draft".

An hour later, and the Subscription status is "past_due" and the Invoice status is "open". The associated PaymentIntent that it created is "require_action".

Had similar issues with my one-time/immediate payment workflows, but I found a workflow that handles SCA "required"/"not required" cards just as well. Haven't been able to do similar for recurring/subscriptipn-based setups.

naive dove
#

got it, so it's up to the bank when to request 3D Secure. they can do so at their discretion, including for recurring payments. if the bank requests 3D Secure, you'll need to bring your customer back to your site in order to perform the needed action. we describe how to do this here https://docs.stripe.com/billing/subscriptions/overview#requires-action

prisma heron
#

Right, I acknowledge that it's something I'm going to need to plan for. I'm trying to adapt my old workflows to pass through confirmCardSetup() as I mentioned above. But where I eventually succeeded in finding a workflow that works well for immediate/on session payments, I'm struggling to find what I set wrong for recurring/off session subscriptions.

Does the workflow I described seem fine? Any settings I mentioned wrong or missing?

umbral frostBOT
sweet mulch
#

👋 Taking over this thread, catching up now

prisma heron
#

Thank you!

sweet mulch
#

Your integration looks fine to me! It's expected that 3DS will be triggered for future invoices due to the test card (4000002760003184) being used. This test card expects authentication to be performed in every payment regardless whether the payments are off session or not. In real world, this can happen, but this is very rare. Your system should also handle the flow like this.

prisma heron
#

The client would have to come back to the system to authorize each recurring payment each time?

sweet mulch
#

Yes, this can happen (although extremely rare) that the card issuing banks require customers to authenticate the payments even for recurring payments

#

In most of the time, authentication is not required.

prisma heron
#

Right, we've been managing subscriptions and one-time payments for years, and only noticed that SCA was a thing recently, however we don't know when it could come up so we need to assume it could ALWAYS come up.

The Stripe API bot suggests this statement:

For recurring charges:

  • Most subsequent subscription charges will process without requiring customer authentication
  • Stripe automatically applies for SCA exemptions when possible (like the merchant-initiated transaction exemption)
  • However, some payments may still require authentication based on the bank's risk assessment

Should my takeaway be "You might be able to get away with not requiring SCA with every payment, but not reliably"?

sweet mulch
#

That sounds right! Ultimately, it's up to the card issuing banks to decide whether authentication is required. This is usually part of their fraud detection / prevention

prisma heron
#

I had hoped/assumed that it would be possible to verify upfront initially for the purposes of later payments, but it seems is though that's not reliably possible. Thank you for your time!

sweet mulch
#

it would be possible to verify upfront initially for the purposes of later payments
I'm afraid this might not be the case. Some issuing banks treat the risk assessment of each payment independently. Having the authentication upfront might not always work