Cadre COF

Pour réutiliser les données de carte de vos clients pour des paiements ultérieurs, vous devez garantir leur utilisation équitable :

• Obtenez le consentement de vos clients pour stocker/réutiliser leurs données de carte sur notre plateforme.
• Définissez la portée de la réutilisation de leurs données de carte en les liant de manière traçable.

Pour cela, les systèmes de cartes ont établi le cadre "Card On File" (COF). Il fait des distinctions à divers niveaux qui jouent un rôle dans le stockage/l'utilisation des données de carte :

CIT vs MIT

Le cadre COF distingue deux types de transactions :

Transactions initiées par le client (CIT)

Transactions que vos clients initient activement dans votre boutique en ligne.

Ils fournissent soit des données de carte à stocker sous forme de token sur notre plateforme (pour la première transaction d'une série de paiements), soit réutilisent des données de carte déjà stockées sous forme de token (pour des transactions ultérieures d'une série de paiements).

Chaque série de paiements doit être initiée par une CIT. Cette transaction est le premier maillon d'une série de paiements, vous autorisant à réutiliser les données de carte pour les paiements ultérieurs.

Attention si votre entreprise est située en Europe, une première CIT doit être traitée avec SCA.

Transactions initiées par le commerçant (MIT)

Transactions que vous traitez au nom de vos clients.

Les MIT sont logiquement liées par une raison commerciale légitime. Cela peut être une instruction permanente ou une pratique de l'industrie.

Au lieu d'utiliser un token, vous liez les paiements individuels en faisant référence au payment.id de la CIT initiale avec laquelle vous avez commencé la série.

Chaque série de MIT doit être initiée par une CIT. Cette transaction est le premier maillon d'une série de paiements, vous autorisant à réutiliser les données de carte pour les paiements ultérieurs – soit en raison d'une instruction permanente, soit d'une pratique établie dans l'industrie.

Vous ne pouvez traiter des MIT sans SCA, car c'est vous qui initiez les paiements au lieu de vos clients.

Instructions permanentes vs pratique de l'industrie

Il existe deux types de MIT :

Instructions permanentes

Ce sont des transactions que vous devez traiter sur une base programmée et récurrente avec des montants/intervalles fixes (c'est-à-dire pour des abonnements). Sinon, certains paiements pour certains services peuvent se produire de manière non programmée, avec des montants/intervalles variables (c'est-à-dire des plans de paiement échelonnés ou des modèles de paiement à l'utilisation).

Les instructions permanentes nécessitent le consentement explicite de vos clients pour traiter les paiements ultérieurs.

Pratiques de l'industrie

Certains services peuvent nécessiter que vous collectiez des frais supplémentaires par rapport à une commande précédente, tels que :

• Pénalités de non-présentation : Appliquez des frais de pénalité pour des biens/services réservés par vos clients mais non récupérés (par exemple, des chambres d'hôtel). S'applique également dans les scénarios où vos clients ont accepté un achat mais n'ont pas respecté les conditions de l'accord.
• Charges différées : Appliquez des frais supplémentaires après la livraison des biens/services originaux.
• Expédition partielle : Recueillez les fonds pour une commande partiellement payée. S'applique également à l'hôtellerie et à la location de voitures pour des séjours/locations prolongés.
• Ré-soumission : Vous avez déjà fourni les biens/services à votre client, mais vous n'avez pas pu collecter les fonds au moment de la commande.

Ces transactions ne nécessitent pas le consentement explicite de vos clients pour traiter les paiements ultérieurs.

token vs paiement.id

Le cadre COF offre deux façons de traiter des paiements ultérieurs après une CIT réussie : via un token ou un payment.id. Chaque option comporte différents avantages, exigences et limitations :

token

Vous ne pouvez utiliser un token que pour des CIT ultérieures (cas d'utilisation C) mais pas pour des MITs. Le token restera le même tout au long de la série.

Un token est un profil de carte stocké en toute sécurité sur notre plateforme. Une chaîne au format UUID, il est retourné dans la propriété creationOutput.token (pour la requête CreatePayment) ou redirectPaymentMethodSpecificOutput.token/cardPaymentMethodSpecificOutput.token (dans GetHostedCheckoutStatus pour les requêtes CreateHostedCheckout). Trouvez un JSON pour créer un token via une CIT dans notre collection JSON.

Vous pouvez demander des CIT ultérieures avec un token via les API endpoints CreateHostedCheckout ou CreatePayment en combinaison avec CreateHostedTokenisation, en pré-remplissant le formulaire de paiement. Trouvez un JSON pour utiliser un token pour une CIT dans notre collection JSON.

La création d'un token n'a aucun impact sur votre niveau PCI.

payment.id

Vous ne pouvez utiliser un payment.id que pour des MITs ultérieures (cas d'utilisation D à J) mais pas pour des CITs. Chaque fois que vous traitez une MIT ultérieure, vous devez prendre le payment.id de la CIT initiale avec laquelle vous avez commencé la série.

Un payment.id est un identifiant unique d'une transaction sur notre plateforme. Il est retourné dans la propriété id (pour la requête CreatePayment) ou payment.id (dans GetHostedCheckoutStatus pour les requêtes CreateHostedCheckout).

Le payment.id est lié à des données de référence de systèmes de carte. C'est une référence pour les systèmes de cartes et pour l'émetteur de vos clients, désignant une transaction pour laquelle une carte spécifique a été utilisée. Ainsi, ce pointeur lie toutes les transactions appartenant à une série de paiements. Cela vous permet de traiter des paiements ultérieurs pour cette carte précise.

Vous pouvez demander des MITs ultérieures avec un payment.id via notre API endpoint dédié SubsequentPayment. Trouvez un JSON pour chaque scénario MIT dans notre collection.

Ce graphique montre les différences entre l'utilisation d'un token ou d'un payment.id tout au long d'une série de paiements COF :

Alors, comment pouvez-vous utiliser ce cadre lors du traitement des transactions ? Consultez nos cas d'utilisation, qui couvrent tous les scénarios possibles.