menu

Payment API

What's on this page

Online Payments / Payment Features / 3D-Secure 2 / Out Of Scope Transactions

Out Of Scope Transactions

The PSD2 mandate does not cover all card-based transactions and considers these as Out Of Scope for SCA. The issuing bank will not apply SCA for these transactions and guarantees that they will not present the cardholders with an authentication challenge. Out Of Scope transactions do not require an exemption to be requested. However, they do have to be explicitly flagged.

Merchant Initiated Transaction - MIT

Visa SCA Implementation Guide Version 2.0

A transaction, or series of transactions, of fixed or variable amount and frequency, governed by an agreement between the cardholder and merchant that, once agreed, allows the merchant to initiate subsequent payments without any direct involvement of the cardholder. Examples of MITs include subscription type payments at fixed or variable intervals, instalment payments, pre/balance payments, payments related to delayed or split shipments, payments related to booking reservations made via indirect channels, cancellation fees (No show), incremental authorisation requests, delayed charges, and collection of payment of already delivered services (contactless transit only).

In most cases SCA is required if the agreement is set up through a remote electronic channel and MITs must be identified and flagged by merchants so their Acquirers can flag them to Visa using the Visa MIT Framework.

Mail order / Telephone Order - MOTO

Visa SCA Implementation Guide Version 2.0

Payments made through Mail Order/Telephone Order (telephone includes Interactive Voice Response services). Note, “voice commerce” payments initiated through digital assistants or smart speakers are not classed as MOTO.

These transactions must be identified and flagged by merchants and Acquirers.

One leg Out

Visa SCA Implementation Guide Version 2.0

A transaction where either the Issuer or Acquirer is located outside the EEA or the UK is considered out of scope and not requiring SCA. However, SCA should still be applied on a “best efforts” basis.

These transactions are identifiable by the issuer BIN or the Acquirer location being from outside the EEA or the UK.

Anonymous transactions

Visa SCA Implementation Guide Version 2.0

Transactions through anonymous payment instruments, for example anonymous prepaid cards.

These transactions cannot be recognised as such by a merchant so must be identified by Issuers checking the BIN.

Liability Shift

The new regulation has implications on the liability in case of a fraudulent transaction. In general, the following applies:

  • If no 3-D Secure is used, the merchant/acquirer is liable
  • If the merchant/acquirer applies for an exemption and
    • the issuer requests a challenge, the issuer is liable
    • the issuer acknowledges the exemption, the merchant/acquirer is liable
  • If the issuer applies for an exemption, the issuer is liable
  • If the transaction is a subsequent transaction (MIT/Recurring/Instalments), the acquirer is liable

How to request Out of Scope transactions

Merchant Initiated Transaction

A merchant initiated transaction, MIT in short, requires an agreement between you and the cardholder. Set up the agreement in the initial customer-initiated transaction (CIT). Without a CIT, there can be no MIT. Each CIT must apply SCA to obtain a valid agreement. Once the agreement is set up, use the CIT as a reference in subsequent MIT payments.

Subsequent transactions imply that the cardholder’s card data is stored on file. Our vault can facilitate this or if you are PCI compliant store the data locally.

API Changes

In order to facilitate MIT exemptions, the sequence information contains the following fields:

