GuidesRéférence APIChangelog
Log In
Guides

Cycle de vie des cartes

Vue d'ensemble

Un paiement par carte de crédit passe par de nombreuses étapes, depuis le titulaire de la carte proposant sa carte comme mode de paiement jusqu'au commerçant recevant les fonds sur son compte bancaire. Utilisez le guide ci-dessous pour mieux comprendre chaque phase du paiement par carte.


1. Acceptation de la carte

Le titulaire de la carte saisit les données de sa carte dans un formulaire sécurisé.

Dans le traitement des paiements en ligne, ce formulaire est présenté sur un site Web ou une application mobile, demandant le numéro de carte de crédit (parfois appelé numéro de compte personnel ou PAN), la date d'expiration et les données de vérification de la carte (CVD). Moneris propose des solutions à intégrer à votre site Web en ligne pour collecter les données de carte de manière sécurisée, telles que la transformation en jetons hébergés ou le paiement Moneris. Vous pouvez également développer votre propre solution pour collecter les données des cartes, mais cela nécessite la conformité PCI pour garantir la sécurité des données.


2. Authentification du titulaire de la carte

Le titulaire de la carte prouve son identité à sa banque émettrice.

Pour des services tels que 3-D Secure, cela peut impliquer une expérience transparente avec la banque utilisant les détails de l'appareil issus de la session de navigateur du titulaire de la carte pour confirmer son identité. Il peut également s'agir d'une demande plus directe de codes d'accès sous forme de défi ou d'un texte avec un code temporaire à saisir dans une application bancaire.


3. Autorisation de la carte

Moneris s'assure que la carte est valide, que les fonds sont disponibles et réserve des fonds pour le commerçant.

Une autorisation ou une préautorisation peut avoir lieu au cours de cette phase en fonction du type de transaction sélectionné par le commerçant.

  • L'autorisation est utilisée pour les retenues de fonds à court terme. Le montant final capturé est le même que le montant autorisé. Ce type est utilisé dans une transaction d'achat.

  • La préautorisation est utilisée pour les retenues temporaires de fonds d'une durée comprise entre 7 et 31 jours. Le montant final capturé peut différer de la retenue temporaire dans les limites autorisées par chaque marque de carte.

    • La banque émettrice et le secteur d'activité du commerçant (catégorie de commerçant) peuvent influencer la période de détention des fonds.
    • Les marques de cartes (card brand) permettent aux entreprises de récupérer les fonds détenus à un prix inférieur au montant initial. Ceci est souvent utilisé dans les affaires pour les agences de location qui prennent un « dépôt de garantie » pour les frais potentiels qui peuvent ou non être engagés.

Jusqu'à ce qu'une préautorisation soit capturée, elle reste éligible à l'annulation.


4. Capturer

Moneris veille à ce que les fonds sur la carte soient déposés sur le compte bancaire du commerçant.

Tous les paiements capturés s'accumulent dans un_ lot ouvert_, un ensemble de transactions

Jusqu'à la clôture du lot, un paiement capturé peut être annulé. L'annulation d'un paiement capturé qui a utilisé la préautorisation à l'étape précédente ne permet pas la réutilisation de cette préautorisation ; le commerçant doit recommencer le processus de paiement s'il souhaite débiter la carte d'un montant différent.

Les comptes marchands utilisant les produits Moneris Gateway voient leur lot fermé automatiquement à 23 heures le soir. Si un commerçant souhaite clôturer son lot à un moment différent qui correspond à son modèle économique, l'automatisation peut être ajustée dans le centre de ressources pour commerçants de son compte.


5. Informations d'identification au dossier

Les titulaires de carte peuvent autoriser les commerçants à enregistrer leurs méthodes de paiement en tant qu'identifiants stockés pour les utiliser lors de transactions ultérieures. Cependant, les transactions impliquant le stockage ou l'utilisation d'informations d'identification nécessitent que les commerçants identifient leur utilisation dans le cadre de scénarios et de pratiques commerciales courants. L'identification correcte des informations d'identification stockées permet d'améliorer le traitement des transactions via le processus d'approbation des autorisations, améliore la visibilité du risque de transaction pour Moneris et les émetteurs, et améliore l'expérience du titulaire de carte.

