#rudi-declined-card

1 messages · Page 1 of 1 (latest)

torpid dove
#

Hey, you say it fails with Stripe.js - is that using confirmCardPayment?

pale rampart
#

no, I use stripe.createPaymentMethod('card', card)

#

then with the given payment_method.id I call from Ruby:

#

Stripe::PaymentMethod.retrieve

#

Stripe::PaymentMethod.retrieve(payment_method_id)

#

we have been processing a lot of cards for years, and this problema started a few weeks ago, exclusively with expedia virtual cards.

torpid dove
#

Can you share a PM ID?

pale rampart
#

I'll try now.

#

this has been created with Stripe::PaymentMethod.create, and it's fine "pm_1KedSKG3lu1xZIdba7XPbpna"

#

now I'll try the same card from the web form.

#

This one fails: pm_1KedxIG3lu1xZIdb1IY0mtSr

torpid dove
#

You need to share the PI if it's failing an actual payment

pale rampart
#

You are right. I see ... it fails later, when attaching to the StripeCustomer.

torpid dove
#

Yeah, you generally shouldn't do that as that request will likely trigger authentication from the bank

#

And that endpoint can't facilitate the required 3DS checks

pale rampart
#

for example now I got the error attachingpm_1Kee5uG3lu1xZIdbUyuRHDAn to cus_LLKlvo6jHQs7Am

torpid dove
#

Yep, explained above why

#

Generally don't use the /attach endpoint

pale rampart
#

but it works for every other card ...

torpid dove
#

Every bank is different! Some may request auth, some may not

pale rampart
#

this is not a bank actually, expedia virtual cards are from expedia. We have been processing hundreds of card for years this way. We create the stripe customer, create the card, attach the card.

torpid dove
#

But our recommendation is to not use that endpoint, and instead implement a Setup Intents flow which can handle 3DS if required

pale rampart
#

But if I try to pay with that card, I got no 3ds trigger. It just works.

#

I mean, it does not work attaching it, but I can on the other hand charge it 🧐

torpid dove
#

Yes, but SCA is now becoming mandatory in Europe. Regulation requires banks to perform authentication for certain transactions. This endpoint, unfortunately, unintentionally triggers a 3DS request auth from some issuers/banks and it can't facilitate it (as its essentially marked as an off-session transaction)

pale rampart
torpid dove
#

Where?

pale rampart
#

ath the end (5. Use the payment method)

#

If you didn’t create the Checkout Session with an existing customer, attach the PaymentMethod to a Customer

torpid dove
#

Yes, but at that point the PM has been generated by the Setup Intent which facilitates completing required auth checks

#

Your way of creating the PM does not do that

pale rampart
#

I don't understand how can I use that example. I am batch processing the cards when I save them, there is no checkout session.

torpid dove
pale rampart
#

it's still a client-server example ... I just receive a list of credit cards from another service and I have to save them on stripe for later use.

#

No stripe.js

torpid dove
#

You'll need Stripe.js to handle the 3DS flow

pale rampart
#

now i create customer (Stripe::Customer.create) then payment method , the I attach the pm to the customer.

torpid dove
pale rampart
#

I know 3D and I know that some cards sometimes require user input, but this cards don't. If I create it and charge it at the same time it works.

#

on the other hand I don't understand, are you saying that gradually it will be impossibile to save any card for future payments without user input?

torpid dove
#

but this cards don't
The issuers is requesting that the cardholder authenticate that transaction. When you attach, it's mostly the equivalent of a $0 charge

pale rampart
#

exactly. Why it doesn't allow 0 charge but it allows a 200 eur charge?

torpid dove
#

on the other hand I don't understand, are you saying that gradually it will be impossibile to save any card for future payments without user input?
I wouldn't say impossible. But in Europe, yes it'll become more and more likely that auth will be requested

torpid dove
pale rampart
#

Actually the operators are telling me that they charge it on Stripe directly.

#

So, attach fails (using the api, with card_declined errore) but charge from Stripe UI works. Secure code is never asked.

torpid dove
#

You mean the Dashboard?

#

Those are flagged as MOTO transactions, which are exempt from SCA: https://support.stripe.com/questions/mail-order-telephone-order-moto-transactions-when-to-categorize-transactions-as-moto

Mail Order Telephone Order (MOTO) transactions: when to categorize ...

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

#

That will be why there's no prompt for 3DS

pale rampart
#

yes from the dashboard

#

Ah, and how can MOTO be enabled on out account?

torpid dove
#

Well it only works when charging cards. Not saving them like you are

pale rampart
#

For example now they charged it "src_1KeebhG3lu1xZIdbpPEm5Akb"

#

So there is no way to save the cards for future use without user input?

#

Looking at the successful payment (pi_3KeeboG3lu1xZIdb1qGYlgNV) I see that the card is marked as "three_d_secure": "optional",

#

"country": "US",

#

It's not even EU

torpid dove
pale rampart
#

Ok I understand, but I am not sure that 3DS is the problem with these cards.

#

Being virtual I don't think they can have any secure code.

torpid dove
#

It's not the CVV

#

It's simply the user authenticating the 'transaction' so that they approve it. Normally via SMS, biometrics, etc

pale rampart
#

Yes I know, we use it already on online payments. But these cards, according to Expedia, do not require any kind of authentication.

#

Even the payment transaction issued 10 minutes ago seems to reinforce it: "three_d_secure": "optional",

torpid dove
#

Decline code: transaction_not_allowed

Your card does not support this type of purchase.

pale rampart
#

I've seen that another virtual card worked, but it is marked with "three_d_secure": null instead of "optional"

#

pi_3KeaJ6G3lu1xZIdb0AcRrTby

torpid dove
#

But again, this is all just determined by the bank/issuer on a per transaction basis. You really need to adapt your integration flow if this is problematic otherwise you'll continue to see these issues

pale rampart
#

and what does "optional" mean? It seems that we can change the rules from the dashboard "Use Radar rules in the Dashboard"

#

maybe we can uncheck the first check

torpid dove
#

Configuring Radar rules won't change things as they only relate to payment/charge attempts

pale rampart
#

ok thanks, we'll try to contact again expedia

#

but what does "optional" mean on the three_d_secure attribute?

torpid dove
#

I believe that means the bank hasn't required 3DS but we will defer to your Radar rules and request it if necessary

pale rampart
#

so the radar rules could change that behaviour

torpid dove
#

Unlikely as 3DS is being requested by the issuer

#

Radar is not really playing any part here

#

I've outlined the steps you need to take to adapt your integration to work, I'm not sure what else we can suggest

#

That would only apply to any cards you've 'saved' prior to the exemption date. Any new cards going forward would (likely) need to be auth'd, so you'll need to update your integration anyway

pale rampart
#

ok thanks

#

we'll try to contact the card issuer. We even noticed that this problem happens on a specific stripe connected account. Other accounts do not have the problem.

#

this for example pi_3KdUxnL2DI6wht390ksoO507

torpid dove
#

What's the issue? That payment succeeded

pale rampart
#

exactly, same issuer (mastercard "Expeida virtual card") but the transactions work (0 transactions as well as real tx)

#

Looking at the json I notice that all the cards that succeeds have the null "three_d_secure", while those that fail have "three_d_secure": optional. Other than that I don't see any difference.

willow atlas
#

Hi 👋 jumping in as my teammate needed to step away.

#

We don't have any insight on why a card issuer declines authorizations other than what they return. The issuer will be better positioned to explain why they declined one but not the other.

pale rampart
#

Ok thanks, we'll try to ask them!