Name Type Size Format Inclusion Description
type string Possible Values:
EXPRESS_CHECKOUT
RECURRING
INSTALMENT
UNSCHEDULED		 Required If the payment is part of a sequence of payments, indicate the type of sequence
instalmentMaxAuthorisations integer 3 Required if type is INSTALMENT and mode is INITIAL If the payment is part of an instalment, the maximum number of instalments allowed with this authentication
recurringExpiry string 8 Date formatted in YYYYMMDD Required if type is RECURRING and mode is INITIAL If the payment is part of a recurring payment, the date that the last recurring payment is executed
recurringFrequency integer 3 Required if type is RECURRING and mode is INITIAL If the payment is part of a recurring payment, the number of days between each recurring payment
mode string Possible Values:
INITIAL
SUBSEQUENT		 Required if type is RECURRING, INSTALMENT or UNSCHEDULED If the payment is part of an unscheduled sequence, indicate if the transaction is the initial or subsequent transaction
source string Possible Values:
CIT
MIT		 Required if type is RECURRING, INSTALMENT or UNSCHEDULED Indicate who the initiator is of the payment
initialTransactionId string Max 20 Required if type is RECURRING, INSTALMENT or UNSCHEDULED and no vault access token is used If the payment is part of a chain of transactions, the reference to the initial or last subsequent transaction of the chain
industryPractice string Possible Values:
INCREMENTAL
DELAYED_CHARGES
NO_SHOW
REAUTHORIZATION
RESUBMISSION
Optional If the payment is a change of an existing CIT, indicate what industry practice triggered the change

Initial Customer Initiated Transaction

The initial transaction acts as an agreement with the cardholder giving you permission to use the cardholders’ card data for future payments.

Inform the cardholder why approval is required, how the card is used, and for how long. If future payments vary in amount, inform the customer during the set up of the agreement. For fixed amounts, the Recurring flow is advised.

To utilize the MIT exemption, transactions must be flagged appropriately. Once the CIT transaction is complete, the transaction response contains the initial transaction id to be used in the subsequent transactions.

API Request

  1. Initiate a new transaction and flag the transaction as the initial CIT. 
    {
    "amount" : 10.99,
    "currency" : "eur",
    "method" : "card",
    "returnUrl" : "https://shop.merchant.com/return?order=123456",
    "merchantOrderReference" : "123456",
    "description" : "Order 123456",
    "language" : "nld",
    "sequenceInfo": {
        "type": "UNSCHEDULED",
        "mode": "INITIAL",
        "source": "CIT"
    },
    "storeInVault": "yes"
}
  2. CCV Pay responds with a generated transaction containing a unique payUrl 
    {
     "amount": 10.99,
     "currency": "eur",
     "method": "card",
     "returnUrl": "https://shop.merchant.com/return?order=123456",
     "merchantOrderReference": "123456",
     "description": "Order 123456",
     "reference": "C200603161403114CB87E19E.2",
     "language": "nld",
     "type": "sale",
     "created": 1591193643343,
     "lastUpdate": 1591193643343,
     "payUrl": "https://onlinepayments.ccv.eu/card/payment.html?reference=C200603161403114CB87E19E.2",
     "status": "pending"
 }
  3. Redirect the customer to the payUrl
  4. The customer submits card data
  5. CCV Pay requests authentication for a mandate and show the challenge to the customer
  6. When the customer completes authentication, CCV Pay redirects them to the returnUrl
  7. CCV Pay sends the authorisation to the issuer for completion

Final API Response

When the transaction is complete, query the transaction to get the final status. The API response now also includes the new field $.details.initialTransactionId. Just like the $.details.vaultAccessToken, store this data for subsequent transactions.

{
   "amount" : 10.99,
   "currency" : "eur",
   "method" : "card",
   "returnUrl" : "https://shop.merchant.com/return?order=123456",
   "merchantOrderReference" : "123456",
   "description" : "Order 123456",
   "language" : "nld",
   "status": "success",
   "details": {
       "initialTransactionId": "INITIAL_TX_ID_1",
       "vaultAccessToken": "VAT_1"
   }
}

Subsequent transaction 1

Each subsequent transaction must refer to a previous transaction in the chain of transactions. Being the first subsequent transaction, only refer to the initial customer-initiated transaction.

Each subsequent transaction also requires card data. If you use our vault, you can add the vault access token of the cardholder to the request. Another option is to add the card data in the transaction details of the request.

We assume that the cardholder is off-session meaning the cardholder is not actively interacting with a website or mobile app. If the card-holder is on-session, MIT is not allowed.

