| Tip | ||
|---|---|---|
| ||
|
| Info | ||
|---|---|---|
| ||
|
Description
This section explains how to implement card subscriptions that comply with PSD2 regulations on Axepta Online for CB, VISA, and Mastercard cards.
Axepta Online supports two types of subscriptions:
Fixed Amount and Frequency Subscription for a defined duration: The amount, frequency, and duration are known at the time of subscription
Variable Subscription (CIT/MIT): For cases where the amount, frequency or duration are not known at the time of subscription (tacit renewal)
| Note |
|---|
The subscription type must be determined at the time of enrollment and cannot be changed during the subscription period. If you wish to switch from a fixed-duration subscription to a variable subscription, you will need to re-enroll your customer (new CIT - Customer Initiated Transaction - with 3DS authentication). |
Prérequis
Prerequisites
- For subscription/recurring payments by card Vous souhaitez l'abonnement / paiement récurrent par carte
- (CB, Visa, Mastercard):
- Définir quel type d'abonnement vous allez proposer à vos clients (cf. ci-dessous)
- Recueillir le consentement de votre client pour la souscription d'un nouvel abonnement (côté marchand)
- Stocker les données suivantes
- L'objet JSON Card contenant : le numéro de carte tokenisé, la marque de la carte et la date d'expiration
- Le schemeReferenceID reçu en réponse de la transaction d'initialisation de l'abonnement
Premier paiement.
- Choose which kind of subscription you will use (see below)
- Obtain your client's consent for the new subscription (on merchant side)
- Store the following data:
- The JSON object Card containing: The tokenized card number (PCNr), The card brand, The expiration date
- The schemeReferenceID received in response to the first transaction (subscription initiation transaction)
First payment
The information for the recurring payment request is passed through the JSON object "credentialOnFile".
Example of a recurring payment request with a fixed amount debit, every day, starting on November 7 and ending on November 20
L'information de la demande de paiement récurrent est passé par l'object json "credentialOnFile"
Exemple, d'une demande de paiement récurrent avec un débit d'un montant fixe, tous les jours, commençant le 07 nov et finissant le 20 nov.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
......
"credentialOnFile" : {
"type" : "RECURRING",
"initialPayment": true,
"recurring" : {
"useCase" : "FIXED",
"frequency" : "DAILY",
"startDate" : "2025-11-07",
"expiryDate" : "2025-11-20"
}
},
......
} |
Once the first payment is accepted, the data needed for subsequent payments are available in the response to the transaction status request query
(API documentation link
Une fois ce premier paiement accepté, les données nécessaire aux paiement successifs sont disponibles dans la réponse à la requête de demande de statut de la transaction
(lien vers la doc swagger de l'api: Retrieve payment details by Payment ID ou Retrieve payment details by Transaction ID)
Les données à sauvegarder sont:
Le numéro de carte tokenisé: le parametre:The data to be saved are:
- The tokenized card number: the parameter 'pseudoCardNumber'
- The scheme Reference
- ID: the parameter 'schemeReferenceId'
Elles doivent être présentées lors de demande suivantes:
This data must be presented in subsequent requests:
Example: Following the previous request for recurring payment, one of the daily paymentsexemple: Suite à la demande précédente de paiement récurrent, un des paiement journalier :
| Code Block | ||||
|---|---|---|---|---|
| ||||
{
......
"credentialOnFile": {
"type" : "RECURRING",
"initialPayment": false,
"recurring" : {
"useCase" : "FIXED",
"frequency" : "DAILY",
"startDate" : "2025-11-07",
"expiryDate" : "2025-11-20"
}
},
"paymentMethods": {
"integrationType": "HOSTED",
"type" : "Card",
"card" : {
"brandSelection": "MERCHANT", // "CUSTOMER" ou "MERCHANT"
"prefillInfo": {
"number": "0701953701953810", // {{PCnrForStoredCredentials}}
"securityCode": "123",
"expiryDate": "203003",
"cardHolderName": "{{firstName}} {{lastName}}",
"brand" : "VISA"
},
"schemeReferenceId" : "1123456"
}
}
......
} |
Mise en place d'un abonnement
La mise en place d'un abonnement s'effectue en 2 étapes :
- Enrôlement du client : Initialisation de l'abonnement lors de la 1ère échéance
- La 1ère transaction, initiée par le client, sera authentifiée en 3DSV2. On parlera alors de CIT ou Customer Initiated transaction.
- Cette transaction ne pourra pas bénéficier d'une demande d'exemption de l'authentification 3DS.
- Une valeur de chaînage sera envoyée dans la réponse de cette transaction. Elle sera stockée par le marchand et utilisée dans toutes les échéances suivantes de l'abonnement (cf. schéma ci-dessous).
- La 1ère transaction, initiée par le client, sera authentifiée en 3DSV2. On parlera alors de CIT ou Customer Initiated transaction.
- Echéances suivantes de l'abonnement
- Les requêtes de paiement suivantes seront initiéées par le marchand. On parlera de MIT ou Merchant Initiated transaction.
- Elles contiendront la valeur de chaînage reçue en réponse de la transaction d'initialisation de l'abonnement.
- Les requêtes de paiement suivantes seront initiéées par le marchand. On parlera de MIT ou Merchant Initiated transaction.
Mise en place d'un abonnement
Focus : Chaînage des transactions
Une donnée clé
La 1ère échéance d'un abonnement permet de récupérer une donnée de chaînage qui sera utilisée pour relier ("chaîner") les échéances suivantes à cette 1ère échéance.
La donnée de chaînage, reçue en réponse de l'échéance d'initialisation de l'abonnement, est générée soit par la banque du porteur soit par le scheme utilisé (Visa, Mastercard).
Dans la documentation Axepta Online, la donnée de chaînage est renseignée dans le paramètre schemeReferenceID.
Principes
Chaînage des transactions d'un abonnement
Implémentation de l'abonnement
Subscription flows
The subscription setup process involves two main steps:
Customer Enrollment: Subscription Initialization at First Due Date
- The first transaction, initiated by the customer, will be authenticated using 3DSV2. This is referred to as a CIT (Customer-Initiated Transaction).
- This transaction will not be eligible for 3DS authentication exemption.
- A chaining value will be included in the transaction response. This value must be stored by the merchant and used for all subsequent subscription payments (see diagram below).
Subsequent Subscription Payments
- Subsequent payment requests will be initiated by the merchant. These are referred to as MIT (Merchant-Initiated Transactions).
- These requests will include the chaining value received in response to the subscription initialization transaction.
Subscription flows
Focus on transactions chaining
A key data
The first installment of a subscription allows you to retrieve a chaining data that will be used to link ("chain") subsequent installments to this first installment.
The chaining data, received in response to the subscription initialization installment, is generated either by the cardholder's bank or by the scheme used (Visa, Mastercard).
In the Axepta Online documentation, the chaining data is specified in the schemeReferenceID parameter.
Principles
Transactions chaining
Subscription implementation
Subscription for a fixed amount and frequency over a defined period
| Expand | ||
|---|---|---|
| ||
ExampleThe customer subscribes to a gym for 1 year for € 34.99 per month
1. Client enrolement : subscription initiation transaction
The first transaction, initiation of the subscription, will be processed through :
2. Subsequent transactionsSubsequent transactions are initiated by the merchant through |
Abonnement d'un montant et d'une périodicité fixes sur une durée définie
| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
ExempleLe client s’abonne à un gymnase pour 1 an au prix de 34,99 € par mois
1. Enrôlement du client : Initialisation de l'abonnement lors de la 1ère échéance
La création de la première échéance d'un abonnement est effectuée au cours d'un parcours de paiement via :
2. Échéances suivantes de l'abonnement Les échéances suivantes d'un abonnement sont initiées par le marchand via :
|
|
Subscription with a variable amount and/or frequency - CIT / MIT
| Expand | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
A variable subscription corresponds to a subscription whose amount varies during the subscription and/or whose duration is not known at the time of subscription. ExamplesThe customer subscribes to a service with a package and monthly consumptions:
L'abonnement variable correspond à un abonnement dont le montant varie au cours de l'abonnement et / ou dont la durée n'est pas connue lors de la souscription. ExemplesLe client s’abonne à un service avec un forfait et des consommations mensuelles
Ou le client s'abonne à un service avec tacite reconduction mensuelle : Or the customer subscribes to a service with monthly tacit renewal:
1. Enrôlement du client : Initialisation de l'abonnement lors de la 1ère échéanceLa création de la première échéance d'un abonnement est effectuée au cours d'un parcours de paiement via :
The creation of the first deadline of a subscription is carried out during a payment process via:
2. Subsequent transactionsSubsequent transactions are initiated by the merchant through Échéances suivantes de l'abonnementLes échéances suivantes d'un abonnement sont initiées par le marchand via :
|
Abonnement avec des cartes AMEX
|
Subscription with AMEX cards
Card subscriptions, compliant with PSD2, on Axepta Online for AMEX cards require the use of the TransactionID parameter instead of the schemeReferenceID parameter (request and response Les abonnements par carte, conformes à la DSP2, sur Axepta Online pour les cartes AMEX nécessite l'usage du paramètre TransactionID à la place du paramètre schemeReferenceID (requête et réponse).
| Table of Contents |
|---|