Merchant-initiated transaction (MIT – 3RI)

The 3RI (3DS Requestor Initiated) flow applies to merchant-initiated transactions (MIT): the merchant initiates the debit without the cardholder’s involvement, under a pre-existing authorization, based on a previously authenticated CIT transaction.

It covers all MIT scenarios: recurring billing, variable amounts, usage-based templates, one-time fees, and deferred debits (no-shows, penalties), not just fixed-rate subscriptions.

👉 If the cardholder is present and authorizes the payment themselves, use the BRW flow. For information on the contractual framework, Strong Customer Authentication (SCA) exemptions, and the validity period of a CIT, see the Best Practices — Merchant Initiated Transaction (MIT) page.

1. Prerequisite: a CIT transaction that has already been authenticated

Since the cardholder is absent, the 3RI does not re-authenticate anyone: it reuses the authentication proof generated during a previous CIT transaction (with the cardholder present) carried out via the BRW flow.

During this CIT, the issuing bank’s server that authenticated the cardholder — the ACS (Access Control Server) — generated a unique identifier for this authentication: theacsTransID. This is the acsTransID that you will associate with each of your MITs to prove to the bank that the card was indeed authenticated for the first time with the cardholder’s consent.

⚠️ Keep the acsTransID from the CIT. Without a previously authenticated CIT — and therefore without acsTransID — a 3RI transaction cannot be completed. If you don't have one, first perform a CIT in BRW to authenticate and tokenize the card. 

2. (3RI) Authentication

The request is sent to the CentralPay API URL 3ds2/authentication, just like for the BRW flow, but with two key differences:

• The channel is different. deviceChannel=03 Indicates a transaction initiated by the merchant (3RI), without the cardholder using a browser. The browser* parameters in the BRW flow are therefore unnecessary here.
• The CIT is referenced. The acsTransID value retained in step 1 is placed in the threeDSReqPriorRef field, which refers to “the previous authentication associated with this transaction.”

Card identification. Since the cardholder is not present, no card is scanned during the session: the card already stored for the customer (Customer) is referenced by transmitting customerId + cardId.

💡 Send only one card source. Combining two sources (e.g., cardId + a token, or a PAN + a token) triggers the error “There is no unique source of card” (see the FAQ). 

