You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These are cited as being the user, the merchant, and the payment method. However, a payment method is an instrument, not a party, surely? Wouldn't the party be the payment app provider? And is it necessary to acknowledge that in some cases the payment app provider may not be the same as the party with whom the merchant finalizes the transaction, especially in the case of a basic card payment?
The traditional model for payments is the "4-party" model and I think we'd do well to describe the architecture in this context. The architecture puts the user agent in the role of mediator between the payer (and their PSP - likely the payment app issuer) and the merchant (and possibly their PSP too).
The text was updated successfully, but these errors were encountered:
Agreed that "payment method" is not really a "party." However, I don't think PSPs should be mentioned in the browser payment API spec, because the browser is not communicating to PSPs directly. PSPs can be mentioned in the architecture overview document.
adrianba
added a commit
to adrianba/browser-payment-api
that referenced
this issue
Sep 16, 2016
In TAG review @triblondon said:
The traditional model for payments is the "4-party" model and I think we'd do well to describe the architecture in this context. The architecture puts the user agent in the role of mediator between the payer (and their PSP - likely the payment app issuer) and the merchant (and possibly their PSP too).
The text was updated successfully, but these errors were encountered: