- From: Eiji Kitamura <notifications@github.com>
- Date: Tue, 28 Apr 2020 02:48:03 -0700
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/issues/911@github.com>
My understanding is a typical payment integration works like this: 0. A merchant server holds a key and a secret from the payment handler. 1. As a customer proceeds to checkout, the merchant sends a request to the backend. 2. The merchant server sends a signed request to the payment handler with the total price, reserves a transaction id and receives a payment URL to redirect the customer to. 3. The merchant redirects the customer to the payment URL on the payment handler website. 4. As soon as the customer finishes the payment at the payment handler website, they are redirected back to the merchant with the resulting credential and the transaction id in query. 5. The merchant determines the user with the transaction id (or with a session id?) 6. The merchant verifies the payment by sending the transaction id and the resulting credential. 7. Successful purchase. If we apply a similar scenario to the Payment Request API, the key would be how they pass the transaction id to the PR API. **Question**: is `id` in the [`PaymentDetailsInit`](https://w3c.github.io/payment-request/#paymentdetailsinit-dictionary) the property a merchant can use to specify a transaction id? I thought of `data` property of [`PaymentMethodData`](https://w3c.github.io/payment-request/#paymentmethoddata-dictionary), but it has to be constructed before displaying the payment button (preferably) and the total price may change at the point the customer press the button. Hence being able to pass a transaction id in the `detailsPromise` after the `.show()` is called would be efficient for merchants IMO. Let me know what is the best solution here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-request/issues/911
Received on Tuesday, 28 April 2020 09:48:16 UTC