Observations

This page is a working page to keep track of the emerging thoughts from the Flows Tasks Force as it reviews each of the legacy flows to see how well the proposals cater for the interactions required.

#3DS & Strong Authentication The specification does not address authentication directly, though these interactions can be mediated outside of the API or within a custom Payment Application.

#Protection :ref issue #11 The specification does not address protection of card details directly, though though these details could be protected with a custom Payment Application. This would require additional payment method to be defined and supported by the merchant.

#PayPal Many of the existing PayPal flows are not pure 'push' payments. The payment is authorised in the browser, but the execution of the payment is initiated from the merchant site using a REST, SOAP or NVP request. Therefore the merchant will need to be able to handle these types of requests themselves rather than receive a generic acknowledgement message. We will need to ensure that the flows can therefore be proxied by a Merchant PSP as the aggregator of many payment methods.

The other PayPal flows are pure HTML hyperlinks that invoke a PayPal payment page. These don't allow for split authorisation/capture as is expected in various situations, e.g. goods that are shipped later.

#Masterpass This flow type is not supported by the WG flows and significant rework the MasterPass wallet flows would be required to fit in with the proposal. It needs to be established if it is the aim of the WG to 'Shim' these legacy flows or to petition the wallet providers to accelerate adoption of the standards.

#PSP Hosting A key part of today's ecosystem is the ability for merchant to delegate the entire processing of all payments their Payment Service Provider. This simplifies the merchant integration in that it doesn't need to understand the details of each different payment type and how to handle those. Another important factor is the ability for a very simple technical integration, e.g. just a URL link to initiate the payment.

In the target model the ability for this handoff should remain such that the manifest and flows should be able to flow to an origin other than this that first initiated the payment. Whilst the PSP could be considered the merchant in this case, it is important to see that this origin will be aggregating payments for many merchants and consider what security/privacy challenges this may imply.

Payment status

Most of the conversation to date at the WG appears considers the payment as an atomic action, however a number of common payment statuses exist beyond pure SUCCESS & FAILURE. For card and other transaction types, there are separate steps for AUTHORISED, CAPTURE (to request settlement), SETTLED, REFUNDED. In addition, there are a asynchronous requests types where payment status updates ill be notified via a callback.

Examples:

1. PayPal has separate Authorise and Execute steps. Execute maps to CAPTURE. Execute is probably the more sensible generic terms to use.
2. Credit Transfer is an asynchronous settlement, where the settlement can take a number of days. The merchant will need to decide if the delivery of services is low enough risk to do immediately or if it needs to wait for full settlement to occur.
3. Many payment systems support a combination of the AUTHORISE and CAPTURE/EXECUTE steps, often called a SALE. Perhaps the API needs to recognise this somehow to allow the merchant to request an AUTHORISATION (for the case of deferred delivery of goods - e.g. backorder of stock or hotel booking) or a SALE ( in the case of immediate delivery, e.g. good being shipped immediately)

It is suggested that these should be modelled in the API as generic statuses with an extensibility framework.

Risk Processing

Many deferred payment methods (or those that allow reversal in dispute) need to support risk processing, so the merchant can decide if it wishes to accept the payment credentials, e.g. blacklisting of credit cards that are used frequently or correlation with geographic location. Items such as address verification are also used. The API flows need to support insertion of these checks into the flow at the appropriate point and also the availability of credentials to perform the check, e.g. location (IP address?), addresses (email, shipping), identity. This obviously has implications of privacy, so the acceptance of information transfer will be to be part of the UX.

Regulatory requirements

Emerging regulations like PSD 2 need to be considered. For example PSD 2 calls for 'Strong Authentication' of payment initiation.

#Payment Settlement Although the payment settlement is not part of the API as such, the different settlement channels will add entry requirements at the API level. To illustrate this comment, a small example: if the payment is executed through a credit transfer or a direct debit, the API must capture the account details of the payee and the payer, so that the payment may be executed. In today's ecosystem, in most case web merchants are sending their bank account information through the purchase confirmation, as no possibility exists to initiate the payment directly or alternatively, the merchant's PSP could provide a link to the bank interface to execute the payment. Remark: we should probably document this latter flow as an additional flow (use today in Belgium already).