Proposal: On-chain Peer to Merchant (P2M) Configuration
Opened this issue · 1 comments
As described in DIP 158, the P2M flow involves redirecting a customer from the merchant site to their customer VASP for payment approval. Recap:
The redirect URL is likely to be used in the Web Redirect flow which means that the customer will be redirected from the merchant's checkout page to the wallet's website to review and approve the payment.
The table below specifies the fields that should be encoded into a series of URL parameters appended to the query string.
| Field | Type | Required? | Description |
|---|---|---|---|
| vasp_address | str | Y | Address of receiving VASP. The address is encoded using bech32. For Diem addresses format, refer to the "account identifiers" section in DIP-5. |
| reference_id | str | Y | A unique identifier of this payment. It should be a UUID according to RFC4122 with "-"'s included. |
| redirect_url | str | N | Encoded URL used by the wallet to redirect the customer back to the merchant |
Customer VASP configuration (like redirect_url) does not exist yet
The redirect_url, and other Customer VASP configuration, is never set, and never stored. This onboarding of Customer VASPs via a registration step is required for any future P2M flows.
Solution
A DIP describing a Customer VASP registration step that sets its configuration on-chain within Move, so that Merchant VASPs are able to retrieve and send said P2M configuration data for the Web Redirect Flow. This includes but is not limited to redirect_url, image_url.