Re: [webpayments] [Architecture] Payment App is a term used in EMV to describe the applet stored in SC (#31)

I think there is a misunderstanding about my intentions for the relationship between a payment method, payment app and payment instrument.

User's don't care about payment methods and it's arguable whether they care about payment instruments. The purpose of the payment app is to abstract these away. Users who want control over specifically which instrument they use will use apps that give them that choice.

Similarly the payee (merchant and/or their PSP) isn't too concerned about which app the user selects to make the payment, they care what payment methods it supports because they need to support one of these. 

*__sidenote:__ One exception would be the merchant that has their own app and would like users to use this because they have proprietary data exchanges as part of the payment method that allows them to do things like process loyalty transactions etc. This is effectively a closed loop system where the merchant's app defines it's own payment method which is preferred over generic methods if available. "Available" in this context means the user is using the merchant's app to pay on the merchant's site.*

To re-state @dlongley 's steps for clarity:

Pre-steps: The user installs a payment app. On a mobile device this may be through the mobile platform's app store on a desktop it may be through a browser API call initiated when they visited the website of the app publisher. Let's assume the app publisher is the user's bank.

The user has multiple "funding sources"/"payment instruments" through this bank; a VISA debit card, a MasterCard credit card, direct debits from their bank account and the bank's proprietary loyalty points system (let's call it BankBucks).

The payment app (through the registration process) supplies the payment mediator with a manifest that provides, at a minimum, the publisher's origin and the supported payment methods:
 - EMV Tokenised Visa Debit
 - Legacy MasterCard
 - ACH Direct Debit
 - BankBucks

In this case the Legacy MasterCard payment method is a very simple protocol where the payment app simply returns the clear PAN, expiry and CVV2 to the merchant however the EMV Tokenised Visa Debit payment method has defined a mechanism whereby the app returns an EMVCo tokenisation scheme compliant token. The bank could have supported a "Legacy Visa Debit" payment method for the Visa Debit card too but chose not to because they feel enough merchants support the tokenised payment method and they don't want to take on the risk of sending the debit card numbers in the clear.

Step 1: The user visits a website, adds some items to a shopping cart and wishes to checkout. The merchant site calls the payment API passing a payment request object that lists the payment methods they support.

This merchant is a rewards/loyalty partner of the user's bank so the supported methods are:
 - EMV Tokenised Visa Debit
 - ACH Direct Debit
 - BankBucks

The merchant doesn't support the "Legacy MasterCard" payment method because they have chosen to not put their website in scope for PCI DSS. If they make a call to the payment API and there are no payment method matches then they simply direct the user to a payment page hosted by their PSP where the user is able to make payments using legacy payment methods or even directly through a traditional payments page.

*__sidenote:__ We probably need to discuss a way in which the merchant can specify a weighted preference for the supported payment method.*

Based on the payment methods supported by the merchant and the payment methods supported by the installed payment apps on the users device, the payment mediator prompts the user to select a __payment app__ to use for the payment (N.B. the user chooses between payment apps not payment instruments, funding sources or payment methods).

Let's assume our user has a variety of apps installed but selects the bank app we described in the pre-steps.

Step 2: @dlongley 's step 2 is not required anymore as the user has already selected their payment app

Step 3: Payment Mediator invokes the Payment App passing it the payment request (trimmed down so that only the data relevant for the payment methods supported by that app are present).

To further illustrate this through examples; on a mobile device the payment mediator will be the mobile OS and the selection of a payment app will be the familiar app selection pattern, on a desktop the browser will likely be the mediator and will prompt the user to select a payment app.

Step 4: The payment app helps the user make their payment using their selected payment instrument/funding source.

The user is now interacting with UI provided by the payment app. In this case it is their bank's app that they selected and the app has prompted the user to login (perhaps through a fingerprint scan on their mobile or an OTP).

The bank's app fetches the latest balance for all of the user's funding sources. The user doesn't have enough BankBucks points for this purchase but is given the option to split the payment and use their points for a portion and pay the balance using an ACH direct debit/their VISA card.

The user decides to use their VISA Debit card to make the balance of the payment and the app makes a call to the bank's tokenisation service for an EMVCo compliant token for that card.

The app returns a response to the website with the details of the payment, a portion paid via BankBucks points and the remainder via the EMV Tokenised Visa Debit payment method.

The merchant takes the response and passes it to their PSP who processes the two payments.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/31#issuecomment-163115817