#MrZ

1 messages · Page 1 of 1 (latest)

tough boneBOT
spiral ore
#

hello! i'm not sure I understand - typically you would use the WisePOS E to collect the payment, not to scan a QR code and then make payment. Can you describe in more detail what you're trying to do?

kindred rapids
#

yes, we use WisePOS E to collect the payment. When the customer finishes his selection using an iPad, normally, the next step is to click "Pay", connect to the "WisePOS E", then ask the customer to use his card to pay. But we only have one "WisePOS E", when more than one customer clicks "Pay" at the same time, too easy to get the wrong payment.

Here is the thing we want to do. When the customer clicks "Pay", only generates a QR code for him, then he can call the clerk over. The clerk uses WisePOS E to scan the QR code and then starts to collect the payment.

tough boneBOT
vast echo
#

Hi @kindred rapids I'm taking over this thread

kindred rapids
#

Thanks @vast echo , is my idea possible?

vast echo
#

I don't think the camera in WisePOS E is open for integration at this moment.

kindred rapids
#

Do you mean the clerk can reconcile the payment on WisePOS E before finalizing the payment?

#

if we use the capture_method="manual"

#

or do we need to add a step on the iPad, after the customer uses his card by WisePOS E?

vast echo
#

Hmm, one sec, this may now help with your problem.

#

Any chance you can get more readers for your staff?

kindred rapids
#

Thank you, Jack, But adding a Reader can't solve this problem unless a fixed Reader is assigned to each iPad, but this will bring more waste of resources, in fact, it is not busy all the time.

vast echo
kindred rapids
#

The clerk still needs to find who is connected at this time😂

#

ask and then find out the right people

kindred rapids
#

The real issue is to find out who is the right customer on the current Reader process. Rather than concurrency payments. I believe the Reader can handle it very nicely when concurrency payments come.

vast echo
kindred rapids
#

When a payment intent is processed, the clerk can see the customer information(i.e., customer ID) on the Reader?

vast echo
kindred rapids
#

ok, so the clerk still does not know who is the current paying person. the issue can not solved by this way.

#

In the current workflow, the clerk carries the Reader and waits to receive payment. When a customer initiates a payment, the clerk needs to find the customer and use Reader to assist the customer to pay.

vast echo
#

Is your business based in US?

kindred rapids
#

We hope to optimize this process. When the customer needs to pay, instead of directly initiating the collection to Reader, first contact the clerk, and the clerk will initiate the collection in some way. I saw that WisePOS E has a camera, so I considered triggering it by scanning the QR code with the Reader.

kindred rapids
vast echo
#

Anyway, I'd suggest you to look at the fail_if_in_use param that I shared earlier so that the other terminal application can't connect to the reader if it's already connected, and you might also need to implement something on your terminal app to reflect the connection status so that your staff knows which terminal app is connected to the reader/