In some scenarios cardholder data are captured and processed (e.g. authentication and authorization) through third-party websites on behalf of one or multiple merchants. The third-party website operartor is usually reffered to as an Agent. Because the cardholder is interacting with the Agent’s environment it is the Agent’s obligation to perform payment authentication.


The requirements for Agent processing models are described in the following paragraphs.

VISA

Travel and Hospitality Merchants

Scenario 1 : Authentication performed by a Travel Agent on behalf of one single merchant

When the Travel Agent is facilitating authentication on behalf of a single merchant at the time of booking the process is as follows:

  • The Travel Agent discloses to the cardholder appropriate T&Cs and follows other requirements associated with the potential future MIT type the merchant may have to process.

  • The Travel Agent authenticates the transaction for the total booking amount (Merchant descriptor name = “Travel Agent Name * name of merchant ” )

  • The Travel Agent may optionally perform an account verification to check validity of the card before passing the card details to the merchant (If an account verification is performed, it must not include the CAVV as this is required by the end merchant )

  • The Travel Agent passes the authentication data to the merchant.

  • The Merchant submits a normal authorization request to Paygate including the required data in the threeDSData [Request] JSON object.


In case the merchant wants to perform the payment at a later time than he should:

  1. Perform an Account Verification (i.e. AccVerify=Yes) with the authentication data received from the Agent within 24 hours.

  2. Subsequently when the amount is due send an authorization flagged as MIT including the schemeReferenceID from the previous account verification transaction.


Scenario 2: Authentication performed by a Travel Agent on behalf of several other merchants.

This scenario covers the case when a customer makes a travel reservation online via a Travel Agent which includes the delivery of services by multiple merchants.

  • The Travel Agent discloses to the cardholder appropriate T&Cs and follows other requirements associated with the potential future MIT type the merchant may have to process

  • The Travel Agent then authenticates the transaction for the total booking amount ( Merchant descriptor name = “Travel Agent Name” )

  • An additional 3DS 3RI authentication request is required to provide CAVVs for each further merchant who will perform an authorization.

  • The Travel Agent submits authentication data to the merchant.

  • The Merchant submits a regular authorization request to Paygate including the required data in the threeDSData [Request] JSON object.


In case the merchant wants to perform the payment at a later time than he should:

  1. Perform a zero-value account verification with the authentication values received from the Agent
    within 24 hours.

  2. Subsequently when the amount is due send an authorization flagged as MIT including the schemeReferenceID from the previous account verification transaction.


Other Merchants

Scenario 3: Authenticated CIT from the Agent and subsequent MIT transaction from the merchant

This is the case when the Agent performs the authentication and subsequently uses the VISA CAVV for its own authorization payload. In such a case as the Agent already used the CAVV and he may not be able to use the 3DS/3RI feature (for having a new CVV for the merchant) than he can provide to the merchant only the schemeReferenceID of the initial CIT together with the payload so that the merchant may initiate his authorizations flagged as an subsequent MIT (i.e UCOF, Delayed Auth)


As a difference worthy to be highlighted between VISA and MC is such use cases is that:

a) Authentication Value (CAVV/AAV)

In case of VISA, the Agent who is performing authentication on behalf of several merchants needs through the 3DS/3RI request (only possible with EMV 3DS 2.2 version) to provide separate CAVV’s values for each merchant separately.
MasterCard on the other hand is stating that for the Agent Model where a single authentication is linked to multiple authorizations the same authentication code/ AVV could be used for multiple transactions.

b) schemeReferenceID

Under the third scenario the Agent can provide to the merchant together with the payload only the ‘schemeReferenceID’ from the initial CIT with no Authentication data in such a way that the merchant is able to initiate subsequent MIT transactions referring to the initial establishment.
For VISA the “schemeRefernceID” (transactionID) is usually provided as a single response parameter while for Mastercard the “schemeReferenceID” is a concatenation of fields like: *(SettlementDate+FinancialNetworkCode& BanknetReference).

-SettlementDate -> n..4
-FinancialNetworkCode -> an..3
-BanknetReference -> an..9

* Agents using this type of scenario (with CIT/MIT) are recommended to provide their merchants with the required MasterCard reference data where the merchant can subsequently submit it to Paygate “schemeReferenceID” during MIT transactions.

Please also be advised that the above approach for handling each of these scenarios serves only as recommendation, therefore, merchants and Acquirers can choose alternative options that complement their business model, as long as they remain compliant with the key principles of the PSD2 SCA.