#bertiespell-3ds-failures

1 messages · Page 1 of 1 (latest)

near chasm
#

Hey there! Can you share the ID of a Payment Intent so I can take a look at how you're integrating?

tame harness
#

Hey!

Here are some examples of customer's who've had these 3DS problems:

https://dashboard.stripe.com/customers/cus_KUWlmDQJFwa2Fx (fixed by client added another cc)
https://dashboard.stripe.com/customers/cus_KE2jB2PuamGsai (fixed- by us adding cc manually)
https://dashboard.stripe.com/customers/cus_KgpTJqB52Csh44 (fixed by client added another cc)
https://dashboard.stripe.com/customers/cus_KoQMHtyZ8VjFvu (not fixed, client not replying)
https://dashboard.stripe.com/customers/cus_KJcTdQx9OTxDfh (not fixed, client let account close)
https://dashboard.stripe.com/customers/cus_K3XPP7cxxuV4Bn (fixed by client added another cc)

left oasis
#

could you share a specific PaymentIntent for a specific failure rather than just customer IDs?

tame harness
left oasis
#

yeah ok, make sense.

#

that's why you should never really use those APIs that directly attach token/sources/paymentmethod to customers, you should use SetupIntents(or PaymentIntents configured with setup_future_usage, depending on the context) since those have a state machine such that if authentication is required during the validation of adding cards to customers, it can be presented and handled instead of the straight decline those older APIs return.

It's been that way since we launched these SCA-ready APIs in 2019, but probably now some banks are forcing auth on these $0 validations so you see it more often.

tame harness
#

When we update a card we call PaymentIntents.Update, is the issue then that we're not also setting setup_future_usage? What about switching to PaymentIntents.Confirm would this make a difference?

left oasis
#

I don't know what you mean by " call PaymentIntents.Update" exactly, can you elaborate a lot more on the exact integration and exact API calls?
Like I assume you mean

  • you create a PaymentIntent
  • a payment is attempted and fails
  • you attach a new card to the customer(that API call you linked?)
  • you update the payment_method field of the PaymentIntent to that new one? (note that does nothing, you have to confirm the PaymentIntent to attempt another payment, which is why I'm confused by the mentions)
tame harness
#

Let me see if I can try to explain a bit clearer how we currently integrate 🙏

When a customer wants to update their CC information we:

It sounds like what we need to do instead is call Confim on the PaymentIntent and not just Update as this will handle 3DS, as the problem we have is that this card is later failing 3DS checks. Is that a fair assessment? 🤔

left oasis
#

So my confusion here is, when is the customer updating their info? Is is just they do it through your user dashboard, or is it when handling a failed payment?

If it's the former I'd do this :

  • Update the source on the Customer

Use a SetupIntent here (https://stripe.com/docs/payments/save-and-reuse) instead

  • Update the default_source on the associated Subscription

Yep, basically! Though https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method default_payment_method is usually preferred

  • Then we call Update on the associated PaymentIntent

The bit I'm confused on is what is this associated PaymentIntent? if this is just an update flow.

===

So assuming it's in fact the latter(updating after a failed payment) I would

  • update the PaymentIntent to set setup_future_usage:"off_session" , which tells us to save the card used to confirm it to the customer(there's an issue today where we don't set that parameter on PaymentIntents that come from recurring invoices so you have to manually set it)

  • confirm the PaymentIntent directly with the card details, directly on the payment page, like I linked above. If you do that, it charges the invoice, attaches the card, and should be fine.

  • update default_payment_method after that, so that its' charged for future payments

tame harness
#

So my confusion here is, when is the customer updating their info? Is is just they do it through your user dashboard, or is it when handling a failed payment?

This is when they update CC info through our dashboard yes, so that can either be because they are updating their card in general, or because a payment failed and they've been asked to update payment details. We only update the PaymentIntent if there is a PendingIntentSecret associated with the subscription, in which case we use the Subscription's PendingIntentIDto update it). In either case though, we're seeing cards receive the error I posted above whereas we haven't had this problem before and it's been implemented this way for some time.

When you mention this:

there's an issue today where we don't set that parameter on PaymentIntents that come from recurring invoices so you have to manually set it

Is that a recent bug/change, as perhaps that's what we've been affected by and why we're now seeing a difference?

#

I understand that now the recommended path is to use a SetupIntent instead of updating the source on the customer - but this would be quite a lot of work for us to change now. I'm trying to explain to my team what is causing the new 3DS errors we're seeing when this wasn't the case before. Just to be clear, are you saying this was never a supported path for cards requiring 3DS (and so I guess that it worked before "by chance"), but now we're seeing more errors due to this reason you stated before?:

But probably now some banks are forcing auth on these $0 validations so you see it more often

left oasis
#

In either case though, we're seeing cards receive the error I posted above whereas we haven't had this problem before and it's been implemented this way for some time.
like I said, it's probably that banks have started enforcing 3DS on those $0 validation charges at a higher rate in recent times. Nothing has changed on Stripe's side directly. You could ask our support team to try to analyse if there's trend like specific banks doing this more than others.

Is that a recent bug/change, as perhaps that's what we've been affected by and why we're now seeing a difference?
nope it's always been that way(it was just brought to our attention recently and we're looking at changing it so it was top of mind for me)

Just to be clear, are you saying this was never a supported path for cards requiring 3DS (and so I guess that it worked before "by chance"), but now we're seeing more errors due to this reason you stated before?:
It's semi-unclear. I'm not sure if banks are "supposed" to enforce 3D Secure on validation charges, but they seem to in some cases, you're not the first merchant I've seen in this exact case. Our integrations and understandings have evolved over time and we nowadays try to only recommended flows that use our Intents state machines, which would handle all this.