#Arkalezard-3ds2-test-card

1 messages · Page 1 of 1 (latest)

remote jasper
#

Hey! Did you try this card? 4000000000003220

#

3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.

#

Also, what do you mean by 'Your other cards with rejection can't be attach to a client so it's impossible to test the transaction flow with it'?

sly frigate
#

This card is working. I want to generate a transaction with the failed statut like the "insuffisant funds" reason

remote jasper
#

This card will return that error, but won't prompt for 3DS: 4000000000009995

sly frigate
#

If I cancel on 3DS it's incomplete not failed

remote jasper
#

What's incomplete?

sly frigate
#

4000000000009995 this card can't be added to a customer

remote jasper
#

That is expected for a Payment Intent if authentication fails. Auth and payment can be re-attempted

sly frigate
#

On my flow, user have to attach a card then he's trying a transaction

remote jasper
#

What state are you trying to test exactly?

sly frigate
#

4000008260003178 this card can be added and the statut of the transaction will be failed

#

it's what i'm looking to reproduce but with a 3DS2 not a 3DS1

night talon
#

If you need to attach to a customer the card to use for that is:

4000000000000341 Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.

#

We don't support all combinations of errors & flows with specific cards

#

ie, that card will be a generic decline, not an insufficient funds error

sly frigate
#

I tested. It's doing something different than my research. It's close but exactly the usecase I need to study

#

There is the failed statut but in term of logs and 3DS it's not the same

night talon
#

Yes, that's correct, its not 3DS failure and it's not the same

#

What exactly are you trying to test? What's the flow?

sly frigate
#

In my expectation, 3DS(2) is working but the transaction not

#

what I want to test

#

What I did with your card

#

The difference is the 3DS version

#

but 3DS is not the same

#

The impact is visible as soon as we cretate the paymentIntent

night talon
#

There is no test card for that exact flow

sly frigate
night talon
#

the insufficient funds error card doesnt support 3ds2

sly frigate
#

and is it planned to increase the coverage of your testcards for 3DS2? It's a new way of validation and we need to understand and test it efficiently

#

Is there a way to force a card in an user profile?
Maybe if I'm able to force the card 4000000000009995 in a customer I'll be able to reproduce something similar?

night talon
#

Actually wait, looking again at the 3178 card i think im wrong here?

#

4000008260003178 This card requires authentication for one-time payments. All payments will be declined with an insufficient_funds failure code even after being successfully authenticated or previously set up.

#

What about this is not working for you?

#

Let me test myself

#

After auth this declines with insufficient funds for me

sly frigate
#

Yes but the 3DS remains v1 not v2

#

The paymentIntent will be based on another type

night talon
#

Can you share that payment intent ID?

sly frigate
#

the test one with 3DS1 or the prod version with 3DS2?

night talon
#

The test payment with the 3178 card

night talon
#

ok thanks, and the real one?

sly frigate
night talon
#

OK i see. It seems like that test card is configured to use 3dsv1, so this is expected/normal. I've asked internally if this is intentional, but for now it would be a limitation of the test card.