#monove
craggy tide
slow palm
HI 👋
Currently when you use the set_reader_display it is enabling what is referred to as "pre-dipping", allowing you to collect card information prior to completing the payment intent.
We call this out here: https://stripe.com/docs/terminal/features/display#pre-dip-a-card
Unfortunately this isn't something you can disable at present. However I can make a request for this feature
The only way to clear the screen at that point is to cancel the reader's action using this endpoint: https://stripe.com/docs/api/terminal/readers/cancel_action
craggy tide
We call this out here: <https://stripe.com/docs/terminal/features/display#pre-di...
what is the webhook callback for that pre-dipping
slow palm
There isn't one. The payment method details are still only stored on the device itself so no objects on your Stripe account are changed.
craggy tide
Then would you agree that displaying a misleading message on the reader followed by another misleading message is a bug, not a feature request?
slow palm
No, this is the intended behavior. It is just that the flow here is rather opinionated about what you should do next.
craggy tide
I'm confused then. When that green light shows and they tap their card, is there any way we can listen for that from our server?
slow palm
In that situation it is expected that whoever is controlling the POS system would continue to process the payment. The server would not be notified but the human operator adjacent to the reader could process the payment without requiring the customer to provide their card again.
Would it be accurate to say you want to use the cart display to simply show an itemized list of the charge and you are currently not interested in the pre-dip/swipe/chip behavior?
craggy tide
no. i like the pre-dip idea. i just want some way of receiving that card information.
so, either:
- no pre-dip functionality
- pre-dip but guide how to receive and process that card
slow palm
There is a slightly different integration where you can collect the Payment Method data on your server and inspect it before you process the payment but that requires requesting access. We mention it here
https://stripe.com/docs/terminal/payments/collect-payment?terminal-sdk-platform=server-driven&process=inspect#process-payment
craggy tide
from our experience we have been unable to create a hybrid of server-driven and front-end-driven payment flow. So, when we push out a request to set the reader display, it is expected that no misleading information be presented to the customer
if the customer taps the device and theres a beep but we have no way of either receiving the event server-side or processing it client-side, thats a bug
slow palm
You could test out polling the reader to see if the status changes in a way that would indicate the payment method has been captured. Unforuntately I don't have my terminal reader with me at the moment to test this.
What is triggering the server API calls?
lucid ventureBOT
craggy tide
Our API. The terminal faces the customer. As the order is built up the customer sees their order. There are multiple payment options on our kiosks/POS including Cash, Credit Card etc.
When either the customer at a kiosk or the POS operator tap the Credit/Debit button, we create a PaymentIntent and push it from the server to the terminal
We're fine with the pre-dipping but only if theres either a webhook event for that or the ability to connect both client-side and server-side so we can process the card
otherwise it is confusing to our customers. Like did the payment go through or not. It made a beep and the green light is now gone and the display clearly says "Completing your order". That might leave them standing there and waiting
slow palm
Yes I can understand that.
Hold on a sec. Would you be able to test this right now?
Or can you share a payment intent ID where this occurred?
I want to double check whether the terminal.reader.action_succeeded event https://stripe.com/docs/api/events/types#event_types-terminal.reader.action_succeeded might be just what we are looking for.,
craggy tide
👋 @slow palm
plain steppe
Hi there 👋 taking over, as my colleague needs to step away. Apologies for the delay.
Give me a few minutes to get caught up.
Okay, so that request shows that you set the reader display. When you use a card and the reader beeps, are you seeing any additional requests/events? Specifically wondering if another terminal.reader.action_succeeded event occurs after a payment method is used on the reader
craggy tide
no terminal.reader.action_succeeded event is fired
2 others experiencing the same frustration
plain steppe
Gotcha, okay. And you have a use-case for not creating the Payment Intent until after the customer enters card details?
Unfortunately I don't think you can use the cart-display when pre-dipping. We've already submitted a feature request for this to be added as a feature fo what it's worth
craggy tide
whats the feature request?
im fine with creating a paymentintent even before the client enters their credit card details but theresno association between setting the reader display and a payment intent
so i guess I'll have to rephrase my original question:
For server-driven integrations, callling the set_reader_display function displays a misleading line about tapping to pay and displays a green light. When the customer taps to pay the display says it is completing their order. It is not completing an order. I wish I could pass in a PaymentIntent or something that could be triggered were the customer to tap their card.
this is a bug for the server-driven flow, not a feature request
either hide that line about tapping to pay or allow it to work somehow
plain steppe
yeah, this whole workflow is a bit confusing. Like, our documentation says
The amounts passed to the setReaderDisplay method are only used for display purposes.
And
Even if a customer pre-dips their card, your application must still complete the full payment flow.
Which is fine in theory, but presenting the ability to accept card credentials means there needs to be some way to use those and I'm not finding any indication of how. Either this is a bug (as you say) or there's something I'm missing.
Let me dig a bit more and circle back. Give me a few minutes
Out of curiosity: does the event that occurs from setting the reader display (this request from earlier --> req_78SA0F5Kpx7kiz) fire before or after the payment method is tapped/swiped?
lucid ventureBOT
craggy tide
sorry, can you you rephrase that question?
plain steppe
Like, do you get the event before or after the display is set. It's a long shot, but I'm curious if anything usable at all is triggered by the customer tapping a card
craggy tide
we dont get any event. req_78SA0F5Kpx7kiz is our request to set the display with the mini cart.
that works, but also display this
not that exact text but like that
the simple customer taps their card. it beeps and shows this:
our webhook doesnt receive any events
we are listening for reader events like evt_1OHUqDB26iHaRoZCLqf7r9fV
plain steppe
Right.. ugh. I was hoping there was a hidden "gotcha" here somewhere that would make this flow doable, but I'm out of ideas. I'm going to file a bug report and poke at the product team a bit, because this does indeed seem broken.
As a last-ditch effort before I do, can you confirm that your reader is completely updated to the latest firmware?
craggy tide
reader version/updater version: 2.18.9.0
Firmware: 5.00.01.25
Bootloader: 6.00.00.41
plain steppe
Yup, that's the latest. Alright, thanks for bearing with us. I'm filing a bug report and poking at the product team now as I hop off of Discord. I'm not sure if/when a fix will be in place, so for now I'd recommend not using the cart display feature.