Sample (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/3ds2/authentication' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--data-urlencode 'customerId=aae4d8c0-a555-4c2f-bfdf-18d5636b78a4' \
--data-urlencode 'cardId=44d0691b-b117-4799-ba07-31e0b02c5b08' \
--data-urlencode 'pointOfSaleId=08960d92-874b-4447-800b-aaa53fa976f5' \
--data-urlencode 'deviceChannel=03' \
--data-urlencode 'messageCategory=01' \
--data-urlencode 'acctType=03' \
--data-urlencode 'cardExpiryDate=9999' \
--data-urlencode 'purchaseAmount=4880' \
--data-urlencode 'purchaseCurrency=978' \
--data-urlencode 'purchaseExponent=2' \
--data-urlencode 'purchaseDate=20230101122345' \
--data-urlencode 'recurringExpiry=20330101' \
--data-urlencode 'recurringFrequency=1' \
--data-urlencode 'chAccAgeInd=03' \
--data-urlencode 'chAccChange=20220901' \
--data-urlencode 'chAccDate=20220901' \
--data-urlencode 'email=support@centralpay.eu' \
--data-urlencode 'nbPurchaseAccount=2' \
--data-urlencode 'paymentAccAge=20221001' \
--data-urlencode 'paymentAccInd=03' \
--data-urlencode 'threeDSReqPriorAuthMethod=02' \
--data-urlencode 'threeDSReqPriorAuthTimestamp=202209010123' \
--data-urlencode 'threeDSReqPriorRef=375d90ad-3873-498b-9133-380cbbc8d99d' \
--data-urlencode 'threeDSRequestorDecReqInd=N' \
--data-urlencode 'threeDSRequestorAuthenticationInd=02' \
--data-urlencode 'threeRIInd=01'

2.1. Explanation of the main parameters

Parameters	Description
deviceChannel	03 → 3DS Requestor Initiated (transaction initiated by the merchant, without the cardholder using a browser)
messageCategory	01 → PA (Payment Authentication) = Authentication associated with a payment (e.g., recurring transaction) 02 → NPA (Non-Payment Authentication) = authentication that does not involve a payment (e.g., registration or card verification without a charge).
threeDSReqPriorRef	must contain the acsTransID from the previous CIT (BRW) transaction (see step 1)
purchaseAmount	amount of the current purchase
purchaseCurrency	currency in ISO format
purchaseExponent	minor unit of the current currency
purchaseDate	date of purchase
recurringExpiry	the date after which no further authorizations may be issued
recurringFrequency	minimum number of days between two authorizations
acctType	account type (03 = debit)
chAccAgeInd	length of time the account holder has had an account with the 3DS requester: 01 → no account 02 → created during the transaction 03 → less than 30 days 04 → between 30 and 60 days 05 → more than 60 days
chAccChange	date of the last change to the account holder’s account (format YYYYMMDD)
chAccDate	account holder’s account opening date (format YYYYMMDD)
nbPurchaseAccount	number of purchases made with this account over the past six months
paymentAccAge	date the payment account was credited to the account holder’s account
paymentAccInd	lenght of time the payment account has been registered: 01 → no account 02 → created during the transaction 03 → less than 30 days 04 → between 30 ans 60 days 05 → more than 60 days
threeDSReqPriorAuthMethod	Initial CIT Authentication Method: 01 → if frictionless 02 → if the cardholder has completed a challenge 03 → AVS 04 → other
threeDSReqPriorAuthTimestamp	date and time (UTC) of the previous authentication (format YYYYMMDDHHMM)
threeDSRequestorDecReqInd	N → do not use decoupled authentication
threeDSRequestorAuthenticationInd	02 → recurring transaction
threeRIInd	Type of 3RI transaction: 01 → recurring transaction 02 → installment transaction 03 → add a card 04 → maintenance 05 → account verification 06 → split/delayed shipment 07 → recharging 08 → mail-order sales 09 → telephone sales 10 check whitelist status 11 → other payment

Sample of response:

{
    "threeDSServerTransID": "67dc456c-6c7a-987f-92cf-f68752525d0c",
    "transStatus": "Y",
    "eci": "02",
    "contractId": "fb8736a5-8741-19b6-9d38-ec135888e0bf"
}

Here, threeDSServerTransID is the transaction ID generated by CentralPay (to be included in the transaction), and eci (Electronic Commerce Indicator) indicates the level of authentication achieved, which determines the transfer of liability in the event of fraud.

2.2. Returned statuses (transStatus) and recommended course of action

The goal is to achieve frictionless authentication, that is, a transStatus = Y. Always try the 3RI first, then proceed according to the transStatus returned.

ℹ️ Support for 3RI depends on the card's scheme and the issuing bank's 3DS version: it is never guaranteed in advance. Hence the “best effort” approach described below — you attempt 3RI, and you only rely on the result if it is positive. 

✅ Authentication successful — use the results (transfer of responsibility)

Status (transStatus)	Meaning
Y	Authentication successful.
A	Attempt made. Not authenticated/verified, but a proof of the attempt is provided.

→ Complete the transaction by submitting the 3DS data from the 3RI (see Step 3). Liability shifts to the issuer.

⚠️ 3RI failed — complete the transaction without authentication (“best effort”)

Status (transStatus)	Meaning
N	Not authenticated/unverified account.
U	Authentication/verification failed (technical issue or other problem).
I	For informational purposes only.
C / D	Challenge requested (not possible in MIT because the cardholder is absent — see note below).

→ You can perform the standard transaction without the 3RI data: the Customer (customerId + cardId) ensures automatic linking to the initial CIT. Please note: In this case, the transfer of responsibility does not apply (increased risk of dispute), and the risk of authorization denial is higher.

⚠️ MIT Challenge (C / D). A challenge requires the cardholder to be present, which, by definition, is not the case with MIT. There are two scenarios: if the cardholder can return (e.g., subscription with a customer portal), reprocess a CIT in BRW to re-authenticate the card; otherwise, treat it as an unsuccessful 3RI and complete the transaction without authentication (best effort). See Best Practices — MIT.  

❌ Explicit refusal — do not attempt the transaction

Status (transStatus)	Meaning
R	Authentication declined: the sender requests that you do not attempt to obtain authorization.

→ Do not complete the transaction, even without a 3RI.

3. Transaction

Once 3RI authentication is successful (Y or A), enter the following 3DS data in the transaction call:

• 3ds[threeDSServerTransID] = threeDSServerTransID generated by 3RI authentication (not the one from a previous transaction)
• 3ds[status] = transStatus
• 3ds[eci] = eci (required if available)
• 3ds[xid] = custom parameter, free-form reference for merchants

⚠️ Do not send 3ds[cavv] in3RI. The cavv (Cardholder Authentication Verification Value, the cryptogram that verifies authentication) is specific to the BRW stream; it is not included in the 3RI response and should not be transmitted here.

Sample (curl) :

curl --location --request POST 'https://test-api.centralpay.net/v2/rest/transaction' \
--header 'Origin: https://example.centralpay.net' \
--header 'Authorization: Basic ZG9jdGVzdDo0STlISlJUZA==' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'currency=EUR' \
--data-urlencode 'amount=1500' \
--data-urlencode 'endUserIp=9.64.32.8' \
--data-urlencode 'endUserLanguage=ita' \
--data-urlencode 'merchantTransactionId=cpcg_12654de89ce44' \
--data-urlencode 'pointOfSaleId=1beb8574-cf4c-4b12-b065-d12b3f0eaa90' \
--data-urlencode 'browserUserAgent=Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1' \
--data-urlencode 'browserAcceptLanguage=it_IT' \
--data-urlencode 'paymentRequestBreakdownId=5485d7e6-60c3-753c-94d3-682eaaf9ae6e' \
--data-urlencode 'email=support@centralpay.eu' \
--data-urlencode 'receiptEmail=support@centralpay.eu' \
--data-urlencode 'capture=true' \
--data-urlencode 'customerId=aae4d8c0-a555-4c2f-bfdf-18d5636b78a4' \
--data-urlencode 'cardId=44d0691b-b117-4799-ba07-31e0b02c5b08' \
--data-urlencode 'order[cardholderEmail]=support@centralpay.eu' \
--data-urlencode 'order[firstName]=John' \
--data-urlencode 'order[lastName]=Doe' \
--data-urlencode 'source=EC' \
--data-urlencode '3ds[xid]=35876533346561303461' \
--data-urlencode '3ds[eci]=02' \
--data-urlencode '3ds[status]=Y' \
--data-urlencode '3ds[threeDSServerTransID]=67dc456c-6c7a-987f-92cf-f68752525d0c'

ℹ️ « best effort » case (3RI not completed). If the 3RI is not completed (transStatus other than Y/A, and excluding R), perform the same transaction without the subject 3ds[...] : the Customer  (customerId  +  cardId) is sufficient to link the operation to the initial CIT. In that case, the transfer of liability does not apply. 

See also: Best Practices — Merchant-Initiated Transactions (MIT) for the contractual framework, mandate, and Strong Customer Authentication (SCA) exemptions.