Integrate our products into your software. Let's make payment happen together!
Look at all the possibilitiesThe European Payment Services Directive 2 Regulatory Technical Standard (PDS2 RTS) requires that all card-based transactions apply Strong Customer Authentication (SCA) starting January 1st, 2021.
These regulations add additional friction to the payment flow in the form of authentication of a cardholder. Transactions are allowed to request an exemption to reduce friction as much as possible at the cost of fraud protection. The use of exemptions will speed up the checkout process significantly but will require time to settle. For example, issuers will need to learn the interactions between cardholders and merchants to apply for exemptions by themselves or approve requested exemptions. Furthermore, the implementation of exemptions by the payment industry is still ongoing.
Aside from exemptions, the directive also defines several use cases that are out of scope for SCA which do not require any form of authentication. For example, a monthly subscription must be able to continue without the interaction of the cardholder. The only new requirement is that the initial transaction must use SCA.
Quote from Visa November 2018:
SCA exemptions are defined based on the level of risk, amount, recurrence and the payment channel used for the execution of the payment. These exemptions allow PSPs to achieve the right balance between convenience of the payment experience and fraud reduction. The SCA exemptions are available only to PSPs. The SCA exemptions are not available to merchants, unregulated payment gateways or other unregulated entities. The Issuer retains the ability to take the ultimate decision on the application of the exemption.
In this guide, we provide an overview of the currently available exemptions and show you how they can be requested using our PSP. Also, we list the most common use cases for exemptions and out of scope transactions to help you decide which are most suited for your business case.
CCV Pay supports all SCA exemptions but some require additional configuration of your account. Contact onlinepayments@ccv.eu in case you have any questions or when you are instructed to by the documentation.
If a transaction can benefit from an exemption or the risk of fraud is low, an exemption can be requested.
Actively monitoring for fraud and have mechanisms in place to prevent fraud, resulting in a low fraud rate, allows for the use of the TRA exemption. The TRA informs the issuer of the card that the risk analysis is performed before requesting the authorisation. A merchant or acquirer can request this exemptions, CCV Pay will not apply the exemption on your behalf. The merchant needs approval of the acquirer to apply the exemption. Without approval the acquirer may discard the exemption before sending to the issuer, or worse, reject the authorisation request.
Transactions below 30 euros do not require SCA. However, once every while, the issuer must verify the identity of the cardholder using SCA. The PSD2 RTS defines the frequency of these checks. The issuer is the one to confirm whether or not a transaction is subject to SCA. Using the LVP exemption is a last resort if you want to try to get an exemption for a payment.
The Trusted Beneficiary exemption is applicable when a cardholder explicitly agrees to trust the merchant for future payments. Explicitly means that you must inform the cardholder what the intent of the request is and register the choice of the cardholder. Do not imply the choice of the cardholder e.g. using a hidden checkbox. By not clearly stating the request for trust, the risk of fraud or disputes can increase.
This exemption can also be applied by the issuer. The issuer can ask the cardholder during the authentication process to trust you. In the future, CCV Pay will add to the API if the issuer questioned the cardholder and the cardholder’s choice.
Mastercard and Visa require additional setup before you can use this exemption. Also, there are additional costs per scheme. If you would like to benefit from this exemption, contact our customer support with your request.
A Secure Corporate Payment utilizes a corporate card. Identification of these cards are critical to apply for the exemption. These kind of cards are common in the travel and hospitality sector.
Acquirers and issuers can identify these cards and apply for the exemption on your behalf. They will be held liable in case of fraud.
A recurring or instalment transaction is part of a sequence or chain initiated by the merchant. The initial transaction of the chain requires SCA to set up an agreement between the merchant and the cardholder. The merchant can use the agreement as a mandate for subsequent transactions.
Due to the similarities with a merchant initiated transaction, Visa and Mastercard define the same requirements for recurring/instalment.
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.
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.
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.
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.
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.
The new regulation has implications on the liability in case of a fraudulent transaction. In general, the following applies:
SCA exemptions are like all aspects of SCA only applicable for card payments. Bancontact does not support 3-D Secure 2. Requesting an exemption for Bancontact will have no impact.
There are 4 standardized exemptions as defined in the PSD2 RTS. See authentication exemptions for a detailed explanation.
Request an exemption for a payment by adding $details.authExemption
to the request
with one of the following values.
Name | Description |
---|---|
TRANSACTION_RISK_ANALYSIS | Choose to trigger the Risk analysis for each transaction or to disable the TRA from being applied. |
LOW_VALUE | Transactions with an amount lower than 30 EURO. Every 5 transactions authentication is required or if the total amount of 100 euro non authenticated transactions is exceeded. |
SECURE_CORPORATE | Business to Business. |
TRUSTED_BENEFICIARY | A cardholder can indicate that the merchant is trusted and that authentication is no longer required. |
Initiate a new transaction with the 3-D Secure 2 compliant data
{
"amount" : 10.99,
"currency" : "eur",
"method" : "card",
"returnUrl" : "https://shop.merchant.com/return?order=123456",
"merchantOrderReference" : "123456",
"description" : "Order 123456",
"language" : "nld",
"billingAddress": "Westvoortsedijk",
"billingCity": "Arnhem",
"billingState": "GE",
"billingPostalCode" :"6827 AT",
"billingCountry": "NL",
"billingHouseNumber": "55",
"accountInfo": {
"accountIdentifier": "7cec0016-0bf3-45c7-bc1a-7916750a39a2",
"accountCreationDate": "20190101",
"passwordChangeIndicator": "CHANGED_DURING_TRANSACTION",
"email": "john.doe@ccvlab.eu",
"workPhoneCountry": "31",
"workPhoneNumber": "11193500",
"authenticationMethod": "OWN_CREDENTIALS"
},
"merchantRiskIndicator": {
"deliveryEmailAddress": "johny.doe@ccvlab.eu",
"deliveryTimeframe": "SAME_DAY",
"passwordChangeIndicator": "CHANGED_DURING_TRANSACTION",
"shippingIndicator": "BILLING_ADDRESS"
},
"threeds2RequestInfo": {
"challengeIndicator": "NO_PREFERENCE",
"transactionType": "GOODS_AND_SERVICES_PURCHASE"
},
"details": {
"authExemption": "TRANSACTION_RISK_ANALYSIS"
}
}
CCV Pay responds with a generated transaction containing a unique payUrl
{
"method": "card",
"reference": "C200603121922297CB87E190.2",
"currency": "eur",
"created": 1591179562332,
"language": "nld",
"billingAddress": "Westvoortsedijk",
"billingCity": "Arnhem",
"billingPostalCode": "6827 AT",
"billingCountry": "NL",
"amount": 10.99,
"billingState": "GE",
"merchantOrderReference": "123456",
"billingHouseNumber": "55",
"returnUrl": "https://shop.merchant.com/return?order=123456",
"payUrl": "https://onlinepayments.ccv.eu/card/payment.html?reference=C200603121922297CB87E190.2",
"lastUpdate": 1591179562332,
"cancelUrl": "https://onlinepayments.ccv.eu/card/cancel/merchant?reference=C200603121922297CB87E190.2",
"description": "Order 123456",
"status": "pending",
"type": "sale"
}
Redirect the customer to the payUrl
The customer submits card data
CCV Pay sends the authorisation including the requested exemption to the issuer
Multiple scenario’s are possible
returnUrl
returnUrl
returnUrl
returnUrl
returnUrl
When using our vault
to provide the cardholders card data, you can also use the exemptions as
described above. The only addition is that you provide
the details.vaultAccessToken
as a reference to the card on file.
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.
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 |
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
{
"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"
}
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"
}
payUrl
returnUrl
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"
}
}
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"
}
}
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"
}
}
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 means payments initiated at an irregular interval, and possibly for changing amounts between payments.
Recurring is an MIT scenario where a fixed amount is withdrawn from the cardholders account at a regular interval.
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"
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"
}
An instalment is a MIT scenario where an amount is paid in multiple payments.
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"
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"
}
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"
}
}
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.
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"
}
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"
}
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"
}