-
Notifications
You must be signed in to change notification settings - Fork 14
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 1.0 The proposed flows don't address 3DS authentication directly, although there is nothing stopping these interactions occurring outside of the proposed flows. This will obviously add complexity for merchants for integration, likely result in different experiences and be less intuitive to users. It would make sense for the WG to look to create reference implementatons either for 3DS 1.0 or the forthcoming 2.0 specification http://www.emvco.com/specifications.aspx?id=299
#Tokenisation :ref issue #11 The proposed flows don't allow for transient tokenisation of card details in their vanilla form. People are likely to be faimilar with the pre-tokenisation as used by ApplePay, where the tokens are generated in a client OS prior to payment and presented at payment time. In transient tokenisation, the token is generated when the user enters their card details at payment time. It is a mechanism to prevent PAN details transmitted on the wire to the merchant.
In this situation, the tokenisation algorithm and key must to shared/exchanged with the Merchant PSP at payment time today, meaning the Merchant PSP has code running in the user-agent.
One option to support this might be to allow registration of a Payment Application that supports tokenisation as part of the payment flow. This however would mean that it would not have access to the card details stored in the existing wallets, e.g. part of form fill or other PAN based wallet.
Another option might be for the architecture to support a payment 'pipeline' where the primary Payment Application provides the details to a secondary Payment Application for additional processing. This might allow for different payee and payer PSPs to participate in the flow at the client side.
#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.
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:
- PayPal has separate Authorise and Execute steps. Execute maps to CAPTURE. Execute is probably the more sensible generic terms to use.
- 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.
- 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.
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.
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).