#manuel_best-practices
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1431263361957494835
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
๐ Hi there! Let me take a look
Out of interest, are there any problems you're seeing with this approach currently?
In production there is an issue sometimes that are related to switching between TapToPay and M2 devices. I know that is not possible to have both type of readers connected at the same time (the barista have to switch the device in settings if needed) because the Terminal instance.
So I like to know some recommendation on how to manage this setup (both card readers) in the same POS.
Hi there, taking over for @echo narwhal as they had to step away
Looking into this now
Got it. Just for context, why do you need the TapToPay integration? Doesn't the M2 card reader also support tap to pay?
Initially, M2 was only managed using the Kotlin plugin. TapToPay was later implemented, using the mek_stripe_terminal library for that. Language convenience issues (Dart vs. Kotlin)
Sorry for the late reply, juggling a couple of threads. It's not a common use case, I haven't found any guidance for managing multiple readers on the same device.
You've probably considered this, but the two options here are to use two separate devices, or to build a single integration with M2 with the more recent TapToPay feature