#Zoë
1 messages · Page 1 of 1 (latest)
Is there an example pi_xxx ID I can look at?
Hey @crisp musk !
pi_3Ls2N6FOLnt0RrSK16xCHKxd is a recent one
To me it feels like it's ignoring that I'm passing confirmParams.return_url
Because the PI includes a URL to follow, but it isn't taking me there
This is the code that's being used
3DS was requested on the transaction during confirmation. Are you not presented with a Stripe modal to auth/reject the payment?
Yeah I see it!
The error you're seeing is because the 3DS Source times out
Are you actioning it?
When I can! Often it looks like this
That was taken about 10 seconds after the secret was created
pi_3Ls2WPFOLnt0RrSK1LLluX0M I hit "Complete" on this one 🤔
It's so weird, I have done this on other projects and it works as expected, I cannot figure out what's making it appear to be random or not work when it does
I'm using v3, I've checked the API keys, I've checked that the secret returning is the secret for the PI
Are you attempting to re-confirm a PI that had previously failed confirmation?
I don't think so, I'm creating a new subscription each time
I just tried 4242 4242 4242 4242 and that works fine – just so you know the rest of the checkout works!
(I was jealous of your PNG avatar so I made one too)
'customer' => $stripeCustomerId,
'items' => [[
'price' => $stripePrice,
]],
'payment_behavior' => 'default_incomplete',
'payment_settings' => ['save_default_payment_method' => 'on_subscription'],
'expand' => ['latest_invoice.payment_intent'],
'default_tax_rates' => $taxRates,
])```
this is the PHP I'm using to create the subscription to get the secret
Is it because I'm re-using 4000 0025 0000 3155 over and over again? Is there some way of re-setting test card usage?
This PaymentIntent could be not be fulfilled via this session because a different payment method was attached to it. Another session could be attempting to fulfill this PaymentIntent. Please complete that session or try again.
No, that shouldn't matter at all
It feels like the PaymentIntent is not attaching correctly or something very strange is happeng, I'm going to double tripple check the customer ID
Okay I've gone over the whole thing again, double checked all the right codes are coming through and it's still happening
If I use a normal card 4242 everything flows through, but anything requiring 3D secrure it just freaks out
Hmm, could it be that clientSecret is cached in state somewhere?
Yeah I cannot imagine how, I'm re-building the component. I don't store it in a global variable, or even a component variable, I pass it straight from the API response to Stripe. If I take the first part of the secret with the pi it lines up with the one I'm expecting
Just going to re-check the variable names
Waaaaait is there any possible way that a webook failing would fail the source?
So I've disabled a webhook and it's working 🤦♀️ When the invoice payment fails because it require auth, it's sending a webhook to our test server and that's responding 500 because it can't find the customer in question. This appears to then cancel/break the source? And then it fails
I had assumed that webhooks would be passive – I saw it in the log and didn't think that would be the cause.
Hmm. Which event(s)?
👋 taking over for my colleague. Let me catch up.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Yup that's it! I'm just taking a deeper look at to why we issue a 500, but that does seem to be the issue – I had no idea that could fail it!
What was the logic in the handler for the webhook? There's a call from your code somewhere that deletes the subscription not long after the (failed) confirmation attempt: https://dashboard.stripe.com/test/logs/req_rYO7oy8jeiLAnY
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
That's the subscription from the initial PI you shared
Yeah the logic was to clear up any mess left behind – but that is probably doing more harm than good!
This appears to be the issue
I hate myself
Thanks for your help!
That's likely the root I suspect, not so much the failing webhook
Goooot you – I think what we've done is that if our webhook controller fails, it then deletes the invoices 🤦♀️
👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!