#Nyxi
1 messages · Page 1 of 1 (latest)
Looking
Wondering if the failing payment was actually an Apple Pay or similar wallet-type card and the handling of that was broken
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
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
The first confirmation for that PaymentIntent (https://dashboard.stripe.com/test/logs/req_0ZtR0U4qIB5JmB) used pm_1M7MyQLj11YtqxjbCIkmLzWx which was cloned from the platform from pm_1M7MyPL7ilRdQXxEMEH1BuE7 which was created via StripeJS without Apple Pay (used Card Element) here: https://dashboard.stripe.com/test/logs/req_oQJmBkzT93cv5K
Maybe I misremember
Overall, as you noted, Apple Pay should never require 3DS since it fulfills authentication already
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
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
You can try here if there is a case you want to test out. Only requires random test data: https://nyxapp.eu.ngrok.io/confirm/637e6223d4e66ae729f5c9c1f1e2bbc1
I will try
does this if I just close it
as expected
What's the PI for that test?
pi_3M7NSLLj11Ytqxjb2Kxo1r9B
still does POST /v1/payment_intents/pi_3M7NSLLj11Ytqxjb2Kxo1r9B/source_cancel
200 OK
Ah okay so yeah that does fire the source_cancel
but it also works fine
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
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
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.
Yeah alright
Is there a way to force an Apple Pay test to fail?
It always succeeds in test mode
Hmm no not really since all it is actually doing is tokenizing the PaymentMethod and we are just tokenizing a 4242 card
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
You could probably test this using Radar rules
But then it is different from the normal flow
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
Yeah that's fair
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