Transactions avec informations d'identification stockées
Les sections suivantes décrivent comment soumettre les transactions initiées par le titulaire de la carte et par le commerçant (CIT et MIT) au Mastercard Gateway afin de se conformer aux normes des systèmes de cartes pour le traitement de ces transactions :
- Paiements initiés par le titulaire de la carte :
- Instructions générales
- Lors de l'utilisation de l'authentification 3-D Secure (3DS)
- Lors de l'utilisation de Hosted Checkout avec des informations d'identification stockées
- Lors de l'utilisation de Hosted Checkout pour obtenir une autorisation pour des transactions initiées par le commerçant futures
- Paiements initiés par le commerçant :
Pour des informations générales sur les scénarios ci-dessus, voir Paiements initiés par le titulaire de la carte et le commerçant. Pour des exemples complets de demandes pour tous les scénarios, téléchargez la collection Postman.
Chaque fois que vous soumettez plusieurs paiements dans une série, la première transaction doit être une transaction initiée par le titulaire de la carte qui fournit l'approbation du titulaire de la carte pour l'ensemble de la série. Les transactions ultérieures sont généralement des transactions initiées par le commerçant. Dans toutes les demandes, vous pouvez utiliser le champ transaction.source pour identifier si une transaction est initiée par le titulaire de la carte ou par le commerçant, et le champ sourceOfFunds.provided.card.storedOnFile pour indiquer si les détails du paiement doivent être stockés, ont été précédemment stockés, ou si vous avez l'intention de les stocker. Pour plus d'informations, voir la rubrique Questions fréquentes.
- Les scénarios ci-dessus sont pris en charge à compter de la version 74 de l'API.
- Pour pouvoir soumettre des transactions initiées par le commerçant, votre Your payment service provider doit avoir activé MERCHANT en tant que source de transaction autorisée sur votre lien commerçant-acquéreur.
- Si vous souhaitez stocker les informations de paiement du payeur sur la passerelle et utiliser un jeton pour faire référence aux informations stockées, votre prestataire de services de paiement doit configurer le profil du commerçant pour la segmentation en jetons de la passerelle.
Informations générales sur les transactions initiées par le titulaire de la carte
Une transaction initiée par le titulaire de la carte peut être un paiement unique pour lequel vous ne stockez généralement pas les détails de paiement fournis par le payeur. Cependant, le payeur peut consentir à ce que vous stockiez ses détails de paiement pour une utilisation future (généralement dans le cadre d'un processus d'enregistrement de client ou de création de compte) afin que vous puissiez proposer des transactions ultérieures initiées par le titulaire de la carte en utilisant les informations de paiement stockées.
- Lors de la demande de transaction initiale avec un nouveau client, vous devez renseigner les champs suivants :
sourceOfFunds.type = CARDouSCHEME_TOKENLa valeur varie selon que vous fournissez les données brutes de la carte ou un jeton (les détails de la carte ayant déjà été segmentés en jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source = INTERNETLa valeur indique à la passerelle que la transaction est initiée par le titulaire de la carte. Vous pouvez définir la valeur avec la valeur
INTERNET,MOTO,MAIL_ORDER,TELEPHONE_ORDER,VOICE_RESPONSEouCALL_CENTER.sourceOfFunds.provided.card.storedOnFile = TO_BE_STOREDLa valeur indique que le payeur accepte que vous stockiez ses informations de paiement pour une utilisation ultérieure.
INTERNET est utilisée. Cependant, vous devez indiquer le canal par lequel vous avez reçu le paiement.Pour tout paiement ultérieur initié par le payeur (et non par vous) et lorsque les détails de paiement stockés par le payeur sont utilisés, vous devez fournir les champs suivants dans la demande :
-
sourceOfFunds.type = CARDouSCHEME_TOKENLa valeur dépend du fait que les détails ont été stockés par vous ou par la passerelle (auquel cas vous fournissez un jeton).
-
Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token -
transaction.source = INTERNET -
sourceOfFunds.provided.card.storedOnFile = STORED
Pour plus d'informations sur la manière d'indiquer à la passerelle comment et si les données de paiement doivent être stockées, voir la rubrique Questions fréquentes.
Transaction initiée par le titulaire de la carte avec 3DS
Les transactions initiées par le titulaire de la carte peuvent être authentifiés avec l'authentification 3DS pour identifier le titulaire de la carte et prévenir la fraude. Vous pouvez utiliser 3DS pour :
- des transactions initiées par le titulaire de la carte ponctuelles,
- des transactions initiées par le titulaire de la carte qui constituent la première étape d'une série de paiements, les suivants étant des transactions initiées par le commerçant,
- des scénarios dans lesquels vous souhaitez authentifier le titulaire de la carte lors de l'ajout de sa carte au compte client pour une utilisation ultérieure.
Le tableau suivant décrit différents cas d'utilisation détaillés relatifs à l' authentification 3DS. Pour plus d'informations sur l'authentification 3DS dans la passerelle et sur l'utilisation de l'autorisation externe dans les transactions de paiement, voir Authentification 3DS.
| Cas d'utilisation | Étapes d'intégration |
|---|---|
Entente avec le payeur pour des paiements récurrents, y compris un montant initial dans la transaction initiée par le titulaire de la carte |
Étape 1: Effectuez l'authentification comme décrit dans les consignes d'authentification et précisez le montant requis pour le paiement initial. Étape 2: Créez la demande de transaction initiée par le titulaire de la carte avec les détails définis dans la rubrique Paiements initiés par le titulaire de la carte et ajoutez l'un des éléments suivants :
|
|
Entente avec le payeur pour des paiements récurrents, y compris aucun montant initial dans la transaction initiée par le titulaire de la carte |
Ce cas d'utilisation couvre des séries de paiements récurrents pour lesquels aucun paiement n'est dû au moment où le payeur s'inscrit au service. Lors de l'authentification comme décrit dans la rubrique Authentification 3DS, utilisez les champs supplémentaires spécifiés dans les étapes suivantes pour intégrer 3DS pour les paiements récurrents. Étape 1: Effectuez l'opération INITIATE AUTHENTICATION (Initier l'authentification) et définissez authentication.purpose avec la valeur ADD_CARD ou MAINTAIN_CARD. Étape 2: Exécutez l'opération AUTHENTICATE PAYER (Authentifier le payeur) avec les champs suivants :
Étape 3: Dans le cadre de la demande de transaction initiée par le titulaire de la carte, effectuez la demande d'opération VERIFY (Vérifier) et ajoutez l'un des éléments suivants :
Si vous utilisez l'intégration Hosted Session, suivez les étapes 1 et 2 au sein de la session, puis utilisez l'ID de session (de la session créée pour les étapes 1 et 2) lors de l'envoi de la demande depuis votre serveur à l'étape 3.
|
|
Ajouter une carte sans entente de paiement |
Ce cas d'utilisation couvre un scénario dans lequel le payeur souhaite ajouter les détails de sa carte lors de la création de son profil ou de son compte client sans paiement immédiat. Le payeur peut utiliser la carte enregistrée à l'avenir pour des paiements ponctuels ou pour établir une entente de paiement pour une série de paiements. Étape 1: Effectuez l'opération INITIATE AUTHENTICATION (Initier l'authentification) et définissez authentication.purpose avec la valeur ADD_CARD ou MAINTAIN_CARD. Étape 2: Exécutez l'opération AUTHENTICATE PAYER (Authentifier le payeur) et fixez le montant à 0. Étape 3: Dans le cadre de la demande de transaction initiée par le titulaire de la carte, effectuez la demande d'opération VERIFY (Vérifier) et ajoutez l'un des éléments suivants :
Si vous utilisez l'intégration Hosted Session, suivez les étapes 1 et 2 au sein de la session, puis utilisez l'ID de session (de la session créée pour les étapes 1 et 2) lors de l'envoi de la demande depuis votre serveur à l'étape 3.
|
Les champs suivants sont nécessaires dans l'opération AUTHENTICATE PAYER (Authentifier le payeur) pour réussir une transaction récurrente :
- Lors de l'utilisation de la version 61 de l'API ou une version ultérieure :
- agreement.id
- agreement.type=RECURRING
- agreement.numberOfPayments
- agreement.amountVariability
- agreement.expiryDate
- agreement.paymentFrequency
- agreement.minimumDaysBetweenPayments
Lors de l'utilisation des version 57 à 60 de l'API :
- agreement.id
- agreement.type=RECURRING
- agreement.expiryDate
- agreement.recurring.daysBetweenPayments
Transactions initiées par le titulaire de la carte avec Hosted Checkout et informations d'identification stockées
Pour créer une transaction initiée par le titulaire de la carte avec Hosted Checkout lorsqu'aucune information d'identification n'est stockée :
- Envoyez une demande d'opération INITIATE CHECKOUT (Lancer le paiement) avec
interaction.saveCardForCredentialOnFile = PAYER_INITIATED_PAYMENTS.Hosted Checkout fournit au payeur les options de paiement disponibles dans la fenêtre Options de paiement.
- Les informations d'identification enregistrées dans les scénarios Hosted Checkout sont prises en charge à compter de la version 74 de l'API et versions ultérieures.
- Si vous prenez en charge le mode de paiement Click to Pay, Hosted Checkout ne l'affiche pas séparément sur sa page de paiement. Il est demandé au payeur son adresse électronique et, s'il a un profil Click to Pay, les cartes qu'il a stockées pour son profil sont répertoriées dans la rubrique Débit ou crédit.
- Le payeur sélectionne Débit ou Crédit.
Hosted Checkout n'affiche ni ne crée de lien vers les conditions générales ou les politiques de confidentialité. Il est de votre responsabilité de fournir ces informations au payeur, comme l'exigent les réglementations ou les lois sur la confidentialité. - Le payeur peut payer avec ou sans consentement à la passerelle, c'est-à-dire en cochant ou sans cocher la case Enregistrer cette carte pour de futurs achats.
- Si le payeur procède au paiement sans donner son consentement, le traitement de paiement fonctionne comme d'habitude.
- Si le payeur procède au paiement avec son consentement, Hosted Checkout :
- Définit l'indicateur Carte dans le fichier correct
- Soumet la demande de transaction PAY (Payer) (si
interaction.operation=AUTHORIZE) avecsourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDettransaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS.
Vous devez vous conformer aux exigences du système et aux exigences réglementaires (par exemple, GDPR). Vous devez proposer au payeur la possibilité de retirer son consentement et de supprimer le jeton de passerelle.
Si le payeur paie avec une méthode autre qu'une carte de crédit, telle que ACH (Automated Clearing House) ou PayPal, la procédure de paiement standard s'applique. La passerelle stocke uniquement les détails de la carte, donc si vous souhaitez stocker des informations de paiement liées à d'autres modes de paiement, vous devez le faire vous-même après avoir reçu le consentement du payeur. - Une fois que la passerelle a redirigé le payeur sur le site Web de votre magasin, soumettez une demande d'opération
RETRIEVE_ORDER.- Si le payeur a donné son consentement, la réponse contient le champ
transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS. - Pour créer le jeton que vous pouvez utiliser pour faire référence aux informations d'identification stockées sur la passerelle, utilisez l'opération CREATE OR UPDATE TOKEN (Créer ou mettre à jour un jeton). Pour plus d'informations, voir Segmentation en jetons de la passerelle.
- Si le payeur a donné son consentement, la réponse contient le champ
- Pour tout paiement ultérieur initié par le titulaire de la carte, envoyez la demande d'opération INITIATE CHECKOUT (Lancer le paiement) avec :
interaction.tokenscontenant le jeton de passerelleinteraction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTSCe champ permet au payeur de saisir de nouvelles informations de carte et de les stocker, s'il ne souhaite pas utiliser les précédentes.
Hosted Checkout affiche les options de paiement disponibles et les cartes stockées au payeur.
- Si le payeur sélectionne Débit ou crédit , les détails du jeton sont répertoriés et le payeur peut choisir de payer avec le jeton ou d'ajouter les détails d'une autre carte.
Transactions initiées par le titulaire de la Carte avec Hosted Checkout pour autoriser les transactions initiées par le commerçant
Pour recueillir le consentement du payeur avec Hosted Checkout afin de stocker ses détails de paiement pour les transactions initiées par le commerçant ultérieures (par exemple, en créant un compte de payeur dans votre système et en stockant les détails sur le compte) :
- Envoyez une demande d'opération INITIATE CHECKOUT (Lancer le paiement) avec :
agreement.idvaleur unique que vous générez pour identifier une entente de paiement avec le payeur. Vous devez le soumettre lors des transactions initiées par le commerçant suivantes pour lier les paiements dans une série. Ceci est nécessaire pour se conformer aux mandats des systèmes de cartes où l'ID de l'entente agit comme un identifiant pour relier la transaction initiée par le titulaire de la carte précédente aux transactions initiées par le commerçant suivantes.
agreement.typeType d'entente commerciale établie avec le payeur.
- Les informations d'identification enregistrées dans les scénarios Hosted Checkout sont prises en charge à compter de la version 74 de l'API et versions ultérieures.
- Les détails de l'entente ne sont nécessaires que si vous avez l'intention de traiter ultérieurement les transactions initiées par le commerçant liés à la transaction initiée par le titulaire de la carte. Si vous avez l'intention de traiter uniquement les transactions initiées par le titulaire de la carte avec les détails de paiement stockés, aucune entente n'est nécessaire.
Hosted Checkout fournit au payeur les options de paiement par carte de débit ou de crédit.
- Vous devez vous conformer aux exigences du système et aux exigences réglementaires, par exemple, GDPR. Vous devez fournir au payeur la possibilité de retirer le consentement et de supprimer les informations d'identification stockées.
- Il est de votre responsabilité de vous assurer que les articles qui ne nécessitent pas d'entente ne soient pas inclus dans la commande ou la transaction.
- Le payeur ne peut continuer qu'en donnant son consentement, c'est-à-dire en cochant la case. Le bouton Payer est désactivé jusqu'à ce qu'il coche la case.
Si le payeur donne son consentement, Hosted Checkout soumet la demande de transaction avec les valeurs suivantes :
sourceOfFunds.provided.card.storedOnFile = TO_BE_STOREDtransaction.payerConsentForStoringCardDetails = MERCHANT_INITIATED_PAYMENTS
- Une fois que la passerelle a renvoyé le payeur sur votre site Web, soumettez une demande d'opération RETRIEVE ORDER (Extraire la commande) :
- Si le payeur a donné son consentement, la réponse contient le champ
transaction.payerConsentForStoringCardDetails = MERCHANT_INITIATED_PAYMENTS. - Si le payeur n'a pas donné son consentement, il ne peut pas continuer (abandon de panier).
- Si le payeur a donné son consentement, la réponse contient le champ
Paiements récurrents initiés par le commerçant
Vous pouvez soumettre des paiements récurrents pour traitement à la passerelle si vous avez une entente de paiement avec le payeur par laquelle le payeur accepte que vous stockiez ses détails de paiement pour une utilisation ultérieure et vous autorise à effectuer des paiements récurrents suivants sans sa participation active.
Dans la demande de transaction initiée par le titulaire de la carte initiale, vous devez renseigner les champs suivants pour configurer l'entente :
sourceOfFunds.type=CARDouSCHEME_TOKENLa valeur varie selon que vous fournissez les données brutes de la carte ou un jeton (les détails de la carte ayant déjà été segmentés en jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=INTERNET, andLa valeur indique à la passerelle que la transaction est initiée par le titulaire de la carte.
sourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDLa valeur indique que le payeur accepte que vous stockiez ses informations de paiement pour une utilisation ultérieure.
agreement.idvaleur unique que vous générez pour identifier une entente de paiement avec le payeur.
agreement.type=RECURRINGEntente d'instructions permanentes que vous avez établie avec le payeur.
- Lors de l'utilisation de la version 61 de l'API et des versions ultérieures :
agreement.numberOfPaymentsagreement.amountVariabilityagreement.expiryDateagreement.paymentFrequencyagreement.minimumDaysBetweenPayments
- Lors de l'utilisation des version 57 à 60 de l'API :
agreement.expiryDateagreement.recurring.daysBetweenPayments
Dans toute demande de transaction initiée par le commerçant ultérieure, vous devez fournir les champs suivants :
sourceOfFunds.type=CARDouSCHEME_TOKENLa valeur dépend du fait que les détails ont été stockés par vous ou par la passerelle (auquel cas vous fournissez un jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=MERCHANTLa valeur indique à la passerelle que la transaction est initiée par le commerçant.
sourceOfFunds.provided.card.storedOnFile=STOREDagreement.idIl doit s'agit de la même valeur agreement.id que celle fournie dans la transaction initiée par le titulaire de la carte initiale. Cela permet à la passerelle d'associer les paiements dans une série et est nécessaire pour se conformer aux mandats des systèmes de cartes où l'ID de l'entente sert d'identifiant pour relier la transaction initiée par le titulaire de la carte précédente aux transactions initiées par le commerçant suivants.
Paiements échelonnés initiés par le commerçant
Vous pouvez soumettre des paiements échelonnés pour traitement à la passerelle si le payeur accepte que vous stockiez ses informations de paiement pour une utilisation future et que vous ayez une entente de paiement avec le payeur pour fractionner un seul achat en plusieurs paiements traités à des intervalles convenus.
Dans la demande de transaction initiée par le titulaire de la carte initiale, vous devez renseigner les champs suivants pour configurer l'entente :
sourceOfFunds.type=CARDouSCHEME_TOKENLa valeur varie selon que vous fournissez les données brutes de la carte ou un jeton (les détails de la carte ayant déjà été segmentés en jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=INTERNETLa valeur indique à la passerelle que la transaction est initiée par le titulaire de la carte.
sourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDLa valeur indique que le payeur accepte que vous stockiez ses informations de paiement pour une utilisation ultérieure.
agreement.idvaleur unique que vous générez pour identifier une entente de paiement avec le payeur.
agreement.type=INSTALLMENTEntente d'instructions permanentes que vous avez établie avec le payeur.
- Lors de l'utilisation de la version 61 de l'API et des versions ultérieures :
agreement.numberOfPaymentsagreement.amountVariabilityagreement.expiryDateagreement.paymentFrequencyagreement.minimumDaysBetweenPayments
- Lors de l'utilisation des version 57 à 60 de l'API :
agreement.expiryDateagreement.recurring.daysBetweenPayments
Dans toute demande de transaction initiée par le commerçant ultérieure, vous devez fournir les champs suivants :
sourceOfFunds.type=CARDouSCHEME_TOKENLa valeur dépend du fait que les détails ont été stockés par vous ou par la passerelle (auquel cas vous fournissez un jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.tokenLa valeur indique à la passerelle que la transaction est initiée par le commerçant.
transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDagreement.idIl doit s'agit de la même valeur
agreement.idque celle fournie dans la transaction initiée par le titulaire de la carte initiale. Cela permet à la passerelle d'associer les paiements dans une série et est nécessaire pour se conformer aux mandats des systèmes de cartes où l'ID de l'entente sert d'identifiant pour relier la transaction initiée par le titulaire de la carte précédente aux transactions initiées par le commerçant suivants.
Paiements non planifiés initiés par le commerçant
Vous pouvez soumettre des paiements non programmés pour traitement à la passerelle si vous avez une entente de paiement avec le payeur par laquelle le payeur accepte que vous stockiez ses détails de paiement pour une utilisation ultérieure et vous autorise à effectuer des paiements non programmés suivants sans sa participation active.
Dans la demande de transaction initiée par le titulaire de la carte initiale, vous devez renseigner les champs suivants pour configurer l'entente :
sourceOfFunds.type=CARDouSCHEME_TOKENLa valeur varie selon que vous fournissez les données brutes de la carte ou un jeton (les détails de la carte ayant déjà été segmentés en jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=INTERNETLa valeur indique à la passerelle que la transaction est initiée par le titulaire de la carte.
sourceOfFunds.provided.card.storedOnFile=TO_BE_STOREDLa valeur indique que le payeur accepte que vous stockiez ses informations de paiement pour une utilisation ultérieure.
agreement.idvaleur unique que vous générez pour identifier une entente de paiement avec le payeur.
agreement.type=UNSCHEDULEDEntente d'instructions permanentes que vous avez établie avec le payeur.
- Lors de l'utilisation de la version 61 de l'API et des versions ultérieures :
agreement.numberOfPaymentsagreement.amountVariabilityagreement.paymentFrequency
- Lors de l'utilisation des version 57 à 60 de l'API :
agreement.expiryDateagreement.recurring.daysBetweenPayments
Dans toute demande de transaction initiée par le commerçant ultérieure, vous devez fournir les champs suivants :
sourceOfFunds.type=CARDouSCHEME_TOKENLa valeur dépend du fait que les détails ont été stockés par vous ou par la passerelle (auquel cas vous fournissez un jeton).
- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=MERCHANTLa valeur indique à la passerelle que la transaction est initiée par le commerçant.
sourceOfFunds.provided.card.storedOnFile=STOREDagreement.id: même agreement.id que celui fourni dans la transaction initiale. Cela permet à la passerelle de relier des paiements de la série.Il doit s'agit de la même valeur agreement.id que celle fournie dans la transaction initiée par le titulaire de la carte initiale. Cela permet à la passerelle d'associer les paiements dans une série et est nécessaire pour se conformer aux mandats des systèmes de cartes où l'ID de l'entente sert d'identifiant pour relier la transaction initiée par le titulaire de la carte précédente aux transactions initiées par le commerçant suivants.
Paiements selon les pratiques du secteur pour les transactions initiées par le commerçant
Vous pouvez soumettre des paiements selon les pratiques du secteur pour traitement à la passerelle si le payeur vous permet de stocker ses détails de paiement pour une utilisation future et vous autorise à initier des transactions initiées par le commerçant ultérieures sans la participation active de sa part.
Dans la demande de transactions initiées par le commerçant selon les pratiques du secteur, vous devez fournir les champs suivants :
order.industryPracticePaymentReasonType de paiement selon les pratiques du secteur que vous créez, par exemple DELAYED_CHARGE, NO_SHOW_PENALTY ou PARTIAL_SHIPMENT.
sourceofFunds.provided.card.storedOnFiles = STOREDLa valeur indique que le payeur a accepté que vous stockiez ses informations de paiement pour une utilisation ultérieure.
referenceOrderIdID de commande de la transaction initiée par le titulaire de la carte précédente. La passerelle utilise ce champ pour rechercher l'ID de trace de la transaction initiée par le titulaire de la carte précédente.
transaction.acquirer.traceidID de trace. Ce champ contient la valeur authorizationResponse.transactionIdentifier de la réponse de la transaction initiée par le titulaire de la carte initiale de la série. Ce champ est nécessaire uniquement si l'ID de commande de référence n'est pas disponible. Si vous fournissez un ID d'entente et ne fournissez pas d'ID de commande de référence ou d'ID de trace sur les cartes Mastercard traitées, Gateway fournira un ID de trace par défaut.
Exemple de flux selon les pratiques du secteur
Transaction initiée par le titulaire de la carte initiale :
order.id= "OD12345"transaction.id= "TRAN 1"agreement.id == "AGR 1"sourceOfFunds.type=CARDouSCHEME_TOKEN- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=INTERNETsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
Transaction initiée par le commerçant selon les pratiques du secteur suivante, soumise sous la forme d'une nouvelle transaction, en raison d'un retard de facturation :
order.id="OD45678"transaction.id= "TRAN 2"agreement.id == "AGR 1"sourceOfFunds.type=CARDouSCHEME_TOKEN- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEreferenceOrderId="OD12345"
Paiements de nouvelle soumission initiés par le commerçant
Vous pouvez soumettre à nouveau à la passerelle les paiements qui n'ont pas abouti si le payeur a accepté que vous conserviez ses détails de paiement pour une utilisation ultérieure et si la réponse de l'émetteur à l'échec du paiement ne vous interdit pas de réessayer plus tard.
Dans la demande de nouvelle soumission de la transaction initiée par le commerçant, vous devez fournir les champs suivants :
order.idEn cas de nouvelle soumission d'une transaction initiée par le commerçant, utilisez le même ID de commande que lors de la première transaction initiée par le commerçant, mais un nouveau transaction.id, car la passerelle n'autorise pas les ID de transaction en double dans la même commande.
transaction.resubmission = "true"Indication que cette transaction initiée par le commerçant est une nouvelle soumission pour une autorisation antérieure ayant échoué.
referenceOrderIdID de commande de la transaction initiée par le titulaire de la carte précédente. La passerelle utilise ce champ pour rechercher l'ID de trace de la transaction initiée par le titulaire de la carte précédente.
- Si la transaction initiée par le titulaire de la carte précédente a été effectuée en dehors de la passerelle, vous devez plutôt fournir :
transaction.acquirer.traceidID de trace. Ce champ contient la valeur
authorizationResponse.transactionIdentifierde la réponse de la transaction initiée par le titulaire de la carte initiale de la série. Ce champ n'est requis que si l'ID de commande de référence ne l'est pas. - Si vous fournissez un ID d'entente et ne fournissez pas d'ID de commande de référence ou d'ID de trace sur les cartes Mastercard traitées, Gateway fournira un ID de trace par défaut.
Exemple de flux de nouvelle soumission
Transaction initiée par le titulaire de la carte initiale :
order.id= "OD12345"transaction.id= "TRAN 1"agreement.id= "AGR 1"sourceOfFunds.type=CARDouSCHEME_TOKEN- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=INTERNETsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
Première transaction initiée par le commerçant, soumise en tant que paiement selon les pratiques du secteur en raison d'un retard de facturation :
order.id="OD5678"transaction.id= "TRAN 2"sourceOfFunds.type=CARDouSCHEME_TOKEN- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEreferenceOrderId="OD12345"
Après l'échec de la première transaction initiée par le commerçant en raison de fonds insuffisants, une deuxième transaction initiée par le commerçant est envoyée en tant que nouvelle soumission (même ordre) :
order.id="OD5678"transaction.id= "TRAN 3"sourceOfFunds.type=CARDouSCHEME_TOKEN- Les champs
sourceOfFunds.provided.card.*ousourceOfFunds.token transaction.source=MERCHANTsourceOfFunds.provided.card.storedOnFile=STOREDorder.industryPracticePaymentReason=DELAYED_CHARGEtransaction.resubmission="true"
Questions fréquentes
Comment puis-je indiquer à la passerelle comment les détails du paiement sont traitées ?
Pour respecter les normes des systèmes de cartes pour le traitement des transactions initiées par le titulaire de la carte et des transactions initiées par le commerçant, vous devez utiliser le champ sourceOfFunds.provided.card.storedOnFile pour indiquer à la passerelle si les détails de paiement sont stockés, non stockés, ou si vous avez l'intention de les stocker.
Pour la transaction initiée par le titulaire de la carte initiale :
- S'il s'agit d'un paiement unique et que vous n'avez pas l'intention de stocker les détails du paiement, omettez le champ
sourceOfFunds.provided.card.storedOnFiledans la demande. -
Si c'est la première fois que le payeur fait affaire avec vous et que ses détails de paiement n'ont pas été stockés auparavant, mais que vous avez maintenant l'intention de les stocker en vue d'une utilisation ultérieure, définissez
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED. Cela indique à la passerelle que le payeur a accepté que vous stockiez ses détails de paiement. Vous devez définir cette valeur indépendamment de :- Comment vous stockez les données de paiement : dans votre propre application ou sur votre propre site Web (vous devez être conforme à la norme PCI), ou en utilisant la segmentation en jetons de la passerelle ou du réseau.
- Que vous stockiez les détails du paiement avant ou après avoir soumis la transaction à la passerelle.
Si vous utilisez Hosted Checkout ou Hosted Session, vous pouvez stocker les informations de paiement à l'aide de la passerelle ou de la segmentation en jetons du réseau une fois la transaction initiée par le titulaire de la carte initiale effectuée et les informations de paiement fournies par le payeur à la passerelle. Utilisez l'opération CREATE OR UPDATE TOKEN (Créer ou mettre à jour un jeton) avec l'ID de session approprié.
Si vous utilisez Direct Payment ou Hosted Batch, vous pouvez stocker les détails avant ou après la fin de la transaction initiée par le titulaire de la carte initiale.
- Si le payeur est un client fidèle et vous avez déjà enregistré ses informations de paiement pour une autre commande, vous n'avez pas besoin de les stocker à nouveau. Toutefois, si vous utilisez la nouvelle transaction initiée par le titulaire de la carte pour créer une entente avec le payeur pour les futures transactions initiées par le commerçant liés à cette transaction initiée par le titulaire de la carte, définissez
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED. Cela indique à la passerelle que vous utiliserez ces détails pour les futures transactions initiées par le commerçant.
Pour les paiements ultérieurs, définissez sourceOfFunds.provided.card.storedOnFile=STORED pour indiquer que les informations d'identification enregistrées sont utilisées lors du paiement. Cela s'applique également dans les situations où le payeur revient et ses informations de paiement stockées sont utilisées pour une nouvelle transaction initiée par le titulaire de la carte qui ne nécessite aucune nouvelle entente pour les futurs transactions initiées par le commerçant.
Et si je n'ai pas d'ID entente ?
Si vous ne disposez pas d'un identifiant unique pour votre entente avec le payeur, vous pouvez :
- Générer un ID d'entente pour l'interaction avec la passerelle. Vous devez ensuite le stocker et le soumettre à la passerelle sur tous les paiements de la série, y compris la transaction initiée par le titulaire de la carte.
- Utiliser un identifiant existant (que vous stockez déjà dans votre système), par exemple, l'ID de commande pour le premier paiement de la série.
Utilisez toujours un ID d'entente si possible, car il s'agit d'une indication de valeur unique entre vous et le payeur. Par exemple, si le payeur doit renouveler sa police d'assurance, l'ID d'entente peut être le numéro de la police.
Dans certaines situations, vous n'aurez peut-être pas accès à l'ID d'entente d'origine. Par exemple :
- L'entente a été conclue il y a longtemps et les détails n'ont pas été enregistrés.
- Vous ne connaissez pas l'ID de l'entente initiale ou celle-ci a été conclue via une autre passerelle de paiement.
Dans ces cas, vous ne pouvez pas générer un nouvel ID d'entente, mais vous devez plutôt utiliser un ID de commande de référence ou un ID de trace.
L'ID de commande de référence reflète la dernière commande de la série de transactions. Par exemple, si la série de transactions est composée d'une transaction initiée par le titulaire de la carte initiale et de 2 transactions initiées par le commerçant ultérieures :
- La transaction initiée par le titulaire de la carte initiale a l'ID de commande = 1
- La première transaction initiée par le commerçant a l'ID de commande = 2 et utilise l'ID de commande de référence = 1 (en référence à la transaction initiée par le titulaire de la carte initiale)
- Le deuxième transaction initiée par le commerçant a l'ID de commande = 3 et utilise l'ID de commande de référence = 2 (en référence à la première transaction initiée par le commerçant, qui correspond au dernier ID de commande de la série)
L'ID de trace (également appelé ID de transaction du système) est un identifiant unique que tous les systèmes émettent pour chaque transaction traitée par leur intermédiaire. L'ID de trace est utilisé pour identifier les transactions associées, par exemple :
- Transaction CAPTURE (Collecter) ultérieure
- Annulation d'une transaction
- Transaction REFUND AUTHORIZATION (Autorisation de remboursement) liée
- Transaction suivante dans une série de paiements récurrents, échelonnés ou non planifiés
- Transaction AUTHORIZATION (Autorisation) à mettre à jour
Les systèmes utilisent différentes méthodes pour générer cet ID :
- Mastercard génère un ID qui combine :
- Code du réseau financier à 3 chiffres
- Numéro de référence Banknet (AN6)
- Date de la transaction (MMJJ)
- VISA génère un ID unique pour chaque transaction d'origine.
- Amex génère un ID unique pour chaque transaction d'origine.
Dois-je soumettre un paiement lors de l'établissement de l'entente de paiement ?
Si, au moment d'établir une entente de paiement avec le payeur, vous n'avez pas l'intention de facturer le payeur, par exemple, s'il s'agit d'un abonnement à un magazine dont le premier paiement est programmé dans un délai de 30 jours, vous devez soumettre une demande VERIFY (Vérifier) avec les détails de l'entente :
agreement.idagreement.type
La transaction Verify (Vérifier) devient la première transaction initiée par le titulaire de la carte de la série. Pour tout paiement ultérieur, utilisez l'agreement.id pour relier les paiements dans la série.
Si le payeur a été authentifié sur la passerelle à l'aide de l'authentification 3DS, vous pouvez fournir l'authentication.transactionId du résultat de l'authentification de la passerelle dans la demande VERIFY (Vérifier) afin de relier l'authentification à l'entente de paiement. Pour les transactions authentifiées en externe, voir les questions fréquentes dans la rubrique Authentification 3DS.
Que se passe-t-il si les détails de paiement d'une entente changent ?
Les détails du paiement par rapport à une entente peuvent changer si, par exemple :
- Le payeur a perdu sa carte et a reçu une nouvelle carte.
- Le payeur a changé de banque.
- La carte n'avait pas suffisamment de fonds et le payeur a fourni d'autres informations de paiement
Si les détails de la carte ont changé (sauf en cas de réémission d'une carte expirée et de jetons de réseau), vous devez effectuer un transaction initiée par le titulaire de la carte en utilisant l'ID d'entente d'origine pour mettre à jour les détails de paiement ou le jeton de la passerelle avant d'effectuer des transactions initiées par le commerçant avec le nouveau numéro de carte. En fonction de votre modèle économique, vous pouvez également décider de créer une nouvelle entente avec le payeur.
Si vous utilisez la segmentation en jetons de réseau, les systèmes de cartes peuvent automatiquement mettre à jour le numéro de carte stocké par rapport au jeton de réseau sur la passerelle.