#Niklas-payment-declines
bleak karma
Niklas-payment-declines
Hey! Is there an example Payment Intent you can share the ID of?
jagged pilot
Hey! Do you mean something like this? 🙂
pi_3KByyeFVJV8p54342u359UBU
bleak karma
Perfect
jagged pilot
As extra information - This often seems to happen when the custuomer has had an ongoing, successful, subscription.
And then when they try to change their card information they run into this error.
bleak karma
That one example you've provided is a straight up decline from the bank/issuer
Nothing seems out-of-line with the integration
jagged pilot
Okey, I see. Thank you.
Another, related question, if I may.
What's the quickest way of testing the following flow:
- Successfully create a monthly-based account with correct card credentials
- Have the added card expire
bleak karma
Hmm, always tricky to test date orientated scenarios like this. So you'd want the subsequent recurring payment to fail because of the expiry?
jagged pilot
Yes, because it seems like we have trouble updating expired cards after they have failed a payment
And only then do we have problem updating the card info
Which makes it very hard to test
bleak karma
Hmm, we do actually often updated saved payment methods even if the physical card has expired: https://stripe.com/docs/saving-cards#automatic-card-updates
But is only supported by certain issuers and in certain regions
jagged pilot
Hmm, not sure that helps here tbh
But the process/api call of updating an expired card should be no different from updating a non-expired card?
From a strictly technical integration-viewpoint
bleak karma
Well you can update an existing Payment Method object, specifically to update the expiry date: https://stripe.com/docs/api/payment_methods/update#update_payment_method-card
But in most cases an expired card comes with a new 16-digit number (and therefore a new Payment Method is required)
jagged pilot
Okay, because in the test environment we can flawlessy change between the 4242424... card and tht 555555555444.... card
Will the creating a new Payment Method fail if the new card has the same 16-digit number as the old one?
bleak karma
Which API calls do you make for that?
bleak karma
Will the creating a new Payment Method fail if the new card has the same 16-digi...
No, PM objects don't need to have unique payment credentials
jagged pilot
Which API calls do you make for that?
Let me check
We are using this endpoint to change cards on an existing subscription:
https://api.stripe.com/v1/setup_intents
bleak karma
Yeah so that would perform any required 3DS/auth on the card whilst your customer is on-session and create a new Payment Method object
Are you updating the default_payment_method on the related Subscription object with that new PM (pm_xxx)? https://stripe.com/docs/api/subscriptions/object#subscription_object-default_payment_method
jagged pilot
Yes, when looking in the Stripe dashboard in the test environment hte new "Default" payment method (card) is the newly changed-to card
bleak karma
Right, but is that on the Customer or the Subscription?
jagged pilot
On the customer
How can I see which card is on the subscription?
"Charge to default payment method"
That's the information on the subscription
bleak karma
Yep, it's set to use the default payment method of the Customer object then
You can set a default PM on a per Subscription basis
jagged pilot
I mean, all of this COULD be that the customers are trying to add faulty cards from there end.
But there is a very large increase in these type of questions from them lately, and that's what makes me wonder if anything could be wrong with the integration, which led me here
This customer claims that he has tried to update his payment method, but that it fails despite his new card being valid:
cus_Jl948SWu0d53su
Can I see the logs of that attempt somewhere?
bleak karma
Let me check
Hmm, there's no logs to suggest there was an attempt to attach a new card to this customer
What date was this?
jagged pilot
My understanding is that it happened today, or very close to it
jagged pilot
I do not recognize this kind of behaviour with my customers I'm afraid
jagged pilot
https://dashboard.stripe.com/logs/req_1wL7kONmAkRak0
Thank you for the direction of the logs
bleak karma
Thank you for the direction of the logs
That seems like a successful attempt to create a new Payment Method via Elements, but there's no subsequent call to update the Customer with that PM
There's also: https://dashboard.stripe.com/logs/req_nrO8dcrE5HecTf
Which is a confirmation attempt on a PI (but no Payment Method is provided)
jagged pilot
Here are logs from the test environment
https://dashboard.stripe.com/test/logs?method[0]=post&method[1]=delete&direction[0]=connect_in&direction[1]=self
Where I recently updated the payment method on a customer (twice)
Well, in essence what I don't understand is that it works perfect with all of your test cards
But there is a steady increase of customers having issues in production
Despite the integration being identical on the dev server and the prod server
And I'm not really sure how to troubleshoot it given the above
bleak karma
I can see the test logs, specifically with creating and confirming Setup Intents, and updating the invoice_settings.default_payment_method parameter on the Customer
None of that is evident in the live logs though
So there must be some other, different flow they're using (somehow)
jagged pilot
Doesn't these two calls in the live logs to exactly that?
https://dashboard.stripe.com/logs/req_tuL4Z8FKVKvJEa
followed by
https://dashboard.stripe.com/logs/req_1oiBxlLYWyu0yM
You can even see that the customer has a amex card with the last 4 digits being "3000", the same as the updated payment intent
bleak karma
Right, but there was no Setup Intent invoked
bleak karma
That pm_xxx there was created here: https://dashboard.stripe.com/logs/req_ewZjCy1EWby2Op