#Nyxi

1 messages · Page 1 of 1 (latest)

lucid stratusBOT
long plume
#

Looking

ancient void
#

Wondering if the failing payment was actually an Apple Pay or similar wallet-type card and the handling of that was broken

long plume
#

Okay so initially that example did not use Apple Pay and 3DS failed

#

Then it collected a new PaymentMethod via Apple Pay and no 3DS was required and it succeeded

#

So that all seems fine to me

ancient void
#

hmm

#

I only used Apple Pay on that test though

#

I dismissed the Apple Pay modal once though, let me try that again

#

Maybe not

long plume
ancient void
#

Maybe I misremember

long plume
#

Overall, as you noted, Apple Pay should never require 3DS since it fulfills authentication already

ancient void
#

Yeah that' why I was confused

#

I'm probably misremembering

#

did a bunch of tests here trying to make it not work

#

Unsuccessful so far

long plume
#

Have you tried just closing the 3DS window instead of actively failing it?

#

I can't remember if that fires that source_cancel request in test mode or not

ancient void
#

I will try

#

does this if I just close it

#

as expected

long plume
#

What's the PI for that test?

ancient void
#

pi_3M7NSLLj11Ytqxjb2Kxo1r9B

#

still does POST /v1/payment_intents/pi_3M7NSLLj11Ytqxjb2Kxo1r9B/source_cancel
200 OK

long plume
#

Ah okay so yeah that does fire the source_cancel

ancient void
#

but it also works fine

long plume
#

But yeah that really shouldn't be the issue. It just jumped out to me before as being different from the other PI you shared and wondered if that is somehow throwing something off

ancient void
#

I can't really think of anything to test

#

All attempts have worked or errored correctly

#

I tried various test cards, declines, with/without 3ds, apple pay etc

long plume
#

Yeah. My only guess at this point is it is some weird interaction involving the issuer and the ACS for 3DS and then how they are sending responses back to us. But really hard for me to check on that stuff without more logs about specific timing like mentioned previously.

ancient void
#

Yeah alright

#

Is there a way to force an Apple Pay test to fail?

#

It always succeeds in test mode

long plume
#

Hmm no not really since all it is actually doing is tokenizing the PaymentMethod and we are just tokenizing a 4242 card

ancient void
#

That's the only case I haven't covered

#

Hm ok

#

Maybe you could have to so putting in a specific amount would trigger a failure on Apple Pay then

#

just an idea

#

cause no way to check if this error handling works otherwise

long plume
#

You could probably test this using Radar rules

#

But then it is different from the normal flow

ancient void
#

would also require that I enable it

#

and I don't need it

#

cause it's 3ds or nothing in our case

#

it's explicitly required

#

It was just a general idea that could help trigger various errors on Apple Pay, like you have certain card numbers

#

since we can't have test Apple Pay cards

long plume
#

Yeah that's fair

ancient void
#

But anyway, I found some code that looked really wonky, but that was only for Apple Pay cases

#

so I haven't really changed anything that could explain the error from before, as it was not Apple Pay

#

I will deploy this with the extra if/else logic we talked about and see what happens