Merchant-Initiated Transactions
A 3RI transaction is an EMV 3-D Secure transaction that is initiated by the merchant
instead of the cardholder. The merchant keeps the payment data from the initial payment
so that the cardholder does not have to be present for subsequent 3RI transactions.
Having the payment details from a previous transaction enables the merchant to obtain a
new Cardholder Authentication Verification Value (CAVV) to authenticate when authorizing
future payments.
The authorization request contains the
consumerAuthenticationInformation.deviceChannel
field. This process can be applied
to these types of transactions:- Recurring payments: payments occur at regular intervals for an indefinite interval like subscription services.
- Installment payments: payments occur at regular intervals for a fixed interval.
- Refunded purchases: the cost of an item is refunded before the item is received. Any charges for damage or missing items can be charged back to the customer using a 3RI transaction.
- Delayed shipments: an ordered item is out of stock delaying the shipment until the item is back in stock.
- Split payments: an order is fulfilled in split shipments rather than in a single shipment because one of multiple items in the order is temporarily out of stock.
- Multiple party commerce: a single entity or party makes multiple transactions with different merchants, for example, a travel agent booking flights, hotels, and tour excursions.
- Unknown final transaction amount: extra charges are made to the customer for items such as hotel services, driving citations, or tips.
Challenge Reponses to 3RI Transactions
The directory server prohibits any challenge response from an issuer in 3RI transactions
because the cardholder is not present for authentication. If an issuer does respond with
a challenge, the directory server:
• Returns an ARes with a Transaction Status (transStatus) =
N
and a
Transaction Status Reason (transStatusReason) = 87
(Transaction is
excluded from Attempts Processing) to the 3-D Secure Server (merchant).• Sends an error message (Erro) to the Access Control Server (ACS), with Error Code
(errorCode) =
203
(Format of one or more data elements is invalid
according to the specification.) When you receive this response, you should find an alternate way of processing the
transaction. Examples include going directly to authorization, or when the cardholder is
present, resending the transaction. When you receive this response, contact your
acquirer to raise the issue with customer support.
Network-Specific Values for 3RI
When the request body requires a previous authentication reference ID (
consumerAuthenticationInformation.priorAuthenticationReferenceId
), use
the network-specific value found in one of these fields in the original response.- Visa:consumerAuthenticationInformation.acsTransactionId
- Mastercard:consumerAuthenticationInformation.directoryServerTransactionId
When the request body requires a value from the
consumerAuthenticationInformation.requestorInitiatedAuthenticationIndicator
field
and the 3RI transaction type is multi-party commerce, use use one of these
network-specific values.- Visa:11(Other payment)
- Mastercard:85(Agent payment)
Note that Mastercard uses the Electronic Commerce Indicator (ECI) value of
07
for 3RI transactions.1a: Initial Recurring Transaction
In this instance, the merchant initiates a 3RI recurring transaction that is a fixed
amount for a set of transactions with no established expiration, such as with a
subscription purchase.
Card Type | Test Card Number |
---|---|
Mastercard Card Type = 002 | 520000 00 0000 280 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups1b: Recurring Payments - Subsequent Transaction (Mastercard)
In this instance, the merchant is running a subsequent 3RI recurring transaction that
is a fixed amount for a set of payments with no established expiration such as a
subscription purchase.
Card Type | Test Card Number |
---|---|
Mastercard Card Type = 002 | 520000 00 0000 2235 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups2a: Installment - Customer Initiated Transaction (Mastercard)
In this instance, the initial authentication is for the total amount for all of the
future installments. Once the initial authentication is completed by the customer,
the subsequent installments do not require authentication and go directly to
authorization, which is Mastercard’s preferred process.
Card Type | Test Card Number |
---|---|
Mastercard Card Type = 002 | 520000 00 0000 2805 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups3a: Split/Partial Shipment (Mastercard)
In this instance, the purchase includes multiple items that do not become available
to the customer at different times. For example, the customer order has backordered
or preordered items. During the initial purchase, the authentication should be for
the full amount total (including products to be shipped at a later time).
Card Type | Test Card Number |
---|---|
Mastercard Card Type = 002 | 520000 00 0000 2235 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups3b: Split/Delayed Shipment (Visa)
In this instance, the purchase includes multiple items that do not become available
to the customer at different times. For example, the customer order has backordered
or preordered items. During the initial purchase, the authentication should be for
the full amount total (including products to be shipped at a later time).
Card Type | Test Card Number |
---|---|
Visa Card Type = 001 | 400000 00 0000 2701 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups4a: Multi-Party Commerce or OTA (Visa)
In this test case, a travel booking merchant creates a multi-party transaction for
the cardholder. The merchants participating in the multi-party transaction are
required to authorize on flights, hotels, and car rentals etc. This test case
focuses on what the participating merchants are required to send for a successful
transaction. Note that each participating merchant must send their own CAVV.
Card Type | Test Card Number |
---|---|
Visa Card Type = 001 | 520000 00 0000 2701 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups4b: Multi-Party Commerce or OTA (MasterCard)
In this test case, a travel booking merchant creates a multi-party transaction for the
cardholder. The merchants participating in the multi-party transaction are required
to authorize on flights, hotels, and car rentals etc. This test case focuses on what
the participating merchants are required to send for a successful transaction. Note
that each participating merchant must send their own CAVV.
Card Type | Test Card Number |
---|---|
Mastercard Card Type = 002 | 520000 00 0000 2805 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups4c: Multi-Party Commerce or OTA (MasterCard)
The merchant initiates a (3RI) recurring transaction of a fixed amount for a
specified number of transactions or with no set number of transactions such as
occurs with subscription purchases. For more information, see Requester Initiated Payments.
Card Type | Test Card Number |
---|---|
Mastercard Card Type = 002 | 520000 00 0000 2235 |
Endpoint
Production:
POST
https://api.cybersource.com
/risk/v1/authentication-setupsTest:
POST
https://apitest.cybersource.com
/risk/v1/authentication-setups