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 purchase 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).
c) Public Transport regular payments
When Bob enters a bus and is shown a payment terminal they can use the payment protocol to not just pay with a one-time-payment, but instead they may open a payment channel to the bus company which is stored off-line by both the bus company and Bobs wallet.
Should Bob board another bus within the hour the payment terminal can use the open channel to continue their trip. When needed, increasing the amount paid to the bus company. At the end of the day/week/month the bus company can simply settle the transaction on chain in order to get paid.
?) 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 tenant 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 tenant initiates a payment protocol in order to retrieve the next address and maybe amount from the rental 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 cancellation 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.
offline (Bluetooth or NFC or even QR) transaction signing.
Imagine a cold wallet, where you have one wallet that just has an xpub (observer only) and the other is airgapped and has the private keys.
To sign an outgoing transaction you'd then build it on the online wallet and make it get signed by the other one.