CB2A 1.6 > Paiement récurrent

Qu’est-ce que le protocole CB2A 1.6

Dans le cadre de la DSP2 et plus particulièrement du 3DS 2, les protocoles d’échanges entre les commerçants et les émetteurs de cartes (banques, acquéreurs privatifs,…) se doivent d’évoluer. Ce protocole est indispensable car il inclut de nouveaux champs obligatoires à envoyer aux émetteurs dans le cas d’une demande d’autorisation. Ces nouveaux champs permettent aux émetteurs d’identifier correctement une transaction 3DS2 et de couvrir tous les cas d’autorisation. Ainsi les émetteurs maitrisent mieux le contexte de la demande d’autorisation pour :

  • gérer les cas d’exemptions
  • autoriser le frictionless
  • autoriser un paiement par Mastercard

Avec un protocole antérieur (et donc obsolète), le risque que vos paiements soient refusés est très élevé.

Cadre réglementaire DSP2 pour les paiements récurrents par carte bancaire

Quand il est question de paiement récurrent, il parait improbable que l’authentification forte soit imposée à chaque échéance. En effet, dans ce modèle le premier paiement est réalisé par l’acheteur. Les suivants sont automatiquement gérés par la plateforme de paiement suivant l’échéancier défini dès le début.

C’est pourquoi, les paiements récurrents sont exemptés d’authentification forte à partir de la deuxième transaction (c’est à dire pas d’interaction de l’acheteur pour valider le paiement à chaque échéance). Cela semble logique mais vous allez voir que si votre plateforme de paiement n’est pas à niveau, la gestion des abonnements peut devenir un vrai casse tête. Cela peut même saturer votre service client et paralyser votre activité.

En effet, dans le cadre de la DSP2, certaines règles de fonctionnement sont à prendre en compte.

  • Paiement en plusieurs fois et abonnement fixe (montant et échéances) : l’authentification forte doit s’effectuer sur le montant total
  • Abonnement à la consommation avec ou non une date de fin: l’authentification forte doit s’effectuer sur le montant de la première échéance
  • Les échanges avec l’émetteur de la carte doivent se baser sur le protocole CB2A 1.6, seul protocole permettant d’obtenir la « Référence unique de transaction » indispensable pour les échéances suivantes.
  • Lors de la demande d’autorisation au moment d’une échéance, la demande d’autorisation doit contenir dans l’identifiant de regroupement la « Référence unique de transaction »

Les deux derniers éléments correspondent à une référence de chainage. Terme utilisé dans le milieu du paiement.

La référence de chainage: Clef de voute de la conversion

Sans référence de chaînage, les demandes d’autorisations d’échéance (sans CVV) seront plus facilement rejetés par les émetteurs. Même s’il existe une période de grâce jusqu’à la fin de l’année (règle Banque de France), il est important dès que possible de:

  • migrer sur le protocole CB2A 1.6
  • stocker la référence d’archivage
  • la transmettre dans les demandes d’autorisation sans CVV

Pour vous garantir une gestion des paiements récurrents respectant la DSP2 tout en conservant une expérience acheteur idéal, Lyra permet de :

  • Effectuer l’authentification forte sur le bon montant en fonction du type de paiement récurrent
  • Converser en protocole CB2A 1.6
  • Stocker de manière hautement sécurisée la référence de chainage de chaque paiement récurrent

Ainsi avec Lyra vous pourrez améliorer votre taux d’acceptation et taux de conversion.

Envie d’en savoir plus?

Contactez-nous

 

Cet article pourrait aussi vous intéresser
Mastercard et CB2A 1.6 dans le cadre de l'authentification forte 3DS2

Mastercard & CB2A 1.6

Dans le cadre de la mise en place du 3DS2, Mastercard a enrichi le protocole d’autorisation. Il impose à la plateforme de paiement de fournir dans...