#guillaume3562
hexed star
gilded frigate
eternal terrace
Sure, this seems expected given that you're using the /invoices/:id/pay endpoint which doesn't support 3DS/auth flows
In this example the bankr equested 3DS/auth for the payment, but as that endpoint assumes the customer is off-session it's surfaced as a decline. You need to bring your customer on-session and re-attempt confirmation of the intent associated with the invoice so they can handle 3DS/auth
gilded frigate
It's not possible: we offer subscriptions with a free trial period of 2 days. All invoices/:id/pay call are made off_session as I specify in ruby: Stripe::Invoice.pay(@stripe_invoice.id, { off_session: true }). That's why I ensure to be compliant by having a SetupIntent with all strong authentication possible on subscription create
eternal terrace
I mean sure, you can pass off_session: true but it doesn't guarantee that it will be exempt from 3DS/auth. The bank can still request 3DS on off-session payments and your integration should handle that
gilded frigate
well it's not the expected behaviour I had for 4 years
eternal terrace
Equally, the payment you linked wasn't attempted with the payment method generated from the Setup Intent you shared so not sure how they're related
The card that was used for the payment attempt wasn't correctly setup/saved via a Setup Intent either, which is the correct way to optimise for off-session payments like this. You used the deprecated Sources API: https://dashboard.stripe.com/logs/req_3BNhPmV9AHVtN2
eternal terrace
well it's not the expected behaviour I had for 4 years
Sure, banking regulations have changed over that tine. 3DS/auth is becoming more common
gilded frigate
I understand that bank need to be precautions with off session payments, yet how do I ensure that payment succeed even on off session
the deprecated source API is the Stripe built-in hosted page
eternal terrace
I understand that bank need to be precautions with off session payments, yet how...
You can't, as I've explained already – banks can and do request auth for off-session payments. Your integration needs to be able to handle those scenarios
gilded frigate
ch_3OYaqqBIOpjLiUFV1go4owVC was insufficient_funds so I redirected the customer to the portal https://invoice.stripe.com/i/acct_XX/live_XX
I thought it would be a good idea to user hosted_invoice_url in that case
eternal terrace
Yes, the HIP (that URL) will handle any 3DS/auth requests for the payment as they're on-session at that point
When you call /pay they're considered off-session and as such a 3DS/auth request is surfaced as a decline
gilded frigate
what I understand is that, correct me if I'm wrong: HIP creates a source via POST /sources , a legacy route. After that, a webhook source_created triggers a new payment attempt in my code, with the new user default payment method. But this new payment method was not attached to a SetupIntent and thus was not treated as a valid off-session-eligible payment method
I see 2 way to solve my issue:
- Handle the declined payment myself, redirect to my own dashboard where user can add a new card with a regular SetupIntent, and then
/payagain - Stripe 'fixes' HIP to use a SetupIntent and not the legacy POST /sources route
digital iris
Hi! I'm taking over from my colleague. Please, give me a moment to catch up.
Are you sure HIP uses Sources?
digital iris
Ok, you need to reach out to Stripe Support, and they can migrate your account from Sources API to PaymentIntents on the Hosted Invoice page. Just make sure this wouldn't break anything in your app: https://support.stripe.com/?contact=true
gilded frigate
thanks will do that
digital iris
Happy to help.