Re: [w3c/browser-payment-api] What semantics is needed for payment method specific data? (#143)

I may be misinterpreting the question here but here's my thinking.

- Payment method identifiers are keys
- These keys have a many to one relationship with a payment method
- All of the details about how a payment app processes a payment request and builds a payment response and what a website must do with that response is published in the payment method specification or defined somewhere else that publishers can find it.
- The payment method specification also lists all of the identifiers that are currently tied to the payment method that they describe.
- Additional semantics MAY be implied by which identifiers (from the set defined in the payment method specification) are used.

i.e. Listing any of the payment method identifiers for a payment method as supported implies that the payment method itself is supported (i.e. the website/payment app has seen the payment method specification and can process requests and responses formatted according to that spec) but which identifiers are listed indicates to the other party some additional information that is payment method specific.

### Examples
**Payment Method**: Basic Card Payment
**Payment Method Identifiers**: 
 - http://w3.org/payments/PMI/card/visa
 - http://w3.org/payments/PMI/card/mastercard
 - http://w3.org/payments/PMI/card/amex
 - http://w3.org/payments/PMI/card/diners
 - http://w3.org/payments/PMI/card/cup

**Details**:
If a website claims support for basic card payments they will use one or more of these identifiers. The specifics of which identifiers are used indicates which card brands they accept.

No special processing is defined for the payment app, it simply returns a response populated with the relevant data.

It is assumed that the website will use the data in the response to initiate a card payment via their normal acquiring channels.
 
**Payment Method**: Example Payments
**Payment Method Identifiers**: 
 - http://example.com/USD
 - http://example.com/EUR
 - http://example.com/ZAR

**Details**:
If a website claims support for example payments they will use one or more of these identifiers. The specifics of which identifiers are used indicates which currencies they accept.

Example Payments may define special processing that a payment app must perform when it gets a request such as a call to a tokenisation web service, downloading of a public key and encryption of the data, or even processing of the payment itself (if this is a credit push payment method).

The processing required of the website when it gets the response will also be defined by the specification and may be very specific (if Example Payments is a proprietary system that has complete control over the payments process) or just general guidance (if Example Payments is a more open system and the processing instructions are more generic like "submit the XYZ data to your local Example Payments gateway".


The data that is in the payment method specific parts of a payment request message  will be formatted according to rules in the payment method specification. For payment apps to be inter-operable they need to follow the rules defined in the payment method specification.

Interoperablity is left to the payment method designer to deal with. For example it's quite possible that there will be closed schemes that will write a payment method specification for their scheme but to support the scheme will require that a payment app go through some registration process.

If the payment method has special business processing that payment apps must do then they will likely define that in the payment method specification to.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/143#issuecomment-213408255