#dimas-priyanto_api
dreamy coralBOT
đ 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/1390160381716070530
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- dimas-priyanto_api, 7 hours ago, 4 messages
wanton rune
hello! Can you share an example PaymentIntent with a saved card that failed?
fossil rock
I'm using Ruby.
` def create_payment_intent(user:, provider_id:, amount:, language:, item_type: nil, resource_id: nil, off_session: false)
payment_methods = Stripe::PaymentMethod.list({
type: 'card',
customer: provider_id,
})
first_payment_method = payment_methods.data.first.id
# item_type present on first time purchase (submit credit card)
if off_session == false
pp "ON SESSION"
payment_intent_params = {
customer: provider_id,
amount: amount,
description: "USER_ID: #{user.id}",
currency: Settings.stripe.currency[language],
capture_method: 'manual',
payment_method_types: ['card'],
return_url: Routes.stripe_3ds_callback_url(item_type: item_type, resource_id: resource_id),
payment_method: first_payment_method,
confirm: true,
use_stripe_sdk: false,
off_session: false,
payment_method_options: {card: {
request_three_d_secure: 'any',
setup_future_usage: 'off_session'
}}
}
else
pp "OFF SESSION"
payment_intent_params = {
customer: provider_id,
amount: amount,
description: "USER_ID: #{user.id}",
currency: Settings.stripe.currency[language],
capture_method: 'manual',
payment_method_types: ['card'],
payment_method: first_payment_method,
confirm: true,
off_session: true,
}
end
payment_intent = Stripe::PaymentIntent.create(payment_intent_params)
pp payment_intent
payment_intent
end`
The ON_SESSION condition is when first saving the card. And OFF_SESSION when charge with saved card.
wanton rune
I'll need an example PaymentIntent id to take a closer look. the PaymentIntent id has the prefix pi_
fossil rock
Okay. Please wait..
This one created with 3DS required card 4000000000003220 pi_3Rgd94GuQq5yqGU507JNVXe0
wanton rune
that's a test card right? Can you share an example PaymentIntent id which failed in production
fossil rock
Okay, please wait..
Can't it be analyzed by pi_ from testing environment?
So, we're no migrating to Stripe::PaymentIntent from traditional Stripe Charge.
we're now
wanton rune
you mentioned that your live payments are failing, there's really no point in analyzing a test payment
fossil rock
While we're still testing in development environment, saved card with 3DS required cards are unable to charge user via off_session.
wanton rune
sorry, I'm a bit confused, is the issue you're facing in test or in prod right?
fossil rock
Okay sorry, let me explain:
- We have saved cards with old Stripe charge api.
- There's an announcement that starting June 30, 2025 we should move to Payment Intent and enabled 3DS (SCA)
- So we migrated to Payment Intent api, with exception to 3DS cards
Right now, in production we are not accepting 3DS cards, because when testing in development environment, we couldn
couldn't charge with setup_future_usage card, via off_session=true parameter
So, we are not saving pi_ of 3DS cards right now.
wanton rune
i see. Anyway, pi_3Rgd94GuQq5yqGU507JNVXe0 which you shared earlier is not an off-session payment. Can you find and share a PaymentIntent that is an off-session payment which failed as per what you described
fossil rock
Okay. So, my implementation was incorrect?
From code snipped i shared earlier.
- First time created pi_ is using off_session=false and set setup_future_usage=:off_session.
- Second time when tried to generate pi_ it is using off_session=true
- Step no 2 returned execption with code authentication_required
So, i couldn' t produce the off_session pi_.
wanton rune
I'm asking for an example PaymentIntent for step 2
That PaymentIntent you shared with me, didn't fail, it was successfully authorized : https://dashboard.stripe.com/test/payments/pi_3Rgd94GuQq5yqGU507JNVXe0 - this looks like it is from step 1
fossil rock
I'm asking for an example PaymentIntent for step 2
I'm asking for an example PaymentIntent for step 2
When tried to generate PaymentIntent for step 2, the code block above raises an execption with code authentication_required, so the PaymentIntent for step 2 is not being generated.
In other words, i couldn't generate PaymentIntent with:
payment_intent_params = { customer: provider_id, amount: amount, description: "USER_ID: #{user.id}", currency: Settings.stripe.currency[language], capture_method: 'manual', payment_method_types: ['card'], payment_method: first_payment_method, confirm: true, off_session: true, } payment_intent = Stripe::PaymentIntent.create(payment_intent_params)
Because saved card is 3DS card, and it seems that it couldn't be used via off_session=true.
wanton rune
okay, gimme a second to take a look
fossil rock
We collected user payment info one time, and next charge didn't require user to re-input the payment info.
So, we didn't perform 3DS authorization, and charge user from backend instead using parameter off_session=true.
Please confirm of this statement correct:
Saved cards authorized with 3DS, could not be used with off_session=true.
We only perform 3DS authorization first time user made a purchase, and second time onwards, we charge them from backend.
Please do not close this channel until our problem resolved, i may away for a while and not responding.
wanton rune
we will close the channel after a while if you don't respond
Let me use this request as an example : https://dashboard.stripe.com/test/logs/req_al3LJFijqr7MfQ - this one failed with authentication_required - when I look at the test card you are using, you're using the 3220 test card which always requires authentication.
fossil rock
Okay, then i'll be standing by responding.
wanton rune
3220 is not the test card that you should be testing with. You should try with the test card ending with 3155 : https://docs.stripe.com/testing#authentication-and-setup
fossil rock
Okay. In production, is it common for a credit card that always requires authentication?
wanton rune
probably not common. Regardless, you should always be prepared to bring your customer back on-session to make payment if the off-session payment fails with authentication_required
fossil rock
In the case of card type like 3220, we have no other option than to reject the card?
Since we couldn't use it via off_session.
Please advise.. In other words, our system requires cards that could be charged via off_session.
wanton rune
like what I mentioned, you should always be prepared to bring your customer back on-session to make (attempt) payment if the off-session payment fails with authentication_required
there is no guarantee that payment is always successful, there's always the possibility that a payment might fail for various reasons and your application needs to be able to handle such scenarios e..g reaching out to the customer to inform them that payment has failed and to request that they come back on-session to make payment and/or use a different card for payments