Les commerçants peuvent choisir de stocker en toute sécurité leurs informations d'identification dans leurs dossiers auprès de Moneris via notre API et de recevoir un paymentMethodID en réponse. Les commerçants peuvent conserver en toute sécurité ces identifiants sous forme de jetons dans leurs propres dossiers et systèmes sans avoir besoin de certification selon les coûteuses normes de sécurité des données de l'industrie des cartes de paiement (PCI DSS) requises pour gérer eux-mêmes les informations d'identification de paiement enregistrées dans leurs dossiers.


Qu'est-ce qui constitue un identifiant stocké ?

Les données ne deviennent des informations d'identification stockées dans un dossier que lorsqu'un titulaire de carte consent à ce que les données de sa carte soient utilisées par un commerçant dans le cadre d'un profil client destiné au traitement de transactions futures. Les commerçants qui conservent uniquement temporairement les données de carte dans le cadre d'un paiement unique avec plusieurs appels API ne sont pas considérés comme stockant un identifiant dans leur dossier.

Certains accords peuvent inclure des conditions sur la manière dont le mode de paiement stocké est destiné à être utilisé, telles que :

  • Une série récurrente de paiements pour un montant fixe par paiement selon un calendrier fixe
  • Une série récurrente de paiements d’un montant variable par paiement selon un calendrier fixe
  • Une série de versements pour un achat unique avec un montant total connu traité en tant que transactions composantes sur une durée spécifiée

Les informations d'identification stockées dans le cadre de ces accords ne peuvent être utilisées que aux fins prévues.

Certains accords peuvent permettre au commerçant d'utiliser le mode de paiement stocké pour n'importe quel scénario d'utilisation. Ceux-ci inclus:

  • N'importe laquelle des séries mentionnées ci-dessus
  • Transactions non planifiées sans montants fixes convenus au préalable, initiées par le commerçant
  • Transactions non planifiées initiées par le titulaire de la carte

Divulgation et consentement du titulaire de carte

Les marques de cartes exigent que les commerçants divulguent leur intention de stocker les données du titulaire de la carte comme identifiant pour une utilisation future et établissent le consentement du titulaire de la carte. L'accord doit comprendre :

  • Une version tronquée des informations d'identification stockées (les quatre derniers chiffres de la carte ou du numéro de compte)
  • Comment le titulaire de la carte sera informé de toute modification apportée au consentement
  • La date d'expiration du consentement (le cas échéant)
  • Comment les informations d'identification stockées seront utilisées par le commerçant

Stockage et utilisation des informations d'identification stockées

Les méthodes de paiement peuvent être créées via le point de terminaison POST Create Payment pour enregistrer temporairement les données en tant que paymentMethodID. Lors d'une validation ou d'un paiement, vous pouvez choisir de convertir le mode de paiement en un identifiant permanent enregistré via le champ storePaymentMethod. A ce moment, vous devez indiquer les intentions du commerçant pour le mode de paiement stocké :

  • MERCHANT_INITIATED (initié par le commerçant) indique le stockage permanent du mode de paiement pour tous les types de transactions ultérieures, qu'elles soient initiées par le titulaire de la carte ou par le commerçant.
  • CARDHOLDER_INITIATED (initié par le titulaire de la carte) indique le stockage du mode de paiement uniquement pour les transactions ultérieures non planifiées initiées par le titulaire de la carte uniquement.
  • DO_NOT_STORE (ne pas stocker) empêchera l'API de Moneris de stocker les données de paiement comme identifiant pour une utilisation future.

