Passing a transaction id to a payment request

[agektmr]

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 the property a merchant can use to specify a transaction id? I thought of data property of PaymentMethodData, 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.

[ianbjacobs]

Hi @agektmr,

The design intent was that the merchant could use 'id' is for a transaction id. When not provided, the user agent generates a UUID. It seems that the attribute is read-only.

Is your observation that there are use cases when the merchant might only know a transaction id after the initial construction? Could you say more about those use cases? Thanks!

Ian

[agektmr]

I'm not aware of concrete use case of this, but I have seen somewhere that detailsPromise was defined so that a merchant can let the browser wait until they determine the total cost. This means at the same time that the merchant won't know the transaction id until then. And the merchant has to be able to pass a transaction id along with the PaymentDetails object by resolving detailsPromise. That's why I asked.

BTW, I was looking at PayPal integration as an example, but my understanding is this is very common pattern used across multiple payment services.

If id of PaymentDetailsInit can be used as a transaction id, that's great. I'm writing a new document and would add this pattern there, but if there's some kind of mention in the spec, that would be even more obvious for implementers.

[ianbjacobs]

@marcoscaceres, @rsolomakhin, @danyao, I am happy to write a pull request for an informative note to mention the use of id as a transaction identifier. Seem ok? Ian

[danyao]

Adding an informative note about id in PaymentDetailsInit sounds good to me.\

I'm not aware of concrete use case of this, but I have seen somewhere that detailsPromise was defined so that a merchant can let the browser wait until they determine the total cost. This means at the same time that the merchant won't know the transaction id until then. And the merchant has to be able to pass a transaction id along with the PaymentDetails object by resolving detailsPromise. That's why I asked.

This would involve adding id to PaymentDetailsUpdate. It seems OK, but I'd like to see evidence from a real world use case before we change the spec.

[agektmr]

I thought PaymentDetailsInit is inherited by PaymentDetailsUpdate but it isn't. Then we need a spec change. I'll work with the partner who might need this feature and see how I can provide evidence.