Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Cardinal Commerce FIDO uses our Data Exchange API (DX API) to determine whether a user is already enrolled in FIDO. The DX API is a versatile set of endpoints that provide additional information and real-time insights into the transaction process prior to authentication. In the context of FIDO, the DX API’s GetInfo endpoint is leveraged to determine the FIDO enrollment status of a Device/PAN combination, as well as what authentication programs are supported by the PAN’s ACS.

...

Field

Description

Type

Required

SupportedVersions

Encompasses Issuer information based on the PRes received from each card network

Array of Objects

Y

SupportedVersions.Version

Specifies all active 3DS protocol versions supported by the Issuer ACS

String

Y

SupportedVersions.Capabilities

Provides information related to the Issuer Capabilities supported for each 3DS version

Array

O

SupportedVersions.MethodURLPresent

Indicates whether there is a 3DS Method associated with the Issuer Range

If the MethodUrlPresent flag returns ‘false’, you can elect to skip Device Data Collection and proceed with the Lookup Request call if you are able to capture the required browser fields on your own

Boolean

Y

Account Object

...

Field

Description

Type

Required

LastFour

Echoes the last four numbers of the AccountNumber field passed on the Data Exchange API request payload

String

Y

CardBrand

Type of card used for the purchase.

Possible Values:

  • Visa

  • Mastercard

  • Amex

  • CB

  • JCB

  • Discover

  • ELO

  • UPI

  • ITMX

Note that currently, Visa is the only network supporting FIDO. As other networks adopt the protocol, this is how they will appear in this context
  • EFTPOS

Note

Cardinal FIDO authentication is currently only supported on Visa cards. More card networks will be onboarded in the future.

String

Y

Fido

This sub-object contains a single Boolean string field, "Registered"This object will only be returned if enrollment can move forward. As mentioned above, this step is checking two factors regarding FIDO capabilityFlowType"

FlowType indicates whether the cardholder has previously been enrolled in FIDO, as well as what type of enrollment UI experience the cardholder may be guided through. In order for FIDO to move forward, the following must be true:

  • Card issuer must support Delegated Authentication

  • Both the acquirer and the issuer must be in a region supported by Cardinal FIDO

Object

C

Fido.FlowType

Indicates what type of flow the cardholder should be moved through. This is a key piece of information determining how to move forward in the transaction. The possible FlowType responses are outlined below.

String

C

FlowType Responses

...

FlowType

Invoke Endpoint

Enrollment Status

Description

TRANSACTION

Transact

EMAIL: Enrolled
DEVICE: Enrolled
PAN: Enrolled

Cardholder has previously been enrolled in FIDO with this device/PAN/email combination. No further enrollment action is required, and they can be moved to a FIDO transaction using the Transact endpoint.

ENROLLMENT

Enroll

EMAIL: New
DEVICE: --
PAN: --

Cardholder has not previously been enrolled in FIDO.
Cardholder will need to be taken through an SCA transaction, then should be given a prompt to enroll in FIDO. If they accept, the Enroll endpoint should be invoked and they will be moved into the Enrollment flow.

ADD_NEW_DEVICE

Enroll

EMAIL: Enrolled
DEVICE: New
PAN: Enrolled

Cardholder has previously been through the enrollment flow and their email has been registered, but they are on a new device which will need to be registered. Cardholder will need to be taken through an SCA transaction, then should be given a prompt to add a new device/authenticator. If they accept, the Enroll endpoint should be invoked and they will be moved into the “Add New Device” flow.

ADD_PAN

Enroll

EMAIL: Enrolled
DEVICE: Enrolled
PAN: New

Cardholder has previously been through the enrollment flow and their email has been registered, but they are using a new PAN for this transaction which will need to be registered.
Cardholder will need to be taken through an SCA transaction, then should be given a prompt to add a new PAN. If they accept, the Enroll endpoint should be invoked and they will be moved into the “Add New PAN” flow.

ADD_NEW_DEVICE_AND_PAN

Enroll

EMAIL: Enrolled
DEVICE: New
PAN: New

Cardholder has previously been through the enrollment flow and their email has been registered, but they are using a new PAN and a new device for this transaction. Both the PAN and the device will need to be registered.
Cardholder will need to be taken through an SCA transaction, then should be given a prompt to add a new device/authenticator (the same prompt as ADD_NEW_DEVICE above). If they accept, the Enroll endpoint should be invoked and they will be moved into the “Add New Device and PAN” flow.

...