The input data of the subsequent transaction can be very compact compared to the initial transaction. E.g. there is no need to provide the billing address for each subsequent transaction.

API Request

{
    "amount" : 20.99,
    "currency" : "eur",
    "method" : "card",
    "returnUrl" : "https://shop.merchant.com/return?order=123457",
    "merchantOrderReference" : "123457",
    "language" : "nld",
    "sequenceInfo": {
        "type": "UNSCHEDULED",
        "mode": "SUBSEQUENT",
        "source": "MIT",
        "initialTransactionId": "INITIAL_TX_ID_1"
    },
    "details": {
        "vaultAccessToken": "VAT_1"
    }   
}

Final API Response

Payment schemes are most likely to respond with a new initial transaction id for the next subsequent transaction id.

{
   "amount" : 20.99,
   "currency" : "eur",
   "method" : "card",
   "returnUrl" : "https://shop.merchant.com/return?order=123457",
   "merchantOrderReference" : "123457",
   "language" : "nld",
   "status": "success",
   "details": {
       "initialTransactionId": "SUBSEQUENT_TX_ID_1"
   }
}

Subsequent transaction 2

To complete the example of multiple subsequent transactions, the following request shows the use of initialTransactionId with value SUBSEQUENT_TX_ID_1 as received in Subsequent transaction 1.

Use the initial transaction id of the CIT transaction or the last subsequent MIT transaction. We prefer the last subsequent transaction which allows all parties involved to store a limited set of data for a chain of transactions.

Example API Request

{
    "amount" : 15.99,
    "currency" : "eur",
    "method" : "card",
    "returnUrl" : "https://shop.merchant.com/return?order=123458",
    "merchantOrderReference" : "123458",
    "language" : "nld",
    "sequenceInfo": {
        "type": "UNSCHEDULED",
        "mode": "SUBSEQUENT",
        "source": "MIT",
        "initialTransactionId": "SUBSEQUENT_TX_ID_1"
    },
    "details": {
        "vaultAccessToken": "VAT_1"
    }   
}

Final API Response

The value initialTransactionId can be the same as the input id or a new one.

{
   "amount" : 15.99,
   "currency" : "eur",
   "method" : "card",
   "returnUrl" : "https://shop.merchant.com/return?order=123458",
   "merchantOrderReference" : "123458",
   "language" : "nld",
   "status": "success",
   "details": {
       "initialTransactionId": "SUBSEQUENT_TX_ID_2"
   }
}

Industry Practice

A Merchant Initiated Transaction encompasses multiple scenarios, especially in the travel and hospitality sector. There are several use-cases for an MIT transaction for which additional flagging is available using the optional field $.sequenceInfo.industryPractice. Use it both in the CIT or MIT transaction of the transaction chain.

Unscheduled Card On File

Unscheduled means payments initiated at an irregular interval, and possibly for changing amounts between payments.

Recurring

Recurring is an MIT scenario where a fixed amount is withdrawn from the cardholders account at a regular interval.

Initial transaction

Flagging the initial recurring transaction looks very familiar to an MIT transaction. Additionally, a recurring transaction requires an expiry and frequency.

Example API Request

{
  "amount" : 15.99,
  "currency" : "eur",
  "method" : "card",
  "returnUrl" : "https://shop.merchant.com/return?order=123458",
  "merchantOrderReference" : "123458",
  "language" : "nld",
  "sequenceInfo": {
    "type": "RECURRING",
    "mode": "INITIAL",
    "source": "CIT",
    "recurringExpiry": "20211231",
    "recurringFrequency": "12"
  },
  "storeInVault": "yes"
}

Subsequent transactions

There is no need to pass on the recurring data in subsequent transactions.

Example API Request

