Haven't thought of this design much but just as users can pay others, they should be able to do a request_payment that creates a payment in pretty much in the same way, i.e. we create and fill-in a PaymentDetail with a PaymentState::Requested(or similar) and allow the user receiving the request to confirm.
One use case is the swap of fiat to crypto, fiat is the off-chain product being sold but the "seller"(someone buying crypto) initiates the trade that the crypto holder can accept to proceed with the usual escrow or accept_and_release(basically a normal transfer) if there's a trust relation between the two parties(or the initiator is simply trustful).
Another use case this could be good for is subscriptions, someone providing a service can regularly issue the payment request and the user just needs to accept. Perhaps later a separate subscriptions_pallet can be the initiator of those requests and have an auto release mechanism if a user decides to trust the merchant.
Haven't thought of this design much but just as users can
pay
others, they should be able to do arequest_payment
that creates a payment in pretty much in the same way, i.e. we create and fill-in aPaymentDetail
with aPaymentState::Requested
(or similar) and allow the user receiving the request to confirm.One use case is the swap of fiat to crypto, fiat is the off-chain product being sold but the "seller"(someone buying crypto) initiates the trade that the crypto holder can
accept
to proceed with the usual escrow oraccept_and_release
(basically a normal transfer) if there's a trust relation between the two parties(or the initiator is simply trustful). Another use case this could be good for is subscriptions, someone providing a service can regularly issue the payment request and the user just needs to accept. Perhaps later a separatesubscriptions_pallet
can be the initiator of those requests and have an auto release mechanism if a user decides to trust the merchant.