Si l'une des options de stockage est sélectionnée, Moneris demande au commerçant de remplir l'objet credentialOnFileInformation en fournissant des détails sur l'utilisation prévue du justificatif d'identité ; les transactions ultérieures suivront également les scénarios d’utilisation. Notre référence API pour l'objet et son champ couvre les valeurs possibles individuellement, mais vous souhaiterez peut-être consulter les tableaux ci-dessous pour les combinaisons possibles de paymentIndicator et paymentInformation afin de mieux comprendre les pratiques commerciales selon lesquelles un commerçant doit suivre les informations relatives aux informations d'identification dans son dossier. Les tableaux sont divisés en premières transactions, où le mode de paiement est saisi par le titulaire de la carte et stocké en tant qu'identifiant dans le dossier du commerçant, et en transactions ultérieures où l'identifiant est utilisé par la suite.


Premières transactions pour les informations d'identification stockées

Lors du stockage d'un identifiant pour une utilisation future, le commerçant doit soumettre les intentions concernant l'identifiant en tant qu'indicateur de paiement lors de la première validation ou paiement. Dans la réponse, le commerçant reçoit un identifiant d'émetteur qui servira de lien entre cette première transaction et toutes les suivantes.


Scénario

Description

Exemple

Valeurs

Ad hoc use (Utilisation ponctuelle)

CLe titulaire de la carte s'engage à conserver son mode de paiement pour tout type d'utilisation future. Ces informations d'identification sont utilisables pour tout type de transaction ultérieure, qu'elle soit initiée par le titulaire de la carte ou par le commerçant.

Lors du paiement sur un site Web marchand, le titulaire de la carte crée un compte stockant les informations de sa carte pour sa prochaine expérience d'achat en ligne.

paymentIndicator = UNSCHEDULED_CREDENTIAL_ON_FILE
paymentInformation = FIRST

Subscription (Abonnement)

Le titulaire de la carte accepte une série de paiements pour un montant fixe selon un calendrier fixe.

La première transaction d'adhésion avec des frais mensuels.

paymentIndicator = RECURRING
paymentInformation = FIRST

Standing Order (Ordre permanent)

Le titulaire de la carte accepte une série de paiements d’un montant variable selon un calendrier fixe.

La première transaction pour une facture d’électricité mensuelle ou un forfait de données de téléphonie mobile.

paymentIndicator = VARIABLE_RECURRING paymentInformation = FIRST


Transactions ultérieures utilisant des informations d'identification

Lorsqu'il utilise un identifiant stocké, le commerçant doit soumettre le scénario le mieux adapté ci-dessous comme indicateur de paiement dans la transaction suivante. La valeur dans issuerID dans cette transaction suivante doit correspondre à celle renvoyée dans la réponse de la première transaction précédente.


Scénario

Description

Exemple

Valeurs

Unscheduled Cardholder-Initiated (Imprévu - Initié par le titulaire de la carte)

Toute transaction effectuée par le titulaire de la carte à l'aide de ses identifiants stockés

Achats en ligne avec une page de paiement qui pré-remplit les détails de paiement

Paymentindicator = Cardholder_Initiated
Paymentinformation = Subsequent
issuerID = identique à la première transaction

Unscheduled Merchant-Initiated ((Imprévu - Initié par le commerçant)

Marchand traitant une transaction conformément à un accord préétabli en dehors du champ d'application d'autres scénarios ultérieurs. Les montants peuvent varier ou être fixes, mais ne se produisent pas selon les horaires réguliers.

Recharges automatiques

Paymentindicator = Merchant_Initiated
Paymentinformation = Subsequent
issuerID = identique à la première transaction

Subscription (abonnement)

Marchand traitant une transaction selon un calendrier récurrent avec un montant fixe.

Frais de service mensuels souscrits après la première transaction

Paymentindicator = Recurring
Paymentinformation = Subsequent
issuerID = identique à la première transaction

Standing Order (ordre permanent)

Commerçant traitant une transaction selon un calendrier récurrent avec un montant variable.

Paiements mensuels des services publics après la première transaction

Paymentindicator = Variable_Recurring
Paymentinformation = Subsequent
issuerID = identique à la première transaction