domwoe
June 20, 2023, 7:51am
14
kristofer:
Got it. The “background notification” is tricky still if I am not missing something.
I am assuming this:
Buyer uses any wallet capable of doing a ckBTC transfer. This means we have no control over that part of the flow.
Buyer interacts with a QR code representing the seller account. That means we cannot trigger anything from the frontend at transaction time. The buyer don’t interact with a frontend at all, they just … transfer.
That leaves us with reacting at the backend. Which means reacting to events or if there are no events, use timers/polling.
Got it. I agree, and think the idea of a payment gateway would be a good approach if you’d want to commercialize and make it scalable. You can apply for a grant afterwards
For a demonstrator, I think the timer approach would be sufficient as well, and we could let the merchant switch it off/on or even make the interval customizable as an advanced setting.
kristofer:
That leaves us with reacting at the backend. Which means reacting to events or if there are no events, use timers/polling.
Would it be acceptable to let the seller QR code not represent the seller address but instead a url to the seller frontend page? Then the notification can be solved easily:
Buyer wants to pay for something at the farmers market
Buyer scans merchant QR code, a web page opens
Merchant logo etc
“Enter amount to transfer” (calculator layout)
Buyer enters amount to transfer
Webpage initiates transfer, buyer signs with wallet
Spinner, “transfer in progress”
Transfer complete, webpage interacts with notification canister that sends text
Ideally, transfer and notification would be packaged together at step 4, the buyer also paying for the little amount of cycles needed for the notification.
This is also a reasonable approach but depends on a wallet standard that we don’t have in place yet (See: Assigned: RFP-7: Wallet Standard Reference Implementation ). Hence, I wouldn’t want to go that route here.
1 Like
