-
Notifications
You must be signed in to change notification settings - Fork 135
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
What component does the payment method intersection? #103
Comments
+1 to using payment mediator consistently as the primary component. |
The browser API spec refers to user agents (not mediators) which is correct as this is a specification for user agents. #137 incorrectly suggests changes to the browser API spec. The browser API spec MAY refer to the role of payment mediator as a role that the user agent assumes in implementing the API but we should emphasize that some of the functions defined in the spec are not functions of a payment mediator they are functions that are only defined for user agents. The architecture document should describe the role of a payment mediator which the browser API spec could reference |
While I believe the mediator is the primary entity that will match identifiers, I propose that we define the matching in the PMI spec. The complexity of the matching algorithm will depend on the semantics we build in (e.g., grouping and subclassing will increase the complexity). |
Matching algo will be defined in the PMI spec |
The architecture document reads...
I believe this should read "The Payment Mediator...."
In addition we should be clear that the payment mediator may optimise the experience, applying knowledge such as user preferences (e.g. preferred payment method) and environmental factors (location).
Note, I will submit a PR post FPWD
The text was updated successfully, but these errors were encountered: