#r.soares
swift raft
Hi there. Let's chat in this thread
First, can you paste the setupintent id in here? Just so I can access it easily
oak citrus
seti_1WwBiK9PS1qRjzzQNju6TdZ
gaunt badgerBOT
oak citrus
That's an old one, if you cant find it i can create a new one
fair edge
👋 hopping in here - the output from your first screenshot is from a setupintent (which was successful), but the screenshot is for a payment intent
and you used the 3155 test card for this, right?
If that's the case, then the reason this failed is because we require you to pass in off_session: true for the future payments you're using it for
oak citrus
i tested with all the cards, all same result, even the one that does not require 3DS
Yes off_session is set to true
Keep in mind the integration is working fine in live mode, this only happens in test mode
fair edge
Do you have an example where this isn't working for the 3DS card?
also to clarify - when I say you need to set off_session: true I mean you need to pass it in when you create the subscription. If you look at your reqeuest req_oixA9dP3begj1C that's creating a subscriptoin I don't see off_session: true passed in
oak citrus
Its the default value
i created a more recent customer: cus_OLCz6WAy8AKdBq
intent: seti_1NYWYxK9PS1qRjzzlHLuU5eI passed 3DS
payment: pi_3NYWZTK9PS1qRjzz1iXT0MZM failed due to 3DS
fair edge
That one I still don't see you passing in off_session: true for the subscription creation
oak citrus
Kk, adding off_session parameter works, dont understand why it beahaves different from live env.
So now im back to my initial problem, when adding a subscription item its fails payment because 3ds too
i tried the same off_session trick, but thats not a parameter for SubscriptionItem
si_OLDGFhq5tKlfRX
fair edge
Do you have the request ID for where you added the subscription item?
and to explain why it behaves differently in live vs test mode - our test cards are meant to behave in very specific ways. The 3155 test card specifically tests scenarios where you'd set up the card for futureu usage and only test this out for off_session charges later
In live mode, a lot of real cards that you set up would be fine to use for off or on session usage in the future, so it looks like it "just works"
oak citrus
Where can i find the request ID ?
The si ID is the only thing it returns on creation
fair edge
no worries, I was able to find it from your subscription ID
Yeah, I didn't realize we didn't have an off_session param for subscription items so that won't work
oak citrus
yeah, and when you create a subscription you have the pending_updates too, not in here so 3DS cannot be triggered here
If it helps, this is the current call
fair edge
Backing up here for a minute - what are you really trying to do? Are you just trying to get your testmode request to behave the same as in live mode? Are you trying to model something specific?
oak citrus
Im trying to add a new product to an subscription
This one i cannot replicate in live mode has i cant get past implementation in test mode, payment always fails
fair edge
So you're just trying to test this out in test mode once to make sure it works?
All you'd need to do is use a 4242 card to test this out really
oak citrus
It failed in the past with 4242, but let me try again
fair edge
Yeah with the 4242 card it should definitely be working, so if it's not I'd love to see an example
fair edge
Hm... interesting - give me a few minutes to dig in
oak citrus
Sure
fair edge
Ahh... I think I see what's happening - you have a 3DS radar rule that triggers when Request 3DS if :card_country: != :ip_country:
THe 4242 test card has a country code of US so if you're testing it from a diferent country that would explain why 3DS is being triggered
oak citrus
Afff.. really 😅 kk let me test, 2mins
fair edge
If you need a card from a specific country we have a pretty long list of available test cards here as well https://stripe.com/docs/testing#europe-and-middle-east
oak citrus
Nop, disabled the rule still same thing
sub_1NYXSEK9PS1qRjzzYcivdTUs -> si_OLDvsYaBJgVVO1
fair edge
Try disabling the 3DS is supported for this card rule as well
oak citrus
Kk, but is that just a test mode thing or in live too ??
fair edge
Ah that's fair - it would disable it in live mode as well
oak citrus
It worked though 😅 but that would mean disabling it in live mode too
The wierd thing is if i use Subscription::Update to increase quantity this 3DS thing doesnt happen
The payment goes trough no problem, is just the SubscriptionItem that refuses to function
fair edge
Is that something you're only seeing in livemode? OR also in test mode?
oak citrus
Subscription::Update is working fine on both envs.
fair edge
Are you passing in anything different with the update requests?
Just to back up for a minute here and clarify something - 3DS is always something that can be requested for a payment, even if the card was setup for future usage
The card issuer can choose to reject the exemption we request and still require authentication for the card
oak citrus
Those are too different endpoints, SubscriptionItem::create doesnt accept same parameters
fair edge
Yeah but they have some commonality - like are you passing in the same thing for proration_behavior?
oak citrus
pi_3NYXdbK9PS1qRjzz0zRac3bj same subscription i updated the qnt for 3 and payment went through fine
Yes, proration_date is just current time
fair edge
That's a really recent request though right (after you've turned off the 3ds rules that were forcing it to be requested)? So it's expected that it should go through and 3DS isn't needed
I'm guessing if you turn on those rules you had earlier then 3ds would also be requested for those subscription update requests
oak citrus
Nah, it happen in the past too
gaunt badgerBOT
oak citrus
I can create new subscription with the rule on if it helps
fair edge
Yeah that would help
oak citrus
Kk
fair edge
and just do the subscription update on it - don't make any requests on a subscriptoin item beforehand
oak citrus
K
Well atleast now its consistent in failing, both cards 4242 and 3155 fail because of 3ds on Subscription::update
fair edge
that's good! I was a bit worried there for a minute
oak citrus
But im sure it worked in the past, but i dont have the old test customers in dashboard anymore, maybe the off_session is making the trick
fair edge
yeah there could've been a lot of different things causing the behavior to be different - if you see it pop up again definitely keep that request ID and flag it to us here
oak citrus
Kk, but now subscription::update also fails even with 3155 card requesting the 3DS again
fair edge
Do you have the reqeust ID for that one? Are you passing off_session: true in the subscription update request?
oak citrus
yeah, same code, have the payment intent: pi_3NYY1gK9PS1qRjzz06uNKRI4
fair edge
Ah, are you only passing off_session: true for the creation request? You need to be passing it for every request that you want to flag as "off-session"
If you're not also passing it for the update call, then that would be why 3DS Is still needed for the update payment
fair edge
Interesting, didn't realize we don't allow you to set it for pending if incomplete updates
oak citrus
But this is new beahviour, when i made the integration back then everything worked fine 😅 still does in live mode, but its confusing, we dont know if it will work or not when live
fair edge
Really this is all still working as expected - needing 3DS again is something that's expected to happen from time to time, and the test cards are just modeling those scenarios
It's just that you don't have a specific test card that models the exact thing you want - we don't have a test card that models you setting it up for 3ds in a setup intent and then future on-session payments are exempted
oak citrus
How can it be, if the endpoints have no way to deal with that situation ?
the 3155 card should work and it doesnt, has per description it requires setup once and wont ask for future 3ds and that is not happening
instead the endpoints are returning successful replies but in the dashboard the payments arent completed
nothing in this makes sense
fair edge
Yeah let me back up
Just because you set up a card with a setup intent initially and request 3DS doesn't mean that it'll always be exempted in the future. The card issuer/bank can always choose to still require it later on, so your integration needs to be resilient to that and have a built in system that can bring the customer
oak citrus
OK, can you please guide me how to do that on a SubscriptionItem ?
Because the object doest return pending_updates like subscription::create/update
Can you also please explain why the API is returning successfull answers instead of pending updates ???
All the update quantities that failed because of 3DS didnt return any pending update
fair edge
That's how pending updates work - if payment fails we populate the pending_update hash and give you 23 hours to complete the payment before expiring the update https://stripe.com/docs/billing/subscriptions/pending-updates#handling-failed-payments
oak citrus
Can you tell me where to find pending_update on a Subscription::update response, same for SubscriptionItem::create ???
fair edge
It's right here on the subscription (https://stripe.com/docs/api/subscriptions/object#subscription_object-pending_update) - for the subscription item response you'd want to expand subscription in order to see it
oak citrus
that parameter is only found in Subscription:create
no pending_update
i sent you the images with the full response from the failed SubscriptionItems, theres no pending_update
fair edge
Yeah that's why I said you need to expand subscription
untold shoal
Hello! I'm taking over and catching up...
oak citrus
The only way to check if the update was successful is by checking the invoice, subscription:update does not return pending_update
@untold shoal hello
untold shoal
In that code, you should be able to access $subscription_update->pending_update to see the details of the pending update when the payment fails.
The pending_update property is only on Subscriptions, not Subscription Items.
oak citrus
So that solves half the problem xD
untold shoal
What's the other half?
oak citrus
SubscriptionItems payment fails because of 3DS
untold shoal
I read through the conversation above and I thought that part was resolved as working as expected. Can you detail what the outustanding issue there is?
oak citrus
It works if i turn of Radar rule, request 3DS if supported
But the card 3155 description states it will only request 3DS once and thats not whats happening
4242 also fails
untold shoal
If you have the Radar rule enabled to request 3DS when it's supported that means if the card supports 3DS you're asking for 3DS to happen.
oak citrus
So why doesnt it happen in live mode ?
untold shoal
Probably because the cards in live mode don't support 3DS at all.
Are they US or CA cards? Many of those cards don't have 3DS support.
oak citrus
US, CA, UK, AU, PT, LT
On live mode everything is working has intended, and test mode was also working in the past, we didnt change anything related to payments for years and now test mode is acting like this
untold shoal
This is always how test mode and that card have behaved. The 3155 test card has always supported 3DS.
Are you certain your Radar rules haven't changed and that's the cause of the different behavior you're seeing?
oak citrus
You can check our account logs.. we have same rules since it was activated, only one we changed was country match ip address
And in almost half a decade we never had one customer unable to do anything because of 3DS
untold shoal
Can you give me a request ID or other Stripe ID showing the different behavior you were seeing earlier?
oak citrus
Which one ? i think by now we are all confused
untold shoal
If I understand correctly (and please correct me if I'm wrong!) you're saying that the 3155 test card's behavior has changed recently. I'm asking you to provide two examples, one before the change with the previous behavior, and one after the change with the new behavior so I can investigate further.
oak citrus
I would if Stripe had deleted all the old test data ???
untold shoal
Do you know when the behavior changed?
oak citrus
I only noticed this few weeks ago, so if you have access to old data you can look for subscription qnt updates
i mostly always use the card 4242 and you can see it never failed in the past
untold shoal
The logs in your Dashboard don't go back that far? https://dashboard.stripe.com/test/logs
oak citrus
Any way to filter by subscription update ?
untold shoal
Click on the API endpoint filter and try /v1/subscriptions/:id
oak citrus
I noticed this a few weeks ago, we dont use test mode since we finished implementing it..
untold shoal
Wait, I think I missed some important piece of information.
I thought you said you noticed test mode behavior changed in the past few weeks, but now it sounds like you're saying you haven't used test mode until very recently?
oak citrus
Yes
Everything is working on live for years now, only now we are implementing a new product and been facing some issues with test mode
untold shoal
So are you saying that live mode and test mode are behaving differently?
oak citrus
Correct
untold shoal
Okay, can you provide two examples that show the behavior difference? One in test mode and one in live mode?
oak citrus
Give me a moment, need to find an example in live
Is there anyway to find subscriptions by quantity ?
untold shoal
I don't think so.
oak citrus
Kk, this customer cus_I2P5WOg3CuCKWi changed quantities multiple times, all went well
Even has 2 different c.cards with setup intents
He never got asked for 3ds when updating his subscription
untold shoal
Looking, hang on...
gaunt badgerBOT
oak citrus
Sure
cus_IrbDr6qWXLmTqM
Also same thing, this one even got the request from the offending rule
untold shoal
For that first Customer I looked at their most recent payment and the rule you have that's requesting 3DS didn't apply at the time of the charge.
Usually that's due to changes with other Radar rules, allow lists, or block lists.
These are also both US cards that likely don't support 3DS anyway.
oak citrus
The last one even failed 3ds once or twice, so it must be supported
untold shoal
What would help most is if you could find a specific Charge (ch_...) from both live mode and test mode that demonstrated different behavior.
A Customer is far too broad, there's too much information to go through.
oak citrus
@untold shoal all the charges in live go through, all the charges in test mode are failing
untold shoal
Should be easy to provide two ch_ examples showing the different behavior then.
oak citrus
"Events before June 28, 2022 are not available."
"Because this event is older than 30 days old, only summary is available"
We would imagine it would be that easy but dashboard is limited ..
untold shoal
To clarify, what I mean is that if you're seeing different behavior in test mode vs. live mode today you should be able to provide two recent examples, right? Find the most recent example in live mode, then do the same thing in test mode right now.
oak citrus
The problem is searching for specific case in live
Needs to 1 have 3ds, second had made changes in the subscription
untold shoal
If you can't find an example in live mode how are you sure the behavior in the two modes is different?
oak citrus
Imagine in half a decade we dont have one customer saying they cant buy something...
Can you confirm if the first customer i sent you has a 3DS pass ?
seti_1JZZULK9PS1qRjzzL5y8ubL0
untold shoal
Yep, there was a successful 3D Secure authentication on that Setup Intent (you can see this yourself by retreiveing the associated Setup Attempt from the API). However, that was back in 2021, and 3D Secure v1 was used, which is mostly no longer supported anywhere. I'm not sure how this is relevant?
oak citrus
So since 2021 it never got asked for 3ds again, seems relevant..
in test mode i cant even create a subscription, its fails because of the supported rule
but that is fixed in test mode by passing off_session: true, which should be the deafult value anyway...
now the problem is i cant add a new product to a subscription because it fails 3DS when it should be already setup
What i need to know is how to setup the SubscriptionItem and handle the 3DS ?
waxen canyon
Well what is happening now when you modify the subscription? Do you want the update to succeed and resolve the payment later, or do you want to update to be conditional on successful payment?
oak citrus
in live or test mode ?
Sorry, you talking about only the subscriptionitems ?
Ive been at this for a few hours now...
When i create a subscriptionitem i want to be conditional on successful payment
So using this code, it always returns a subscriptionitem and i have no info of the real result
So even if 3DS is required, i cant promp the user for auth
untold shoal
Add 'expand' => [ 'subscription' ], to that and then look at $subscription_update->subscription.
oak citrus
@untold shoal theres no pending_update on a SubscriptionItem
untold shoal
Right. It's only on Subscription. So, therefore, you need to expand subscription in the response.
Which is what I told you to do above.
And what @fair edge told you to do a while ago: #1134148392176595134 message
Can you please try what we're telling you to do?
Expanding subscription when creating a Subscription Item will return the full Subscription object in the response instead of just the Subscription's ID.
You'll then be able to access pending_update on the Subscription, because you'll have the full object.
oak citrus
"This property cannot be expanded (subscription)."
If you are frustrated imagine how i fell...
So please keep it cool, thanks
untold shoal
My fault. I thought that was expandable on Subscription Items. In that case you'll need to retrieve the Subscription separately after you create the Subscription Item.
gaunt badgerBOT
oak citrus
And if the payment failed, there will be pending_update ?
untold shoal
Yes.
oak citrus
Doesnt pending update always exists ??
Thats why we are checking for last invoice, did that beaviour changed ?
untold shoal
The property always exists, but it will only be populated if there's a pending update.
Did which behavior change?
oak citrus
In the past i think pending_update was always populated with the most recent change
Theres no pending_update in the subscription
The Item isnt added to the subscription because it fails payment
untold shoal
As far as I know that behavior has always been consistent. If it changed in the past it would be a breaking change listed here, but I'm not seeing anything related to that: https://stripe.com/docs/upgrades
oak citrus
Well one of your collegues told i had to check pending invoices because of it..
But ok, let me double check the subscription pending thing
untold shoal
I am seeing a pending update on the Subscription where you most recently added a Subscription Item...
Maybe I'm looking at a different one?
Here, look at this: https://dashboard.stripe.com/test/events/evt_1NYaA4K9PS1qRjzzoOSme5SY
oak citrus
Yeah got it
untold shoal
That should confirm there's a pending update on the Subscription, and it's a direct result of you adding a Subscription Item to it.
oak citrus
was printing the subscriptionitem twice, sorry its late here
So based on that how would i go about making this payment ?
untold shoal
One sec, looking at this Invoice more closely...
Ah, okay, I was thrown off for a moment because there were multiple separate attempts to add a Subscrpition Item to this Subscription, and the subsequent attempt would override the previous pending update from the previous attempt, but I see what's going on now.
Okay, so to your question...
In a case where you create a Subscription Item for an existing Subsription and the payment fails, which results in a pending update, you need to then look at the Payment Intent attached to the latest Invoice for that Subscription to see what state it's in and handle it appropriately from there.
So in the case of sub_1NYXvpK9PS1qRjzzFG0EsjNq the latest Invoice is in_1NYaCrK9PS1qRjzzD18OQ4S1 and that Invoice's Payment Intent is pi_3NYaCsK9PS1qRjzz0RZ2XHfS and it currently has a status of requires_action.
Once that Payment Intent is successfully paid the associated Invoice will be marked as paid and that will cause the pending update on the Subscription to be applied.
Note that what I said above is no longer accurate; you created a new Subscription Item for this Subscription which voided the Invoice mentioned above and canceled the associated Payment Intent. Now there's a new latest Invoice for that Subscription (in_1NYaRlK9PS1qRjzzRcJfQtDa).
oak citrus
yeah i know
Im using
$latest_invoice = $subscription->latest_invoice; //->payment_intent->status;
$invoice = \Stripe\Invoice::retrieve($latest_invoice);
Yep. Also note that, unlike before where I was wrong (sorry again BTW), latest_invoice on a Subscription is expandable: https://stripe.com/docs/api/subscriptions/object#subscription_object-latest_invoice
And on an Invoice, payment_intent is expandable: https://stripe.com/docs/api/invoices/object#invoice_object-payment_intent
So you can expand latest_invoice.payment_intent to get both the full Invoice and Payment Intent in the response when retreiving the Subscription.
untold shoal
Hm. Can you access $subscription->latest_invoice->payment_intent->status?
untold shoal
Oh, wait, this might be the odd syntax thing... Try doing •••::retrieve(['id' => $subscription_id, 'expand' => •••]);
I'll try on my end as well...
oak citrus
PHP API doesnt like that 😛
"Invalid array"
Also tried 'expand' => 'latest_invoice' but same result
untold shoal
This works for me:
$subscription = \Stripe\Subscription::retrieve([
'id' => 'sub_123',
'expand' => [
'latest_invoice.payment_intent',
],
]);
echo $subscription;
sec
Kk, that done it
"payment_intent": {
"id": "pi_3NYaihK9PS1qRjzz1glwRrPv",
"object": "payment_intent",
"amount": 99600,
"amount_capturable": 0,
"amount_details": {
"tip": {}
},
But theres no status on the PI
untold shoal
No status? Meaning $subscription->latest_invoice->payment_intent->status doesn't exist?
oak citrus
nevermind, found it
So if required action means 3DS right ?
Or can be because other reasons ?
untold shoal
It means a next action is required, which is often, but not always 3DS.
There are other possibilities, but it doesn't matter in practice. If you handle the next action using Stripe.js we take care of whatever next action it is for you: https://stripe.com/docs/js/payment_intents/handle_next_action
oak citrus
Right, and the paymentinten returns error if payment fails or need to recheck again ?
untold shoal
Yes. The Payment Intent's status will change based on the outcome, and associated Events will fire.
oak citrus
Alright, think i got it but its late here, ill finish implementation tomorrow can we keep this open ?
untold shoal
We don't keep idle Discord threads open, but this thread isn't going to go away. You can always find it using this link: https://discord.com/channels/841573134531821608/1134148392176595134 or by searching for it. You're also welcome to ask new questions in #dev-help later if you have any.
gaunt badgerBOT