Skip to content

How it Works

Jump to bottom
ianbjacobs edited this page Dec 15, 2015 · 13 revisions

Here we outline the different steps envisioned under this architecture:

  • Registration of Payment Apps
  • Payment Initiation

Registration/Installation

In this model, "registration" is the process of communicating Payment App information to the Payment Mediator. At a minimum, this involves information about the Payment Methods that the Payment App supports. Depending on the deployment scenario, registration may also involve installation of software (e.g., installation of a native mobile platform payment application).

Examples: 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 the user visits the website of the app publisher. For this example let's assume the app publisher is the user's bank and the user has logged into their internet banking on their desktop, the website has called a registration API and the payment mediator (built into the desktop UA) has registered this new payment app. The user has also installed the banks mobile app on their smartphone.

The registration API call in the desktop browser may look something like this:

navigator.payments.registerPaymentApp({
    "id" : "https://mybank.com/app/" //Some debate around this property. See Issue #14
    "label" : "My Bank",
    "icon"  : "https://mybank.com/icons/app.png",
    "supportedPaymentMethods", : [
        "https://visa.com/emvco_tokenized_debit/", 
        //"https://w3.org/payments/methods/legacy_card/visa_debit/", excluded due to security concerns - see below
        "https://w3.org/payments/methods/legacy_card/mastercard_credit/",
        "https://nacha.org/directdebit/", 
        "https://mybank.com/bankbucks/", 
    ],
    "appstoreId" : "87345656", //Platform specific extension for iOS
    "playstoreId" : "com.mybank.paymentapp", //Platform specific extension for Android
    "endpoint" : "https://mybank.com/app/v2",
});

note: the mobile os platform specific extensions might allow the API call in a mobile browser to trigger a prompt to the user to install the mobile app from the app store.

On mobile some of the app meta data would be provided in the app manifest or whatever platform specific mechanism is used to provide app meta-data (such as supported custom-URL protocols and intents etc) or not be required (such as for label and icon).

The label and icon would be used by the payment mediator when prompting the user to select a payment app.

In our example let's assume 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) supplied the payment mediator with a manifest that provides, at a minimum, the publisher's origin and the supported payment methods (identified by their payment method identifier):

In this case the Legacy MasterCard payment method is a very simple protocol (defined by the W3C during the Web Payments standardization process) where the payment app simply returns the clear PAN, expiry and CVV2 to the merchant.

However, Visa have defined the EMV Tokenized Visa Debit payment method which has a mechanism whereby the app returns an EMVCo tokenization scheme compliant token instead of the clear PAN. This requires the app to either store this token of fetch it from a token server as required. To support this payment method the payment app must be capable of doing this and understand the format of the request and response messages it must process and return.

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.

Payment Request

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:

The merchant doesn't support the "Legacy MasterCard" payment method because they have chosen to not put their website in scope for PCI DSS so they don't support methods that send card data in the clear.

sidenote: The merchant could offload this entire process to their PSP by allowing the PSP to call the payment API from an iframe. This implies we should allow calls to the payment API even if they are not from the top-level browsing context however this would need to be carefully controlled for security.

If the merchant makes 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. i.e. Using the payments API does not have to replace their existing process it simply offers an upgrade of the experience for users that are able to exploit it.

sidenote: There should be a way that the merchant can influence the choice of payment method after a user has picked a payment app so this is not entirely under the control of the payment app. The risk is that payment app publishers will try to maximise the fees they earn at the expense of the merchant while the user is potentially ignorant of this even happening. At a minimum the merchant should be able to incentivize the user to use specific payment methods by surfacing price differences that may be available during app selection.

TODO: Log an issue to track this

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

TODO: Describe the process if the user has no payment apps installed

Step 2: The payment mediator invokes the payment app selected by the user, passing it the payment request (trimmed down so that only the data relevant for the payment methods supported by that app are present).

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 through some custom browser UI (hopefully better than the client certificate selection UI) which will use the label and icon provided by the app during registration.

Step 3: 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) if they are not already authenticated with the app.

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.

sidenote: the ability to split a payment between two payment methods will likely not be supported by the standard in v1 as this requires consideration of a number of complex failure scenarios. Rather it is expected that PSPs that wish to support this will wrap it in their own custom payment method (such as BankBucks in this case). The response will be a BankBucks format response but will have another payment method response embedded instructing the PSP to split the payment. The PSP, knowing how to interpret BankBucks responses will know how to extract the other payment method response and how to deal with the complex failure scenarios should one payment method fail.

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

Previous section: Architecture components

Next section: Deployment Examples.

Home

A Payments Initiation Architecture for the Web

Clone this wiki locally