#bwurtz999
1 messages · Page 1 of 1 (latest)
hey there, taking a look
Do you have a serial number available for that reader?
That will let me look at recent logs
It appears that the reader was still busy process the payment following this request: https://dashboard.stripe.com/logs/req_lJCiaq3o6oY1kE
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
OK... can you help me understand this process a little better. I'm reviewing the logs and I see that 9:09:03 it looks like a request was POSTed to process the payment intent
And it was finished processing at 9:09:28
But, at 9:09:20 my app attempted to cancel the collection action because of the time that has passed
Can you tell me what was happening between 9:09:03 and 9:09:28?
Why can't I cancel that collection action during that time?
Had the customer already dipped/tapped their card? And Stripe was just taking a while to process the payment?
Yes, exactly -- a card was presented at x:09:14 so it was already into processing that when you requested the cancel_action
The customer was a bit slow to present I suppose, and you requested cancelling just a few seconds after they tapped
OK. Do I have access to the terminal logs?
Not at this time, no
OK
So the way my app works, for server-driven integrations, I poll for ~20 seconds after the reader is activated to process the payment intent
I don't want it polling indefinitely, so I stop it after a certain point to cut down on requests
If I were to check the reader as I'm attempting to cancel the action, what would tell me that it's already received card info?
You might want to configure that with an exponential back-off
Basically what you encountered implies that
If it hadnt, you'd have been able to cancel
You are subscribed to the events for this and got the success events at x:09:30 & :31
Such as evt_1MEZAlFW9LyxBBXmSpNrH4hN for reader action succeeded
and evt_3MEYzpFW9LyxBBXm2HvvyKMZ for payment intent succeeded
Yes, and I received the webhook
OK so catching this error means that the card has already been presented. Got it
Is there a way for me to intentionally slow down the processing in test mode so that I can simulate this?
It testing it never takes 14 seconds for a payment to process
It's always much faster
Hmm not easily i don't think, without some complex network packet manipulation to delay
Could this have potentially taken so long because the card required additional authentication to complete the purchase? And is it possible to trigger additional authentication with something similar to these errors (https://stripe.com/docs/terminal/references/testing#physical-test-cards) ?
Or do I have to use a simulated test card to invoke additional authentication?
Hmm I'm not familiar with any such flow, but i suppose its conceivable for a bank/card to build this
But no we don't have any test card with a flow like that
Something to simulate a debit card needing a PIN? Anything?
The simulated cards have examples for prompting for PIN: https://stripe.com/docs/terminal/references/testing#test-cards-for-specific-success-cases
So you can potentially work out this path using the simulated reader and those cards
Quite welcome 🙂 thanks for your patience