Usecases:
a) Payment Provider
The traditional usecase.
A buyer wants to pay for their purchase in a brick&mortar store.
The merchant uses a payment provider and their point of sale web solution on his tablet.
To initiate the purchage the Point of Sale (PoS) terminal shows a QR code and activates its NFT.
The user scans the QR code, or hovers over the NFT to instruct their phone to start processing this payment.
The phone opens a channel with the payment provider to negotiate the payment method and details, builds a transaction and sends the transaction to the payment provider for approval and broadcast.
Optionally, the user approves of the payment details before the phone signs and finalizes the payment.
b) Wallet to Wallet
A buyer wants to pay for their purchase in a brick&mortar store.
The merchant is using their own phone with a simple wallet.
Other that that, identical to usecase (a).
?) Payment via WebService
A buyer wants to pay for their purchase to a merchant that they found via a web-service.
The merchant uses the service to provide the payment request under the understanding that a fee is paid to the web-service.
The merchant indicates what amount they want to get paid in a webpage of the service. According to their contract the webservice takes a small fee as well, the merchant approves the request.
The service shows a QR to the buyer, who uses that info to figure out how to reach the service over the Internet.
The phone opens a channel with the payment provider to negotiate the payment method and details, builds a transaction and sends the transaction to the payment provider for approval and broadcast.
Optionally, the user approves of the payment details before the phone signs and finalizes the payment.
The transaction will pay both the merchant as well as the service.
?) Comment (op-return)
?) Prepare future payment
The payee and payer are in a contract which requires regular payments. For instance an employee and boss paying a salary, or a tennant paying their rent.
In contrary to most usecases, we don't actually expect that the payment is completed in the time that the payment protocol runs. Instead, one side initiates the payment to the other with the sole intention of directing a future payment and providing details for this future payment.
So the worker wanting to get their salary initiates a payment protocol in order to provide an address to the payroll department for the next payment cycle.
The tennant initiates a payment protocol in order to retrieve the next address and maybe amount from the rantal service, to be completed at the time the rent is due.
cash-back or other token saving schemes.
in short, a user pays for something, like a hotel, and after that event has taken place and no cancelation is possible anymore, the merchant sends some tokens to a previously negotiated "return address". We want to have a bool indicating that the merchant can accept tokens and then the wallet replies with either a token or a bch address.