Introduction
This is my view of the current Secure Remote Commerce (SRC) specification (v0.9) which EMVco have published into the public domain for wide review and comment. I’ll try to explain what SRC is, how it might work, and what it means for the work of the Web Payments Working Group (WPWG) at the World Wide Web Consortium (W3C). Happily, my main conclusion is that I think the two ecosystems (SRC and Payment Request) play nicely with each other. I think that the open architecture of Payment Request and Payment Handler lend themselves well to supporting one or more SRC payment methods below.
What is Secure Remote Commerce?
At its heart, SRC is an attempt to combine authentication of payer and payee with a desire to have privileged, persistent payment data move only between a cardholder and their issuer. In particular, it attempts to move the traditional card number (Personal Account Number or PAN) away from the merchant. It can therefore be seen as an evolution of two other EMVco specifications – network tokenisation and 3D secure for authentication.
Figure 1 – SRC takes away card numbers and replaces them with an SRC payload
It should be stated from the outset that as the spec currently stands, it works only with CARD payments – specifically those with a long 16-19 digit Personal Account Number (PAN) which conforms to ISO 7812. It is not currently set up to work for non-card payments which are prevalent in many payments markets. Although I’ll spend the rest of this blog talking about transaction processing, it’s worth noting that that SRC describes a whole ecosystem including how to register the various participants with the SRC systems, how to enrol cards and cardholders and how to bind identities and credentials together. This makes the specification very big and a little daunting to read.
Roles
Like many specifications, SRC begins by defining a new set of roles and actors. The main new ones we need to talk about are the SRC Initiator (SRCI) and the Digital Card Facilitator (DCF), but to be honest it’s easiest to start by talking about the transaction flow to illustrate what these different roles are doing.
To begin at the beginning
Caveat: I’m assuming everyone is already registered/enrolled in the flow that follows, and this is consumer initiated. The spec says it can support merchant initiated transactions, but then says it doesn’t say how in this version. Everything starts with the SRC trigger, which the spec says can be a button, a gesture, a voice command, or a funky dance move[1]. Whatever it might be, the trigger can be found in what the specification calls a Digital Shopping Application (DSA), but which you and I would probably call a website or an app, and to keep things simple, I’m going to say here that the shopper pushed a button.
Figure 2 – Orchestrating the SRC dance
Once an SRC transaction has started, the specification assumes that a bunch of assurance and validation takes place of the cardholder and the cardholder’s device (which might be a phone, a PC, a smart TV, or a car. Maybe’s it’s their fridge.) How this happens isn’t tightly specified, but it seems that it’s the responsibility of the SRC Initiator to make sure that information is collected that allows a Customer Profile Request to be sent to EACH[2] SRC system. Let’s assume for now that the assurance works smoothly (perhaps via Web Authentication API) and that the SRC Initiator is now content that it’s dealing with the real consumer. The Customer Profile Request (step 1 above) is then sent to each SRC system in turn, and those SRC systems each return a Customer Profile Response, which includes all the stuff you need to build a list of digital cards that can be used in this payment, including card art and masked PAN. The various SRC systems go off and do this via the Digital Card Facilitators (step 1a), who are providing the digital representations of the underlying cards. I don’t think that the cardholder has to have any interaction with the DCF – in other words, the SRC Initiator can handle all the user interactions – but the spec also provides for a DCF handover method, so there’s probably another flavour of this flow in which the user jumps into a UX from the DCF later in the flow. The SRC Initiator then has to present all of these cards in a SRC Candidate List, which enumerates all the SRC enrolled cards associated with the cardholder.[3]
Figure 3 – The SRC candidate list shows the cardholder all their possible SRC payment choices
The cardholder chooses from the list and that then allows the SRC Initiator to send a Checkout Request (step 2) which can provide more information about the specific card that’s been chosen, like associated delivery addresses, billing addresses and lots of risk data. My reading of the SRC spec is that this step might be optional. It’s probably worth highlighting that the order in which different cards will be arranged on the candidate list is based on the most recently used cards, according to the SRC specification, whereas the payment handler API takes the approach that the user can control the ordering. Once the consumer is completely ready to buy with a selected card, the SRC Initiator sends a Payload Request (step 3), which the SRC system replies to with a Payload Response (step 3a), which contains dynamic data. It’s this Payload Response that allows the SRC Initiator (and so finally the merchant) to create a traditional authorisation request – how to get from Payload Response to auth request is beyond the scope of the specification so will presumably depend on the implementations of each of the SRC systems in question. Once the authorisation request has gone off (via the merchant’s gateway/PSP/acquirer) and there has been an authorisation response (like “authorised” or “declined”), the SRC Initiator is supposed to send a Confirmation Request (step 4) to the SRC system to signal the end of the payment transaction, and received a Confirmation Response in return.
Implications for Payment Request and Payment Handler
As I said in the introduction, I think that SRC can work very well with the WPWG’s payment request/payment handler specifications.
Figure 4 – fitting SRC and Payment Request together
The role of SRC Initiator can be played by a payment handler. It could be the handler that some browsers have chosen to implement inside/alongside the browser. It could be a handler implemented as a standalone native handler, or it could be implemented as a web application and supported through the payment handler specification. However, the requirement to complete verification/assurance activities before presenting the candidate list needs some careful thought – being logged into a browser might not be enough to allow the candidate list to be provided, and so instead a third party payment handler capable of supporting SRC and its assurance methods might be required. The URL-based payment method identifier mechanism would allow each SRC system to declare a payment method, and have a manifest which declared which handlers/Initiators were supported. The requirement to send a confirmation request from the Initiator to the SRC system looks like it might be difficult against the existing payment request API. The current Payment Request specification allows for a “complete” method to be called, but its result can (at the moment) only be a “success”, “fail” or “unknown”. An extension might be needed to carry the additional information required by the confirmation messages, but the good news is that in version 0.9 of the SRC specification, these confirmation messages are optional, not compulsory. Beyond the technical aspects of the SRC specification, it is important to note that each SRC Initiator has to be registered with the SRC systems, and that each SRC Initiator has to enrol each Digital Shopping Application that it supports. In practice, in the WPWG world, this probably means that each payment handler will have to have a registration scheme to register each website that it supports. Some handler-like implementations like ApplePay and Pay with Google already require website registration – other handlers wishing to support SRC would have to implement similar.
Other observations
There are a number of inconsistencies in the v0.9 which I expect will be ironed out as the specification matures. But it would be fair to say that accessibility (in the sense of ensuring that there are no barriers that prevent interactions with the SRC flows by people with disabilities) is something that I think needs further work – especially an over-reliance in the specification language on things like buttons and “visual versions” of things like card art. The EMVco specification is a starting point for implementations from each of its members (Union Pay, JCB, Visa, Mastercard, Diners/Discover and American Express). Until these implementations are available for experimentation, it’s difficult to know for sure how easy the integration of payment request and payment handler into this ecosystem will be. There may also be implementations of SRC systems from organisations other than EMVco members – just as there have been of other EMVco specifications, notably including Tokenisation. However, the profusion of SRC systems will require careful management, and the specification is currently silent on how an SRC Initiator might try to identify all possible participants. I imagine some kind of directory will be required eventually. The SRC specification describes an entire ecosystem including registration, enrolment, configuration management, identity binding and orchestration, alongside payment acceptance, so there are big chunks of it that aren’t directly relevant to the work of WPWG but which may well be interesting to WPWG members, especially if they might plan to implement their own payment handler.
Conclusions
It’s still very early in the lifecycle of this specification, and EMVco are to be applauded in making it available for review before it reaches v1.0. I’ve necessarily only looked at a handful of possible implementations and have not covered in this blog big chunks of the ecosystem, but my initial analysis is that the worlds of SRC and web payments (payment request and payment handler) can work well together. Payment Request has been designed from the outset to be agnostic of the underlying payment method and the extensibility that comes from URL-based payment method identifiers and payment handlers lends itself well to adapting to SRC. More than that, I think SRC can exist alongside existing card payments (like Basic Card) and non-card payments (like credit transfer) which means consumers should be able to make choices about what payment methods they use but still have a consistent experience. The public consultation on SRC v0.9 is open until Monday 3rd December and I’d urge anyone interested to respond if they can. Equally, if anyone has feedback on my initial analysis, or has thoughts about implementations, the WPWG would love to hear from you.
**UPDATE 1**
Fixed spelling and capitalisation errors, and added a comment about the ordering of payment instruments in the candidate list
[1] The spec is actually silent on the subject of interpretative dance. But imagine how cool it would be if you could make a payment simply by busting out a moonwalk.
[2] Yes, you did read this correctly. It looks like it’s the responsibility of each SRC Initiator to contact every possible SRC system each time a shopping transaction happens.
[3] Where this gets exciting is when a cardholder enrols with multiple SRC Initiators and with multiple DCFs, but let’s assume it all just works for now
Recent Comments