#garymoon

1 messages · Page 1 of 1 (latest)

versed surgeBOT
outer lake
#

Can you share the invoice id?

indigo holly
#

Sure thing, thanks mate: in_1MCr7eJlOH731doq9NZqZgwN

#

LOVE LOVE LOVE the username 😂 Had a flashback immediately to the pilot 😂

#

And your dp is the dog too, I'm dying 😂

outer lake
#

Haha thanks

#

Ok so I looked at this invoice a bit. Since the invoice is being paid server-side (customer isn't online completing payment), getting that error message that authentication is required is expected. The reason the invoice was voided and cancelled was because of this call your server made: https://dashboard.stripe.com/test/logs/req_FjgisVZ27bZ2aA

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

indigo holly
#

Oh that log is interesting, thank you, I'll dig into that.

However, the customer is online for the card capture. For example using 4000003800000446 gives us a 3DS prompt and success as expected. 4000000000003220 doesn't 3DS prompt at all.

#

If I may DM I can share a link to our integration which is using the card Element.

outer lake
#

Did you mean to send a different one?

#

It's easier if I can just look at id's you send me

#

Maybe try running through your test flow right now and send me the id's that are used where you see this problem

indigo holly
#

Oh I see, so it's being declined when we attempt use the captured card because there's no customer present for 3DS, but 3DS also isn't being triggered at capture time.

#

Will Stripe not prompt for 3DS when using a SetupIntent and a 3DS2 card?

#

SI is seti_1MCr0rJlOH731doqzJ7qKvax

outer lake
#

It should. Let me take a look

#

That shows that 3DS authentication succeeded

indigo holly
#

We reliably don't get prompted for that card, and the failure to pay the invoice suggests 3DS wasn't successful.

outer lake
#

I'm referring to the setup intent, specifically where 3ds was successful. The 3220 test card, however, will always require 3ds for all future transactions regardless of the fact that you set it up. So attempting to pay the above invoice did fail 3ds authentication. To test the case where setting up a payment with a SetupIntent doesn't require authentication for future transactions, you can use 4000002500003155 from https://stripe.com/docs/testing#authentication-and-setup.

The fact that you're not getting an authentication prompt when entering the 3220 card in your card element is strange. Can you share an example payment intent where this happened (I know the shared invoice from above isn't a case where this happened because the customer wasn't on session for the transaction)?

Testing

Simulate payments to test your integration.

indigo holly
#

I can only share a SetupIntent. We use an SI to capture the card, then use that card to pay an invoice and start a subscription. Do I understand correctly that we can't use that flow at all with 3DS2 cards?

outer lake
#

No you can do that if you'd like

#

The 3220 card just isn't the best test card to test what would realistically happen when you do that

#

4000002500003155

#

That's much more realistic ^

#

Because most cards, when set up with a setupintent won't require future auth if set up properly for off_session payments. The 3220 test card ignores being set up with a setupintent. It will always require 3ds

#

Now the important thing to note is that some banks, for whatever reason, might require 3ds on future off session transactions. It's usually rare if the card is setup properly, but it happens. So, your integration should be able to handle the case where a customer will need to come back online in some point in the future and auth the transaction