#nickc-legacycard-sca
1 messages ยท Page 1 of 1 (latest)
Hi ๐
The Payment Method API should be backward compatible. Do you have any example payments that failed due to using the card_ objects?
sure, let me add a little more context first:
- we used to charge these subscriptions to a merchant's connected Stripe Standard account (via Stripe Connect) using Direct Charges. Cloning the customer to their account created a
pm_token. - we have built out a new payment system which charges those subscriptions to our platform account (which we pay out to our merchants via Transfers to a Stripe Express account they set up connected to our Platform account), however the only way I have to get some of these old payment methods is to use the
CustomerAPI to list payment methods, which for these older saved customers lists acard_token.
Here's an example of a charge that was performed against our platform account with a saved Customer: ch_3NFsOb2Tl1fYCjx21opfFNR1
This was declined by the issuer due to not using SCA, according to Stripe Support
here's an example of a charge performed against that same customer where we cloned the customer to the merchant's Stripe Standard account: ch_3NG8nF2oom3NW9KP1G4Fc6qm
This charge succeeded because it used a pm_ token for the payment method, which according to Stripe Support supports SCA.
So basically we have a bunch of payment methods stored in our database, and older ones only store the cus_ token, while newer ones store that token + the pm_ token that the Stripe.js PaymentIntent creates.
It seems like the only way to charge these older customers and have banks not reject them is to figure out how to turn that cus_ token into a pm_ token
Well for the failed charge the bank returned a do_not_honor response. So they were rejecting the payment.
But our newere payment methods do use other tools to increase acceptance by banks so you have a higher success rate
Yes, here's the response I got from Stripe Support on the matter (I provided a couple of examples):
One probable explanation for the payment being declined in the platform is that the platform uses the card API. I reviewed one of the payment methods card ending 4638 and found that the merchant uses the payment method API (pm_1NG**) while the platform uses the card API (card_1FDu**). The card API does not comply with SCA.
so it sounds like to increase acceptance rates I would need to find some way to use the Payment Method API for those old customers where we only have access to the card
I've tried creating a token for that card but that doesn't seem to work unless i'm using it to clone a payment method to a connected account
Well that would not grant you the SCA mandate. For that the customer needs to be on-session and authenticate with their issuing bank
I think your best bet is to ask your customers to update their payment methods using the new Payment Method integration
That's what I was afraid of, that makes sense. I appreciate the response!
Yeah, using either Setup Intents to just save the Payment Methods to the Customers (https://stripe.com/docs/payments/save-and-reuse) or saving it as part of a payment (https://stripe.com/docs/payments/save-during-payment) will take your customers through the process of setting up the Payment Method and providing any additional authentication required
๐ Taking over. Card object work the same as PaymehtMethod objects
there's absolutely no reason to re-collect card details and the advice you were given by our support team is definitely wrong
nickc-legacycard-sca
Is there a different thing that explains the decline when charged against our platform account vs the accepted charge when charged against the connected Stripe Standard account using Direct charges?
This would have nothing to do with the fact that it's a Card itself, it could be many different things such as the bank just declining for certain criteria.
It definitely could be that 3DS is needed but you don't need to re-collect card details. You neeed to get the Customer back on session on your app and you can confirm that PaymentIntent client-side with the already saved Card card_123 and it will do 3DS as needed
Ah okay, so I do need to get the customer back on-session, but present them a payment intent created with the card object
yes
you can re-collect card details if you want and that can be easier to build for sure, but you don't have to
you have to know that even with a PaymentMethod object pm_123 the same thing can happen. Banks will ask for 3DS regularly even if you did it before
If we store enough payment info ourselves about the customer to provide that level 3 data, is that something we could pass along when we create the payment intent to perform the recurring charge for the subscription?
We already do this for some merchants who migrated onto our platform but own their own customers in Stripe with the Charge API
ah yeah i see that we have access to the Level3 feature and should be able to pass that along to a PaymentIntent the same way we do a Charge
What does level 3 data has to do with it?
We don't really talk about secret features here but you can not set any of this with Subscriptions at least
ah sorry, i was conflating 3ds with L3 data
all good
So we'll need a way to direct customers who have bank declined payments to a thing that allows them to complete whatever is needed for 3DSecure
yep
and this may need to be done periodically, not just once?
you basiclaly send them to like example.com/payment_recovery. and there you show a UI showing say their card brand + last 4 + expiration date with a "Pay button" and that calls confirmPayment() with the right pm_123 or card_123 id.
And you can have a separate "add new card" that would just use PaymentElement
and yes, you can't just do 3DS once and then for the next 10 years it just works. There are a lot of rules around 3DS and exemptions and such but banks will still want you to do 3DS occasionally even for off session payments
you mostly handle it the same way you'd handle a card decline really
Got it, one thing i'm still confused about is why the same customer worked for the connected standard account without additional 3DS steps but not our platform account
could be any kind of reason, maybe they charged that card before, maybe they are in another country, maybe the amount was different, etc.
Got it. Appreciate the help/clarification!