{
  "amount" : 15.99,
  "currency" : "eur",
  "method" : "card",
  "merchantOrderReference" : "123458",
  "language" : "nld",
  "sequenceInfo": {
    "type": "RECURRING",
    "mode": "SUBSEQUENT",
    "source": "MIT",
    "initialTransactionId": "INITIAL_TX_ID_1"
  },
  "details": {
    "vaultAccessToken": "VAT_1"
  }
}

Instalments

An instalment is a MIT scenario where an amount is paid in multiple payments.

Initial transaction

Flagging the initial instalment transaction looks very familiar to an MIT transaction. Additionally, an instalment transaction requires the maximum number of authorisations (i.e. payments) a merchant will execute as part of the agreement with the customer.

Example API Request

{
  "amount" : 15.99,
  "currency" : "eur",
  "method" : "card",
  "returnUrl" : "https://shop.merchant.com/return?order=123458",
  "merchantOrderReference" : "123458",
  "language" : "nld",
  "sequenceInfo": {
    "type": "INSTALMENT",
    "mode": "INITIAL",
    "source": "CIT",
    "instalmentMaxAuthorisations": "12"
  },
  "storeInVault": "yes"
}

Subsequent transactions

There is no need to pass on the instalment information in subsequent transactions.

Example API Request

{
  "amount" : 10.99,
  "currency" : "eur",
  "method" : "card",
  "merchantOrderReference" : "123456",
  "language" : "nld",
  "sequenceInfo": {
    "type": "INSTALMENT",
    "mode": "SUBSEQUENT",
    "source": "MIT",
    "initialTransactionId": "INITIAL_TX_ID_1"
  },
  "details": {
    "vaultAccessToken": "VAT_1"
  }
}

MOTO

In order to flag a payment as moto, an new input parameter is added to the API.

Name Type Size Format Inclusion Description
moto string Possible Values:
mail
telephone		 Optional Indicate if the payment is initiated via a mail or telephone order

Example API Request

{
    "amount" : 10.99,
    "currency" : "eur",
    "method" : "card",
    "returnUrl" : "https://shop.merchant.com/return?order=123456",
    "merchantOrderReference" : "123456",
    "description" : "Order 123456",
    "language" : "nld",
    "details": {
        "moto": "mail"
    }
}

Early adaptor migration

Some integrators required changes from CCV Pay before completion of the API. As a result, CCV Pay opted to use default values to apply for an MIT exemption if possible. These changes are only applicable to them who use our vault to provide the card data.

We strongly encourage everyone to migrate to the new API as the application of default values will be terminated in 2021.

Initial Customer Initiated Transaction

Before migration: no additional input was required. CCV Pay stored the initial transaction along with the vault access token.

After migration: flag the transaction as a CIT

{
  "sequenceInfo": {
    "type": "UNSCHEDULED",
    "mode": "INITIAL",
    "source": "CIT"
  }
}

First Subsequent Merchant Initiated Transactions

Before migration: only the vault access token was required

After migration: flag the transaction as an MIT

No initialTransactionId is available so CCV Pay will use the id as stored in the vault access token.

{
  "sequenceInfo": {
    "type": "UNSCHEDULED",
    "mode": "SUBSEQUENT",
    "source": "MIT"
  },
  "details": {
    "vaultAccessToken": "VAT_1"
  }
}

As a result of this MIT, the API response contains the initialTransactionId to be used in subsequent transactions.

{
  "details": {
    "initialTransactionId": "INITIAL_TX_ID_1"
  }
}

All the following Subsequent Merchant Initiated Transactions

Before migration: only the vault access token was required

After migration: flag the transaction as an MIT and include the initialTransactionId

Use the initialTransactionId of the previous transaction in the sequence chain.

{
  "sequenceInfo": {
    "type": "UNSCHEDULED",
    "mode": "SUBSEQUENT",
    "source": "MIT",
    "initialTransactionId": "INITIAL_TX_ID_1"
  },
  "details": {
    "vaultAccessToken": "VAT_1"
  }
}