#calebmmmm
tall basin
@low kestrel let's chat here! I'm adding your message from the main thread
WisePos - Terminal Reader - How to use setReaderDisplay? I am calling $stripeClient->terminal->readers->setReaderDisplay(
$stripeReaderID, ... the card charges successfully, but the display remains with my custom display line items... how do I get it to continue and show payment successful.
low kestrel
ok... they are two separate questions.
tall basin
That's fine, we can address both in a single thread
tall basin
Give me a few minutes, I'm getting some additional help
reef totemBOT
tall basin
processPaymentIntent hands off payment to the reader. Since the reader could be waiting a while for the user to provide their payment method, the API doesn't wait for confirmation before returning the response {"msg":"Reader processing payment"}
low kestrel
yes, I understand that, but was hoping their might be an option to call it syncronously
worldly nebula
Hello! I'm taking over and catching up...
processPaymentIntent is an async operation. Why do you want to "call it syncronously"? What would that mean exactly?
I mean... we also might be talking about things differently. In PHP the call to $stripe->terminal->readers->processPaymentIntent() is itself synchronous in that the operation returns immediately, but the operation on the Terminal reader isn't complete at that point and is still in progress.
worldly nebula
Ah, yeah, no, there's no way to do that. It might take a long time for that to happen; you wouldn't want your code to be paused for that long.
low kestrel
ok
other question... when I send the payment intent to the Reader... I want to display on the reader (WisePos) the customer's name and invoice information... the only way I found to do that is with the setReaderDisplay and then I only have control over line items to display
so I am setting the customer name and some invoice information as line items... just to get it to work
this is not ideal... the use case is I want to send the paymentintent to one of the available readers... this wil lbe at a very busy event with several user's "sharing" the readers we have available... they need to look at the reader to confirm it has the persons correct charge on the reader.
worldly nebula
That's probably not what I would recommend doing, but that's also the only way I can think to make that work.
The Terminal reader's display is not designed to display arbitrary information.
low kestrel
now you read my use case above... what do you recommend?
worldly nebula
I recommend you use a different display to show that information, a display you control.
low kestrel
picture a very busy venue with several users accepting payments (physical checks, cash, and stripe terminal)
and then what reader would I use?
seams like that defeats the benefits of using a WisePos reader?
I do have a different display that I control... the application the employee/users are controlling, but when they send the paymentintent to the reader I would like the card holder to see that the charge on the reader is really "their" charge.
worldly nebula
Not sure I completely understand... what do your POS devices look like? Tablets? Laptops?
worldly nebula
Right, but what is your POS device?
Like which device do you initiate a transaction from?
low kestrel
It is a web application... tablets and laptops both can do it.
worldly nebula
Gotcha, okay, so that's where you would show information like what you're describing.
low kestrel
I don't think I am explaining myself correctly
worldly nebula
If you have multiple Terminal devices you would label them and then use the one displayed on your screen.
So, for example, let's say you had three readers, A, B, and C. The web app would connect to reader B and then say "use reader B to complete payment for <invoice/customer details here>".
low kestrel
yeah, that allows the employee/user to confirm... but then I want the buyer/card holder to also see that the charge on the WisePos terminal device is indeed for their charge.
worldly nebula
Yeah, you show them that information on the POS device screen, not the Terminal reader's screen.
Like you flip the tablet or laptop around and show them on there.
low kestrel
yeah, that does not guarantee anything
if there are 10 POS stations all processing payments of different types that are sharing 3 terminal readers ... I really want the terminal reader to confirm the invoice being paid.
ok... so back to my original question then
worldly nebula
That's not how Terminal is designed to work.
low kestrel
ok... so back to my original question then
worldly nebula
I don't think using 10 POS devices with 3 readers is going to work well for you. You would need to constantly be connecting and disconnecting to and from the readers. It's unlikely to work in practice.
You should have a 1:1 relationship between POS devices and readers.
low kestrel
that is not the real world
but back to my original question
setReaderDisplay let's me set the line item info, but then the reader become stuck in that information... what is proper API flow and some sample code of how I can use the setReaderDisplay along with sending a payment intent.
worldly nebula
What do you mean by "stuck"?
low kestrel
the reader processes the payment fine and Stripe receives the payment just fine, but the reader continues to display the line item information that I set with my call to setReaderDisplay
worldly nebula
Are you talking about pre-dipping? https://stripe.com/docs/terminal/features/display?terminal-sdk-platform=server-driven#pre-dip-a-card
low kestrel
if I don't call setReaderDisplay, it only shows the Total to be charged... the card holder swipes the card, the reader shows a nice success message and the reader returns to a ready state waiting for the next request.
worldly nebula
You can call the cancel action API to clear the display: https://stripe.com/docs/api/terminal/readers/cancel_action
low kestrel
yes, I know that and am using that
see how it says, "Tap, insert, or swipe to pay"
if you do that after calling setreaderdisplay nothing happens on the reader in the flow
worldly nebula
Correct, that's the pre-dipping functionality I mentioned above.
low kestrel
and if you call cancel_action it completely cancels the reader's action.
worldly nebula
If you have a look at the docs I linked above they say, regarding pre-dipping:
Even if a customer pre-dips their card, your application must still complete the full payment flow.
Meaning you have to do everything you would normally do if you didn't call setReaderDisplay.
low kestrel
can you show me working sample code that uses setReaderDisplay in full context along with terminal->readers->processPaymentIntent( and how it should be used.
if you had a wisepos you could play with you would understand what I am asking
if you have working sample code in full context of the api flow for integrating with the WisePos reader that includes setReaderDisplay that would be helpful
worldly nebula
I do have a WisePOS E and I've done this many times. We don't have complete sample code that I know of, but really the main thing to understand is that set reader display is mostly independent of the payment flow.
It's just to display line item info on the Terminal's screen and support pre-dipping.
low kestrel
then show me how you would setReaderDisplay?
worldly nebula
That's all it does.
low kestrel
along with terminal->readers->processPaymentIntent
worldly nebula
Just like in the code sample here: https://stripe.com/docs/terminal/features/display?terminal-sdk-platform=server-driven#set-the-reader-display
low kestrel
I can read the docs... it only shows how to call the setreaderdisplay
I am doing that
worldly nebula
I would call that first, then after that I would call processPaymentIntent when I was ready to actually take payment.
low kestrel
then why does setReaderDisplay say "tap, insert, or swipe to pay"
worldly nebula
Because it supports pre-dipping.
Meaning you can optionally present your card before processPaymentIntent is called.
But you still need to call processPaymentIntent.
low kestrel
ok... For my use case I need to wait to call processPaymentIntent until they have pre-dipped.
I was calling processPaymentIntent right away and it was deleting my line items
FYI... the documentation is great and has a bunch of great messages
great examples
however, they are all in isolation
so it is difficult to see the flow of things
I think I understand now how it works
worldly nebula
I don't think there's any way for your integration to know if a customer has pre-dipped or not.
low kestrel
there is not a method call to see if they pre-dipped to then call processpayment?
worldly nebula
I don't think so. I'm looking, but I don't remember anything like that.
low kestrel
ok... maybe in my POS I have a button that says: "Prepare Reader" and then once they confirm the reader has their info another button that says "Get Payment" so they just ask the card holder/buyer if the info on the reader looks correct.
worldly nebula
Yeah, I can't find a way to do that. The setReaderDisplay functionality isn't designed to accomidate your use case.
Yeah, that might work.
low kestrel
I don't want to buy 10 - $300 readers
worldly nebula
That's more along the lines of how setReaderDisplay is intended to be used.
worldly nebula
I mean, again, I caution you about using 3 readers with 10 POS devices. I don't think it's going to work out well.
low kestrel
if it doesn't I honestly do not understand the point of a reader devise like the WisePos... might as well only have cheap attached readers
I think the WisePos type smart readers are just juvinile in their functionality and need more api's and functionality.
they will continue to improve
I think my use case is a perfect example for WisePos
perfect use case