| 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). |
Prerequisites
- 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
- For subscription/recurring payments by card (CB, Visa, Mastercard):
- 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)
Premier paiement.
First payment
L'information de la demande de paiement récurrent est passé par l'object json The information for the recurring payment request is passed through the JSON object "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.
Example of a recurring payment request with a fixed amount debit, every day, starting on November 7 and ending on November 20.
| 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:
exemple: Suite à la demande précédente de paiement récurrent, un des paiement journalierThis data must be presented in subsequent requests:
Example: Following the previous request for recurring payment, one of the daily payments:
| 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.
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
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
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 :
|
Abonnement d'un montant et/ou d'une périodicité variable - CIT / MIT
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
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 :
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 :
2. Échéances suivantes de l'abonnement Les échéances suivantes d'un abonnement sont initiées par le marchand via :
|
Abonnement avec des cartes AMEX
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 |
|---|


