Closed mgiuca closed 4 years ago
This highlights the difference between this API and the Payment Request API.
The latter is not invoked by a website that already knows what backend it is talking to as the website shouldn't know which payment methods the user has (for privacy reasons).
I'm not super familiar with Payment Request, but my understanding was that the website absolutely needs to know the backend it's talking to, since the website and payment method need to do a bunch of behind-the-scenes communication once the purchase has been approved by the user. In this regard, I see PR and DG APIs as being in sync.
absolutely needs to know the backend it's talking to, since the website and payment method need to do a bunch of behind-the-scenes communication once the purchase has been approved by the user
This only happens after the PR API call has completed. At the time the PR API is invoked the website presents a set of payment methods it supports. The browsers compares this with the set that it knows are available to the user and calculates the intersection of those sets.
The browser then presents any payment apps that can handle payment methods in the intersection to the user to choose as the app they wish to use.
If the website already knows how the user is going to pay then what is the value of invoking that payment app via the API?
From a private discussion with @rsolomakhin:
I'm not sure. That significantly complicates the API, since it means all of the other methods need to have a
paymentMethod
parameter. (Since otherwise it wouldn't be clear which backend you're talking to.)Since this would only be useful for testing, I'm leaving it out for now. We can discuss further on this issue.