Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Introduction to describe actors better #121

Closed
adrianhopebailie opened this issue Apr 4, 2016 · 1 comment
Closed

Update Introduction to describe actors better #121

adrianhopebailie opened this issue Apr 4, 2016 · 1 comment

Comments

@adrianhopebailie
Copy link
Collaborator

In TAG review @triblondon said:

three key parties in every transaction

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).

@rsolomakhin
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants