Manage a EMV-like behavior

[Tirodem]

Context

In order to use the product as retail device, we need to manage to have a EMV-like interaction with a specific device (smartphone, or tablet, but that can be a browser tab on a portable monitor) to display informations & payment QR code customer-side. We need a custom order page, allowed only when logged as admin, and displayable on small screen. Note that every retail feature is Lightning only, or Bitcoin with 0 confirmation setted, considering sellers need fast transactions on a physical store. (And of course "cash" payment as it's done by the seller)

Solution

We have 2 use-case :

• I use another device (like a smartphone) as EMV-like device
• I use a dedicated screen (connected to a bootik-POS) as EMV-like device

  I use another device (like a smartphone) as POS EMV-like device

• identify the current retail Bootik session with a POS Seat ID
• log with the POS Seat ID on the POS EMV device
• check /admin/POS/{id} page on the POS EMV-like device browser

  I use a dedicated screen (connected to a bootik-POS) as EMV-like monitor

• identify the current retail Bootik session with a POS Seat ID
• display /admin/POS/{id} page on the EMV-like monitor

  Needs

  POS Seat management

  On a /admin/POS page, Bootik owner shall be able to create, update & revoke seats (+/- accounts) for each physical retail checkout. Each POS seat will correspond to a login / password, allowing to access:

• /admin/product (read only)
• /admin/order
• /admin/pos (that'll redirect to /admin/pos/{id} , depending of the POS Seat session)

  POS EMV page

  About the /admin/POS/{id} page (see Design). This page will be the one displayed on the POS EMV-like device or or on the POS checkout computer through the EMV-like monitor. For this page, we need:

• [ ] a way to display current cart for POS Seat id on /admin/pos/{id}
  • [ ] cross-device when using a smartphone as EMV-like monitor, so we'll need to track (optional) pos seat ID on carts object in database
• [ ] a way to display the simplified order page on the order is created with a POS Seat on /admin/pos/{id}
  • [ ] so we'll need to track (optional) pos seat ID on carts object in database
• [ ] a specific display once order is validated
• [ ] a waiting page displayed after X seconds once the previous order is paid
  • [ ] manage the delay on /admin/pos as a dynamic setting

    POS seat login

• [x] #395
  • [ ] Allow it on more than one device for the POS EMV-like device use case (1 session on the POS checkout computer, 1 session on the EMV-like device)

Design

Pages should be OK on 320*480px devices (to stick with these kinds of monitors : https://www.amazon.fr/dp/B07DK6CKJJ/ref=pe_27091421_487052621_TE_item & https://www.amazon.fr/dp/B07WSVS1Q1/ref=pe_27091421_487052621_TE_item ) Following design are the complete pages, not just a focus.

Basket in progress

Should be refresh on every basket update.

Pending order

Note: on that one, if Bootik has one, we can add Machankura / 8333.mobi bootik phone number or display lightning address

Paid order

Waiting for new order

• logo used here shall be the one from the seller bootik
• should be displayed 5 secondes after "Paid order" screen
  • "5 secondes" might be a dynamic setting ?

[coyotte508]

461 adds a "sessions" collection.

Each POS seat's _id should be a crypto.randomUUID().

We should add a seatId info to that session when a POS user logs in: when they log in, they need to select the POS Seat they're on in the next page.

The DB's session is updated with that seat.

Then they have an easily accessible link to /admin/pos/{seatId} which opens a new tab with the view for the client.

The POS user can then create carts, etc, and the view for the client will update accordingly.

For real time communication:

• In DB we should have a "seat.view" collection, which contains all the data displayed in the view for the client
• The view for the client will call an endpoint on the backend with SSE, using https://github.com/Azure/fetch-event-source lib which has auto-reconnect
• On the backend we can open a changestream on the seat.view collection to watch when it's updated, and send SSE events to the frontend. When the backend endpoint is called, we send the current view data, and then subsequent updates.

That way communication should be instant, there should be no delays.

[AdrienBarb]

Admin can create POS Seat with a login/password. After that, POS Seat can login via the admin form with his credentiels, but what happen if a User and a POS Seat have the same login ?

Should we not have only one Users collection, with a isPos boolean ?

[coyotte508]

@AdrienBarb we have only one Users collection, with a unique index on login, backupInfo.email & backupInfo.npub. Users also have a roleId, a POS could have the point-of-sale role id

[Tirodem]

"that's my fault" comment : I discussed today with Benderrr and I gave him a greenlight for "isPOS" boolean paraeter in user instead on managing per role for the Luxogood MVP, if that allows to go quicker (Luxogood will launch with only 1 physical shop & 1 POS, so... we have time to check before heavy POS seat management). Nothing to add on the other comments, their still legit.