***** Superseded ***** See flow diagrams that correspond to a proposed architecture for doing EMV® Secure Remote Commerce (SRC) through Payment Request API.
See also:
Questions? Ian Jacobs <ij@w3.org>.
Notes:
Note: This diagram shows one way a user can enrol a card in the SRC system through a payment handler. A card may be enrolled through other channels (e.g., a Web site) or by other roles (e.g., a bank acting as a participating issuer).
Risk analysis will likely play a role in every transaction. 3DS may play a part in risk analysis that happens during an SRC flow. If it does, it make take place at at various times, including "during Payment Request" or "after Payment Request."
The diagram above illustrates a flow where the merchant may request that 3DS be part of the Payment Request flow. There is still work to be done to define an interface for merchants that supports a variety of use cases. See the section 3.1 of 3-D Secure 2 with Payment Request API for more discussion.
SRC systems include a notion of cardholder identity. The following diagrams illustrate different identity management scenarios.
In each diagram below, there is only a single payment handler available to the user.
In this flow, a user with an existing identity is using a new device for the first time. The payment handler does not know about the user's existing identity and so the user's experience is that of adding a new card to the SRC system(s). The payment handler generates a new identity for the user based on device characteristics.
In this flow, a user with an existing identity is using a new device for the first time. The payment handler knows about the user's existing identity, so it retrieves previously enrolled card information from the SRC system(s).
supported_origins
and no
default_applications
. This allows each SRC Programme to
manage its own certification program and publish the results in a way
that is machine readable by the browser. This does mean that SRC
programmes will need to work with browsers to add support, but the
initial number should be small.
'src'
. This is easier
for developers, and enables merchants to accept payments from multiple
SRC programmes without changing their front-end integration.
supportedNetworks
capability filter to improve the chances of a successful match.default_applications
specified in a payment method
manifest.
src
. Once the user has
selected a payment handler, it is registered and there will be no
further JIT registration.
src
payment handlers may become
large, it may be desirable to offer mechanisms to reduce the size of
the set. Some of these mechanisms may occur outside the scope of the
standards (e.g., the brower may have relationships with payment
handler providers or SRC programmes). Some of these mechanisms may
involve standardized APIs (e.g., we might enable merchants to specify
a list of preferred payment handler origins for src
or
other open payment methods).
BobPay
and
src
.
src
string to multiple payment method manifests.Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
Last modified: $Date: 2020/04/15 17:14:12 $