- Directives d'intégration
- Fonctionnalités prises en charge (Sécurité)
- Informations d'identification stockées, transactions initiées par le titulaire de la carte et le commerçant
Informations d'identification stockées, transactions initiées par le titulaire de la carte et le commerçant
Cette page décrit comment soumettre à la passerelle des transactions initiées par le titulaire de la carte et par le commerçant afin de se conformer aux normes des systèmes de cartes pour le traitement de ces transactions.
Vous pouvez avoir une intégration où vous recueillez les détails de paiement de vos payeurs, les stockez, puis les utilisez pour traiter les paiements futurs des payeurs. Si tel est le cas, vous fournissez des informations à la passerelle lors de la transaction initiale indiquant que vous stockez les détails du paiement et que vous avez l'intention de les utiliser à l'avenir. Vous devez également fournir ces informations à la passerelle lorsque vous utilisez les détails de paiement stockés pour effectuer des paiements ultérieurs, initiés par le payeur (transaction initiée par le titulaire de la carte) ou par vous en tant que commerçant, suite à une entente de paiement avec le payeur (transaction initiée par le commerçant).
Il s'agit de se conformer aux normes du système de cartes pour le traitement des paiements initiés par le titulaire de la carte et par le commerçant à l'aide des détails de paiement stockés (également appelés exigences en matière d'informations d'identification stockées). La soumission d'informations à la passerelle pour identifier les détails de paiement stockés, les transactions initiées par le titulaire de la carte et les transactions initiées par le commerçant peut permettre :
- une meilleure visibilité des niveaux de risque de transaction pour les émetteurs,
- des taux d'approbation des autorisations plus élevés et de meilleures ventes réalisées, et
- une expérience améliorée du payeur.
À compter de la version v74 de l'API WS, la passerelle prend en charge les paiements suivants en utilisant les détails de paiement stockés :
- Paiements initiés par le titulaire de la carte
- Paiements récurrents initiés par le commerçant
- Paiements échelonnés initiés par le commerçant
- Paiements non planifiés initiés par le commerçant
- Paiements initiés par le commerçant suivant les pratiques du secteur et nouvelle soumission
Informations d'identification sur un fichier avec l'authentification 3-D Secure
Vous pouvez utiliser l'authentification 3-D Secure avec les paiements initiés par le titulaire de la carte. Pour plus d'informations, lisez les détails spécifiques suivants.
Effectuer des paiements initiés par le titulaire de la carte
Une transaction initiée par le titulaire de la carte est une transaction effectuée avec la participation active du payeur. Par exemple, transaction de commerce électronique, par courrier ou de commande téléphonique.
Pour indiquer que la transaction a été initiée par le payeur, vous devez définir transaction.source
sur INTERNET
/MOTO
/MAIL_ORDER
/TELEPHONE_ORDER
/VOICE_RESPONSE
/CALL_CENTER
. Tout au long de ce guide, nous utilisons un paiement par Internet (transaction.source
=INTERNET
) pour illustrer une transaction initiée par le titulaire de la carte ; vous pouvez cependant remplacer ce paiement par l'une des autres valeurs autorisées.
Une transaction initiée par le titulaire de la carte peut être un paiement unique où vous ne stockerez généralement pas les détails de paiement fournis par le payeur. Toutefois, vous pouvez conclure une entente avec le payeur afin de stocker 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) et effectuer des transactions suivantes initiées par le titulaire de la carte à l'aide des détails de paiement stockés.
Lors d'une interaction avec le payeur, si celui-ci accepte que vous stockiez ses détails de paiement pour une utilisation future, vous devez renseigner les champs suivants dans la transaction initiale :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET, et
sourceOfFunds.provided.card.storedOnFile
:TO_BE_STORED.
Pour les paiements ultérieurs initiés par le payeur (et non par vous) et lorsque les détails de paiement stockés du payeur sont utilisés, vous devez indiquer :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET, et
sourceOfFunds.provided.card.storedOnFile
:STORED.
Pour plus d'informations sur la manière d'indiquer à la passerelle si les détails de paiement sont stockés, non stockés ou si vous avez l'intention de les stocker, voir la rubrique Questions fréquentes.
Effectuer des paiements initiés par le commerçant
Une transaction initiée par le commerçant est une transaction qui est effectuée à l'aide des détails de paiement stockés, mais sans la participation active du payeur. Vous effectuez des transactions initiées par le commerçant si vous proposez :
Cas d'utilisation des données d'entente
- Paiement récurrent : des produits ou des services qui nécessitent que vous facturiez un payeur suivant un calendrier prédéfini. Par exemple, un paiement récurrent ultérieur pour un abonnement à un magazine, une adhésion à une salle de sport ou
- Paiements échelonnés : un paiement par un payeur pour un achat unique en plusieurs paiements échelonnés.
- Recharges : propose au payeur un service permettant de recharger son compte à la demande pour des services. Par exemple, les recharges de compte lorsque le montant disponible passe en dessous d'un seuil défini.
Dans les cas d'utilisation précédents, vous devrez conclure une entente avec le payeur concernant ces services. Le payeur doit accepter que vous stockiez ses détails de paiement à cet effet et doit vous permettre d'effectuer des paiements ultérieurs en utilisant les détails de paiement stockés sans sa participation active.
Cas d'utilisation de paiement suivant les pratiques du secteur
- Frais associés/différés : frais de compte supplémentaires après que le traitement du paiement des services initiaux. Par exemple, un supplément pour le mini-bar après que le titulaire de la carte a quitté l'hôtel.
- Pénalité de non-présentation : pénalité facturée au payeur conformément à la politique d'annulation du commerçant. Par exemple, l'annulation d'une réservation par le titulaire de la carte sans que le commerçant en ait été dûment informé.
- Livraison partielle : expédition pour laquelle le commerçant décide d'expédier les marchandises d'une même commande en plusieurs fois pour différentes raisons, telles que l'indisponibilité des marchandises, l'implication de plusieurs fournisseurs pour les marchandises, etc. Par exemple, le fournisseur ne dispose pas de toutes les marchandises ou de la logistique nécessaires.
Cas d'utilisation de nouvelle soumission de paiement
- Nouvelle soumission : une tentative précédente d'obtention d'une autorisation pour une transaction est refusée, mais la réponse de l'émetteur n'interdit pas au commerçant de réessayer plus tard, même si le payeur n'est plus présent. Par exemple, en raison de fonds insuffisants.
Détails de l'entente
Lorsque vous concluez une entente avec le payeur qui vous permet de soumettre ultérieurement des paiements initiés par le commerçant, vous devez indiquer dans la transaction initiale de la série, c'est-à-dire la transaction initiée par le titulaire de la carte, les informations suivantes sur l'entente :
agreement.id
: spécifie la valeur unique que vous générez pour identifier une entente de paiement avec le payeur. Vous devez également la soumettre sur les transactions initiées par le commerçant pour lier les paiements dans une série. Ceci est requis pour se conformer aux mandats des systèmes de cartes, où l'ID de l'entente correspond à un identifiant permettant d'associer la transaction initiée par le titulaire de la carte aux paiements suivants initiés par le commerçant.agreement.type
: indique si l'entente commerciale avec le payeur a été établie. Vous ne devez l'indiquer que lorsque vous établissez l'entente avec le payeur, c'est-à-dire dans la transaction initiée par le titulaire de la carte.
Référence de l'API Agreement Details (Détails de l'entente) [REST][NVP]
Détails de paiement suivant les pratiques du secteur et de nouvelle soumission
Lorsque vous concluez une entente avec le payeur qui permet à un commerçant de soumettre ultérieurement des paiements initiés par le commerçant suivant les pratiques du secteur, le commerçant doit fournir les détails suivants :
order.industryPracticePaymentReason
: ce champ est utilisé pour classer les paiements initiés par le commerçant qui sont soumis dans le contexte de certaines pratiques du secteur. Utilisez ce champ pour indiquer la raison de ce paiement suivant les pratiques du secteur. Par exemple, DELAYED_CHARGE, NO_SHOW_PENALTY ou PARTIAL_SHIPMENT.sourceofFunds.provided.card.storedOnFiles = STORED
: ce champ indique le consentement lorsque le commerçant doit avoir obtenu le consentement du payeur avant de soumettre des transactions suivant les pratiques du secteur.transaction.resubmission
: ce champ indique que cette transaction initiée par le commerçant est une nouvelle soumission pour une autorisation précédente qui a échoué en raison de fonds insuffisants. Les opérations à soumettre à nouveau doivent être uniquement Authorize (Autoriser) ou Pay (Payer).referenceOrderId
: ce champ indique la référence à une commande que vous avez précédemment soumise à la passerelle. Elle s'applique aux scénarios suivants lors de la soumission d'opérations de paiement :- un paiement suivant les pratiques du secteur : référence à la transaction initiale initiée par le titulaire de la carte.
- une transaction de nouvelle soumission : référence à la transaction initiée par le commerçant qui est à nouveau soumise.
Référence de l'API Industry Practice Payment Details and Resubmission Details (Détails de paiement suivant les pratiques du secteur et de nouvelle soumission) [REST][NVP]
Source de la transaction
Lorsque vous soumettez des paiements, vous devrez faire la distinction entre la première transaction de la série, c.-à-d. la transaction initiée par le titulaire de la carte et tout paiement suivant initié par le commerçant de la série. Pour ce faire, vous pouvez utiliser le champ transaction.source
, dans lequel, pour la transaction initiale, vous devez définir transaction.source
=INTERNET
ou toute autre valeur autorisée afin d'indiquer que la transaction a été initiée par le payeur. Pour les paiements ultérieurs de la série, vous devez définir transaction.source
=MERCHANT
pour indiquer que la transaction a été initiée par vous. « MERCHANT » doit être activé pour Your payment service provider comme source de transaction autorisée sur votre lien d'acquéreur marchand.
Référence de l'API Transaction Source (Source de transaction) [REST][NVP]
Lorsque vous soumettez la première transaction d'une série initiée par le titulaire de la carte ou les paiements ultérieurs initiés par le commerçant, vous devez 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 plus d'informations, voir la rubrique Questions fréquentes.
Paiements récurrents
Les paiements récurrents sont une entente par laquelle le payeur vous autorise à traiter les paiements de factures récurrentes ou à des intervalles convenus (par exemple, chaque semaine, chaque mois).
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.
Pour ce faire, vous devez renseigner les champs suivants dans la transaction initiale de la série :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET, et
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id
agreement.type
=RECURRING
Pour les paiements ultérieurs d'une série que vous initiez, vous devez indiquer :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, et
agreement.id
: même agreement.id que celui fourni dans la transaction initiale. Cela permet à la passerelle de relier des paiements de la série.
Authentification du payeur
Le tableau suivant répertorie différents scénarios ou cas d'utilisation pour traiter une authentification 3-D-Secure avec des paiements initiés par le titulaire de la carte. Pour plus d'informations sur l'authentification 3-D Secure, voir le Guide d'intégration 3D-Secure.
Pour les transactions autorisées externes, voir les consignes d'authentification.
Les champs suivants sont requis pour réussir une transaction récurrente lors de l'utilisation de la demande WS API AUTHENTICATE_PAYER à compter de la version 61 :
- agreement.id
- agreement.type=RECURRING
- agreement.numberOfPayments
- agreement.amountVariability
- agreement.expiryDate
- agreement.paymentFrequency
- agreement.minimumDaysBetweenPayments
Les champs suivants sont requis pour réussir une transaction récurrente lors de l'utilisation de la demande WS API AUTHENTICATE_PAYER pour les versions 57 à 60 :
- agreement.id
- agreement.type=RECURRING
- agreement.expiryDate
- agreement.recurring.daysBetweenPayments
Cas d'utilisation | Étapes d’intégration |
---|---|
Établir une entente récurrente avec le payeur qui comprend une charge initiale et lancer une nouvelle série de paiements récurrents. |
|
Établir une série de paiements récurrents lorsqu'aucun paiement n'est dû initialement Si vous voulez établir une série de paiements récurrents avec le payeur où il n'y a pas de paiement dû au moment où le payeur s'inscrit au service. Exemple : Services d'abonnement mensuel sans paiement requis lors de l'inscription du client. |
En vous reportant aux consignes d'authentification, utilisez ces paramètres supplémentaires spécifiés dans les étapes ci-dessous pour intégrer l'authentification 3DS pour les paiements récurrents. Les étapes 1 et 2 doivent être complétées pendant que le titulaire de la carte est en session. L'étape 3 doit être utilisée lorsque vous êtes prêt à traiter le paiement.
Pendant que le titulaire de la carte est en session, suivez les étapes 1 et 2. Lorsque vous êtes prêt à traiter le paiement, suivez l'étape 3. Étape 1 : Initier l'authentification
Étape 2 : Authentifier le payeur
Étape 3 : Exécuter l'opération Verify (Vérifier), puis choisir l'une des options suivantes :
ou
|
Ajouter une carte sans établir d'entente de paiement Si vous souhaitez offrir aux payeurs la possibilité d'ajouter les détails de leur carte lors de la création de leur profil ou de leur compte sans qu'une entente de paiement soit en place au moment de l'inscription. La carte ajoutée peut être utilisée à l'avenir. |
En vous reportant aux consignes d'authentification, utilisez ces paramètres supplémentaires spécifiés dans les étapes ci-dessous pour intégrer l'authentification 3DS. Étape 1 : Initier l'authentification
Étape 2 : Authentifier le payeur
|
Effectuer des paiements échelonnés initiés par le commerçant
Les paiements échelonnés sont une entente par laquelle le payeur autorise le paiement d'un seul achat à être fractionné en plusieurs paiements traités à des intervalles convenus. Par exemple, le paiement d'un achat en six mensualités.
Vous pouvez soumettre des paiements échelonné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 échelonnés suivants sans sa participation active.
Pour ce faire, vous devez renseigner les champs suivants dans la transaction initiale de la série :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, et
agreement.type
=INSTALLMENT
Pour les paiements échelonnés ultérieurs d'une série que vous initiez, vous devez fournir :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
agreement.id
: même agreement.id que celui fourni dans la transaction initiale. Cela permet à la passerelle de relier des paiements de la série.
Effectuer des paiements non planifiés initiés par le commerçant
Un paiement non planifié est une entente par laquelle le payeur autorise le commerçant à déduire automatiquement les fonds pour un paiement pour un achat convenu lorsque cela est nécessaire (non planifié). Par exemple, des recharges automatiques lorsque la valeur du compte tombe en dessous d'un seuil.
Vous pouvez soumettre des paiements non planifié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 planifiés suivants sans sa participation active.
Pour ce faire, vous devez renseigner les champs suivants dans la transaction initiale de la série :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, et
agreement.type
=UNSCHEDULED
Pour les paiements non planifiés ultérieurs d'une série que vous initiez, vous devez fournir :
sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, et
agreement.id
: même agreement.id que celui fourni dans la transaction initiale. Cela permet à la passerelle de relier des paiements de la série.
Paiements initiés par le commerçant suivant les pratiques du secteur
Vous pouvez soumettre des paiements initiés par le commerçant dans le contexte de certaines pratiques du secteur pour traitement à la passerelle si vous avez conclu une entente de paiement avec le payeur par laquelle le payeur accepte que le commerçant stocke ses détails de paiement pour une utilisation future, et vous autorise à initier des paiements commerçant ultérieurs sans la participation active du payeur.
Pour ce faire, renseignez les champs suivants dans la transaction initiale de la série :
order.id
= "OD12345"transaction.id
= "TRAN 1"sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET, MOTO, MAIL_ORDER, TELEPHONE_ORDER, CALL_CENTRE, or VOICE_RESPONSE
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
Pour les paiements commerçant ultérieurs que vous lancez, renseignez les champs suivants :
order.id
="OD45678"
transaction.id
= "TRAN 2"sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
order.industryPracticePaymentReason : {DELAYED_CHARGE, NO_SHOW_PENALTY, PARTIAL_SHIPMENT}
referenceOrderId
="OD12345"
transaction.acquirer.traceid
="MCC123456889"
transaction.relatedTransactions.firstTransactionInTheSeries.source
=MOTO, MAIL_ORDER, TELEPHONE_ORDER, CALL_CENTRE, or VOICE_RESPONSE
- Le champ referenceOrderId fournit une référence à order.id à partir de la transaction initiale initiée par le client dans la série.
- Le champ transaction.acquirer.traceid est identique au champ autorisationResponse.transactionIdentifier de la transaction initiale initiée par le client dans la série. Ce champ doit être indiqué lorsque la transaction initiale d'une série s'est déroulée avec succès en dehors de la passerelle MPGS.
- Pour le motif de paiement suivant les pratiques du secteur « DELAYED_CHARGE », vous devez fournir le champ transaction.relatedTransactions.firstTransactionInTheSeries.source de la transaction initiale initiée par le client, lorsque la transaction initiale initiée par le client dans la série s'est déroulée avec succès en dehors de Mastercard Gateway. Les valeurs d'énumération autorisées sont MOTO, MAIL_ORDER, TELEPHONE_ORDER, CALL_CENTRE ou VOICE_RESPONSE.
Nouvelles soumissions de paiements initiées par le commerçant
Vous pouvez soumettre à nouveau un paiement initié par le commerçant lorsque l'autorisation précédente a échoué en raison de fonds insuffisants. Les opérations à soumettre à nouveau doivent être uniquement Authorize (Autoriser) ou Pay (Payer).
Pour ce faire, renseignez les champs suivants dans la transaction initiale de la série :
order.id
= "OD12345"transaction.id
= "TRAN 1"sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
Pour les paiements commerçant ultérieurs que vous lancez, renseignez les champs suivants :
Pour référence, plus loin dans cette section, la première transaction MIT est appelée MIT1 et la transaction MIT soumise à nouveau est appelée MIT2.
Pour MIT1 1, renseignez les champs suivants :
order.id
="OD5678"
transaction.id
= "TRAN 2"sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
order.industryPracticePaymentReason : {DELAYED_CHARGE, NO_SHOW_PENALTY, PARTIAL_SHIPMENT}
referenceOrderId
="OD12345"
transaction.acquirer.traceid
="MCC0987335353"
- Le champ referenceOrderId fournit une référence à order.id à partir de la transaction initiale initiée par le client dans la série.
- Le champ transaction.acquirer.traceid est identique au champ autorisationResponse.transactionIdentifier de la transaction initiale initiée par le client dans la série. Ce champ doit être indiqué lorsque la transaction initiale d'une série s'est déroulée avec succès en dehors de la passerelle MPGS.
MIT 1 échoue en raison de fonds insuffisants. Par conséquent, le commerçant soumet à nouveau la transaction MIT envoyée, qui est maintenant MIT2.
Pour MIT 2, renseignez les champs suivants :
order.id
="OD5678"
transaction.id
= "TRAN 3"sourceOfFunds.type
=CARD
ouSCHEME_TOKEN
- Les champs
sourceOfFunds.provided.card.*
ousourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
order.industryPracticePaymentReason : {DELAYED_CHARGE, NO_SHOW_PENALTY, PARTIAL_SHIPMENT}
transaction.resubmission
="true"
referenceOrderId
="OD12345"
transaction.acquirer.traceid
="MCC0987335353"
- le champ referenceOrderId indique le order.id de la dernière transaction initiée par le commerçant qui a échoué en raison de fonds insuffisants.
- Le champ transaction.acquirer.traceid est identique au champ autorisationResponse.transactionIdentifier de la transaction initiale initiée par le client dans la série. Ce champ doit être indiqué lorsque la transaction initiale d'une série s'est déroulée avec succès en dehors de la passerelle MPGS.
- Le champ transaction.acquirer.traceid est identique au champ autorisationResponse.transactionIdentifier de la dernière transaction initiée par le commerçant dans la série.
Hosted Checkout pour une transaction initiée par le titulaire de la carte
Hosted Checkout pour une transaction initiée par le titulaire de la carte vous permet de recueillir le consentement du payeur afin de stocker ses informations de paiement pour les transactions ultérieures initiées par le payeur.
interaction.operation=AUTHORIZE
est pris en charge pour cette fonctionnalité. Une prise en charge supplémentaire pour interaction.operation=PURCHASE sera bientôt disponible.Conditions préalables
- Assurez-vous que la MSO a configuré votre profil de commerçant pour la segmentation en jetons de la passerelle.
- Pour pouvoir utiliser la fonctionnalité Informations d'identification stockées, l'API WS v74 ou une version ultérieure doit être utilisée.
Demander Hosted Checkout pour une transaction initiée par le titulaire de la carte
Suivez les étapes ci-dessous pour demander une transaction initiée par le titulaire de la carte Hosted Checkout :
- Demandez une API WS INITIATE_CHECKOUT avec
interaction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTS
.Hosted Checkout propose au payeur les options de paiement disponibles.
La liste des options de paiement du payeur n'inclut pas Click to Pay.
La liste des options de paiement du payeur n'inclut pas Click to Pay. - Si le payeur sélectionne « Débit ou crédit », la case à cocher Options de paiement suivante s'affiche.
Si le payeur paie avec une méthode autre qu'une carte de crédit, comme ACH ou PayPal, la procédure de paiement standard s'applique. Hosted Checkout n'affiche ni ne renvoie aux conditions générales, aux politiques de confidentialité ou aux deux. 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 « Enregistrez cette carte pour vos futurs achats ».
- Si le payeur procède au paiement sans donner son consentement, le traitement de paiement fonctionne comme d'habitude. Dans ce cas, la passerelle ne segmentera pas en jetons la carte du payeur.
- 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 AUTH (Payer) (si
interaction.operation=AUTHORIZE
) avecsourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
ettransaction.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.
- Une fois que la passerelle a renvoyé le payeur sur le site Web de votre magasin, soumettez une demande d'API WS
RETRIEVE_ORDER
.- Pour une transaction réussie :
- Si le payeur a donné son consentement, la réponse contiendra les informations selon lesquelles le consentement a été fourni dans le champ
transaction.payerConsentForStoringCardDetails=PAYER_INITIATED_PAYMENTS
. - Si le payeur a donné son consentement et que la transaction a réussi, la réponse contiendra le jeton de passerelle dans le champ
sourceOfFunds.token
.
- Si le payeur a donné son consentement, la réponse contiendra les informations selon lesquelles le consentement a été fourni dans le champ
- Pour une transaction réussie :
- Pour les paiements ultérieurs initiés par le titulaire de la carte,
- Demander l'API WS
INITIATE_CHECKOUT
avecinteraction.tokens
contenant le jeton de passerelle interaction.saveCardForCredentialOnFile=PAYER_INITIATED_PAYMENTS
- Cela permet au payeur d'entrer de nouveaux détails de carte et de les stocker.Hosted Checkout affiche les options de paiement disponibles pour le payeur.
- Demander l'API WS
- 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.
Hosted Checkout pour une transaction initiée par le commerçant
Hosted Checkout pour une transaction initiée par le commerçant vous permet de recueillir le consentement du payeur afin de stocker ses informations de paiement pour les transactions ultérieures initiées par le commerçant.
interaction.operation=AUTHORIZE
est pris en charge pour cette fonctionnalité. Une prise en charge supplémentaire pour interaction.operation=PURCHASE sera bientôt disponible.Conditions préalables
- Assurez-vous que la MSO a configuré votre profil de commerçant pour la segmentation en jetons de la passerelle.
- Les commerçants peuvent créer des comptes payeurs et enregistrer les informations de jeton sur ces comptes.
- Pour pouvoir utiliser la fonctionnalité Informations d'identification stockées, l'API WS v74 ou une version ultérieure doit être utilisée.
Demander Hosted Checkout pour une transaction initiée par le commerçant
Suivez les étapes ci-dessous pour demander Hosted Checkout pour une transaction initiée par le commerçant :
- Demander une API WS
INITIATE_CHECKOUT
avecagreement.type
etagreement.id
Hosted Checkout propose au payeur les options de paiement par débit ou crédit.
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. - 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 soumettra la demande de transaction avec les valeurs suivantes :
sourceOfFunds.provided.card.storedOnFile=TO_BE_STORED
transaction.payerConsentForStoringCardDetails=MERCHANT_INITIATED_PAYMENTS
Vous devez vous assurer que le payeur respecte les exigences du système et les exigences réglementaires (par exemple, GDPR). Vous devez proposer au payeur la possibilité de retirer son consentement et de supprimer le jeton de passerelle. - Une fois que la passerelle a renvoyé le payeur sur le site Web de votre magasin, soumettez une demande API WS
RETRIEVE_ORDER
pour une transaction réussie :- Si le payeur a donné son consentement, la réponse contiendra les informations
transaction.payerConsentForStoringCardDetails=MERCHANT_INITIATED_PAYMENTS.
Il est de la responsabilité du commerçant de s'assurer que les éléments qui n'ont pas besoin d'ententes ne sont pas inclus dans la commande ou la transaction. - 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 contiendra les informations
Questions fréquentes
Comment indiquer à la passerelle si les détails du paiement sont stockés, non stockés ou si j'ai l'intention de les stocker ?
Pour vous conformer aux normes du système de cartes pour le traitement des transactions initiées par le titulaire de la carte et les transactions initiées par le commerçant, vous devez indiquer à la passerelle si les détails du paiement sont stockés, non stockés, ou si vous avez l'intention de les stocker en utilisant le champ sourceOfFunds.provided.card.storedOnFile
.
Pour la transaction initiale, c'est-à-dire la transaction initiée par le titulaire de la carte :
- S'il s'agit d'un paiement unique, c'est-à-dire que vous n'avez pas l'intention de stocker les détails de paiement, vous pouvez omettre le champ
sourceOfFunds.provided.card.storedOnFile
. - S'il s'agit d'un paiement pour lequel vous avez l'intention de stocker les détails de paiement pour une utilisation future, 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 :
- quel que soit l'endroit où vous stockez les détails de paiement — votre propre application (vous devez être conforme à la norme PCI), la segmentation en jetons ou les jetons de système de cartes,
- que vous stockiez les détails du paiement avant ou après avoir soumis la transaction à la passerelle.
Pour les paiements ultérieurs, une transaction initiée par le titulaire de la carte où les détails de paiement stockés du payeur sont utilisés ou des transactions initiées par le commerçant utilisant les détails de paiement stockés, définissez sourceOfFunds.provided.card.storedOnFile
=STORED
.
Avec la segmentation en jetons de la passerelle, celle-ci définit les valeurs par défaut en votre nom.
- Lorsque la segmentation en jeton n'est pas activée pour votre profil, la passerelle définit
sourceOfFunds.provided.card.storedOnFile
=NOT_STORED
- Lorsque vous segmentez les détails de la carte en jetons, la passerelle donne au champ
sourceOfFunds.provided.card.storedOnFile
la valeur que vous avez indiquée dans la demande de transaction. Vous pouvez indiquerTO_BE_STORED
ouNOT_STORED
dans la transaction initiée par le client. - Lorsque vous effectuez des transactions ultérieures à l'aide du jeton de la passerelle, celle-ci définit
sourceOfFunds.provided.card.storedOnFile
=STORED
Référence de l'API Stored on File (Détails stockés) [REST][NVP]
Et si je n'ai pas d'ID entente ?
Si vous n'avez pas d'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 pour 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.
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.id
agreement.type
La transaction Verify (Vérifier) devient la première transaction de la série initiée par le titulaire de la carte. Pour tout paiement ultérieur, utilisez l'agreement.id
pour relier les paiements dans la série.
Si le payeur a été authentifié à l'aide de l'authentification 3D-Secure dans MPGS, vous pouvez indiquer le authentication.transactionId
utilisé dans la transaction d'origine.
Pour les transactions authentifiées en externe, reportez-vous à la page Implémentation d'une intégration 3DS à l'aide de l'API d'authentification et accédez à la section Options > Soumettre une demande Pre-Authenticated Payment (Paiement préauthentifié).
Et si le PAN pour une entente change ?
Les détails de paiement par rapport à une entente peuvent changer, par exemple, si :
- le payeur a perdu sa carte et s'est vu remettre une nouvelle carte,
- le payeur a changé de banque, et
- la carte avait des fonds insuffisants et le payeur a fourni d'autres détails de paiement
Si les détails de la carte ont changé (sauf en cas de nouvelle émission d'une carte et de jetons de système de cartes ayant expiré), vous devez effectuer une transaction initiée par le titulaire de la carte en utilisant le même identifiant d'entente pour mettre à jour les détails du paiement / le jeton de passerelle avant d'effectuer une transaction initiée par le commerçant avec le nouveau numéro de carte. Suivant votre modèle d'entreprise, vous pouvez choisir de créer une nouvelle entente.
Si vous utilisez un jeton de système, le numéro de carte stocké sur le jeton de système peut être automatiquement mis à jour par le système.