Après le paiement

Après avoir effectué le paiement, vous pouvez le gérer dans l'espace personnel du portail vendeur ou via API. Lisez les sections ci-dessous pour en savoir plus.

Annulation et remboursement du paiement

Si vous souhaitez annuler un paiement, vous pouvez effectuer l'une des deux opérations, selon le statut de la commande : annulation ou remboursement. Ces opérations sont décrites ci-dessous.

Annulation

L'annulation signifie que la transaction est annulée et tous les fonds réservés sur le compte du client sont débloqués. Cette opération peut s'appliquer aux transactions en deux étapes, lorsque les fonds sont réservés mais pas encore reçus (statut Confirmé). Après l'annulation, la transaction obtient le statut Annulé.

Les méthodes d'annulation suivantes sont disponibles :

• Annulation du paiement sur le portail vendeur. Effectuée en cliquant sur le bouton Remboursement sur la page des détails de l'opération. Ce bouton fonctionne aussi bien pour l'annulation du paiement que pour le remboursement des fonds – selon le statut de la transaction. Si c'est possible, l'annulation du paiement se produit, et sinon, le remboursement des fonds est effectué. Lisez plus en détail ici.

• Annulation du paiement via l'API en envoyant une requête reverse.do.

• Annulation automatique de tous les paiements en deux étapes après l'expiration d'un certain temps. Si vous avez besoin de cette fonctionnalité, contactez le service support de la banque.

L'annulation ne peut être effectuée qu'avant la fin du jour bancaire actuel.

Remboursement des fonds

Le remboursement signifie le retour au client des fonds déjà débités. Cette opération peut s'appliquer aux transactions en une et deux étapes, lorsque les fonds ont déjà été débités (statut Terminé). Le système permet de rembourser les fonds plus d'une fois, mais au total pas plus que le montant initial d'achèvement.

Les méthodes suivantes d'organisation du remboursement sont possibles :

• Remboursement des fonds dans l'espace personnel en cliquant sur le bouton Remboursement dans les détails de la transaction. Ce bouton fonctionne aussi bien pour l'annulation du paiement que pour le remboursement des fonds – selon le statut de la transaction. Si c'est possible, l'annulation du paiement se produit, et sinon, le remboursement des fonds est effectué. Lisez plus en détail ici.
• Remboursement des fonds via l'API en envoyant une requête refund.do.

Tant l'annulation que le remboursement peuvent être déclenchés par des déclencheurs de notifications callback. Lisez plus en détail ici.

Obtention du statut de la commande

Vous pouvez vérifier le statut de la commande à tout moment. Par exemple, vous pouvez le vérifier après le paiement pour vous assurer que la commande est réellement payée. Le statut de la commande est disponible sur le portail du vendeur et peut également être obtenu via l'API.

Détermination du statut de la commande sur le portail du vendeur

Le statut de la commande peut être consulté sur la page Détails de la transaction de la transaction correspondante.

Le statut Deposited signifie un paiement réussi.

Détermination du statut de la commande via l'API

Pour obtenir le statut de la commande, la boutique en ligne envoie à la passerelle de paiement une requête getOrderStatusExtended.do. La requête contient soit orderId (numéro unique de la commande dans la passerelle de paiement), soit orderNumber (numéro unique de la commande dans le système de la boutique en ligne). Si les deux paramètres sont transmis dans la requête, la priorité de orderId est plus élevée.

La passerelle de paiement retourne le statut de la commande dans le paramètre orderStatus. Le statut 2 signifie un paiement réussi.

Fonctionnalités supplémentaires

Paiements à deux étapes

Types de paiements

En fonction des spécificités de l'activité, l'entreprise peut utiliser deux types de paiements :

• À une étape - opérations de paiement de biens/services, effectuées via Internet en utilisant des cartes bancaires, ne nécessitant pas de confirmation supplémentaire, c'est-à-dire que la réservation et le débit des fonds se produisent en une seule étape. Ce type de paiement est préférable si le bien ou le service est fourni immédiatement après le paiement.
• À deux étapes - opérations de paiement de biens/services, effectuées via Internet en utilisant des cartes bancaires, nécessitant une confirmation supplémentaire, c'est-à-dire que le paiement est effectué en deux étapes. À la première étape, il y a vérification de la disponibilité et réservation (mise en réserve) des fonds du payeur (pré-autorisation) ; puis à la deuxième étape, l'entreprise soit confirme le débit des fonds, soit annule la réservation des fonds.

Le montant de finalisation peut être inférieur au montant de réservation. Il y a aussi la possibilité de faire des finalisations pour un montant dépassant la valeur de réservation (dans les limites des limites configurables). Si vous souhaitez utiliser cette fonctionnalité, contactez notre service de support.

Les paiements à deux étapes doivent être utilisés si un certain temps s'écoule entre la décision de paiement de l'acheteur et la livraison du bien ou service choisi.

Pour qu'un paiement soit à deux étapes, la commande doit être enregistrée à l'aide de la requête registerPreAuth.do, et non register.do.

Le paiement à deux étapes est possible avec toute méthode d'intégration :

• Paiement par lien
  
• Intégration via redirection
• Paiements directs
• CMS
• SDK

Pour les variantes d'intégration directe, intégration via redirection, CMS, SDK, l'enregistrement et la finalisation de commande via API sont possibles.

Finalisations

La finalisation se produit à la deuxième étape du paiement à deux étapes, lorsque les fonds préalablement réservés sont débités du compte du porteur de carte. Dès que le débit a lieu, la commande devient finalisée et passe au statut DEPOSITED. Le montant de finalisation peut être supérieur ou inférieur au montant de pré-autorisation. La finalisation partielle progressive est également disponible. Si vous ne transmettez pas de montant, la totalité du montant sera débitée.

Il y a trois façons de faire une finalisation :

• Finalisation du paiement sur le portail marchand
• Finalisation du paiement via API
• Finalisation automatique de tous les paiements à deux étapes après un certain temps

Il y a aussi la possibilité de faire une finalisation partielle. Dans ce cas, la commande sera finalisée pour un montant moindre (que le montant d'autorisation).

Finalisation et annulation des commandes automatiquement

Si notre service d'assistance a activé cette fonction pour vous, vous pouvez configurer votre intégration de sorte que toutes les commandes à deux étapes pré-autorisées (au statut Confirmé) soient complétées ou annulées automatiquement après une certaine période de temps. Dans ce cas, vous n'avez pas besoin de traiter chaque commande manuellement dans l'espace personnel. Il n'est également pas nécessaire d'appeler les méthodes API deposit.do et/ou reverse.do.

Pour activer l'auto-completion de commande dans l'espace personnel :

1. Connectez-vous à l'espace personnel.
2. Dans le panneau de contrôle à gauche, allez dans la section Paramètres. .
3. Allez sur l'onglet Généraux.
4. Dans la section Auto-completion, cochez Auto-completion activée.
5. Dans le champ Délai de completion (en heures) saisissez le nombre d'heures après l'enregistrement, après lequel la commande à deux étapes doit être complétée automatiquement.

Vous pouvez également activer l'auto-annulation des commandes. Dans ce cas, toutes les commandes à deux étapes pré-autorisées (au statut Confirmé) seront automatiquement annulées après la période de temps définie. L'annulation signifie que la transaction est annulée et tous les fonds réservés sur le compte du client sont débloqués.

Vous pouvez définir la date et l'heure d'auto-completion et d'auto-annulation par API à l'aide des paramètres autocompletionDate et autoReverseDate dans les requêtes API registerPreAuth.do et instantPayment.do. Fuseau horaire utilisé : UTC+0.

Ci-dessous est décrite la logique de fonctionnement de l'auto-completion et de l'auto-annulation.

Lorsqu'une commande est enregistrée et que l'auto-completion est définie pour elle :

• Si le statut de la commande reste Créé au moment où l'heure d'auto-completion arrive, rien ne se passera avec la commande : elle finira par expirer et sera fermée. Si la commande est complétée après la période définie, l'auto-completion ne se déclenchera pas.
• Si la commande est pré-autorisée et n'est pas complétée avant l'expiration de la période de completion prédéterminée, la commande sera entièrement exécutée, c'est-à-dire que le montant pré-autorisé sera automatiquement crédité en totalité.
• Si la commande est pré-autorisée et complétée avant l'expiration de la période de completion définie, le statut de la commande changera selon son cycle de vie habituel.
• Si avant l'expiration de la période de completion définie un remboursement/annulation est appliqué à la commande, l'auto-completion ne se déclenchera pas.

Lorsqu'une commande est enregistrée et que l'auto-annulation est définie pour elle :

• Si le statut de la commande reste Créée au moment de l'arrivée du temps d'annulation automatique, rien ne se passera avec la commande : finalement, sa durée de validité expirera et elle sera fermée. Si la commande est terminée après l'expiration de la période définie, l'annulation automatique ne se déclenchera pas.
• Si la commande est préalablement autorisée et non terminée avant l'expiration de la période d'annulation prédéfinie, la commande sera entièrement annulée, c'est-à-dire que le montant préalablement autorisé sera automatiquement annulé en totalité.
• Si la commande est préalablement autorisée et terminée avant l'expiration de la période d'annulation définie, le statut de la commande changera conformément à son cycle de vie habituel.
• Si avant l'expiration de la période d'annulation définie un remboursement/annulation est appliqué à la commande, l'annulation automatique ne se déclenchera pas.

Opérations par liaisons

La transaction par liaison est utilisée quand le porteur de carte autorise le vendeur à stocker les données de paiement pour les paiements ultérieurs. Par exemple, le payeur peut choisir de sauvegarder sa carte lors de la finalisation de commande. Dans ce cas est créée une liaison (CoF, credential on file), un jeton protégé unique, généré par la passerelle de paiement, qui lie le numéro de carte du payeur (PAN) à son identifiant dans le système du magasin (par exemple, au login du payeur).

Plus de détails sur les types de liaisons, supportés par la passerelle de paiement, lisez ici.

Création de liaison

Vous pouvez créer une liaison via API ou via l'espace personnel (indépendamment du type d'intégration). Plus de détails voir ci-dessous.

Création de liaison via API

Pour sauvegarder la carte (créer une liaison) dans la passerelle de paiement via API, vous devez transmettre le paramètre clientId dans la demande d'enregistrement de commande ou d'initiation de paiement. clientId - c'est l'identifiant de votre client (propriétaire de la carte), à ce numéro seront liées toutes les cartes du client. À des fins de test vous pouvez utiliser n'importe quel numéro en tant que clientId. Ce paramètre peut être transmis dans les demandes suivantes :

• register.do
• registerPreauth.do
• instantPayment.do
• motoPayment.do
• /applepay/payment.do
• /applepay/paymentDirect.do
• /google/payment.do
• /google/paymentDirect.do
• /samsung/payment.do
• /samsung/paymentDirect.do

La liaison sera créée seulement après le paiement réussi. Après le paiement vous pourrez obtenir l'identifiant de liaison via la demande getOrderStatusExtended.do dans le paramètre bindingId.

Création de liaison via l'espace personnel

Pour la création de liaison lors du paiement via l'interface utilisateur allez dans l'espace personnel, établissez une facture sur l'adresse électronique avec indication du paramètre Identifiant du client. Si vous indiquez ce paramètre, le client verra la case à cocher Sauvegarder ma carte sur la page de paiement. Si le client coche cette case, après l'achèvement du paiement sera créée une liaison, et le client n'aura pas besoin de saisir les données de carte la prochaine fois. Plus de détails lisez ici.

Création de liaison sans paiement

En présence des droits utilisateur correspondants, vous pouvez créer une liaison via API sans effectuer de paiement.

Pour cela, transmettez la valeur VERIFY dans le bloc features de toute demande de paiement avec le paramètre clientId. Dans ce cas, aucun montant ne sera prélevé au porteur de la carte. La réponse contiendra l'identifiant de la liaison créée dans le paramètre bindingId. Cet identifiant de liaison peut être utilisé dans les demandes ultérieures au lieu des détails de carte sauvegardés.

Apprenez-en plus sur la fonction VERIFY ici.

Création forcée de liaison

Si vous transmettez la valeur FORCE_CREATE_BINDING dans le bloc features de la demande de paiement, la liaison sera créée de force, même si le client a décidé de ne pas sauvegarder les données de carte sur la page de paiement.

La valeur FORCE_CREATE_BINDING ne peut pas être transmise dans une demande avec un bindingId existant ou bien lorsque bindingNotNeeded = true (provoquera une erreur de vérification). Pour transmettre cette valeur, il est également nécessaire de transmettre le paramètre clientId.

Si dans le bloc features sont transmises les deux valeurs FORCE_CREATE_BINDING et VERIFY, alors la commande sera créée SEULEMENT pour créer la liaison (sans paiement).

Effectuer le paiement par liaison

Travail avec les liaisons via API

Après la création de la liaison, vous pouvez travailler avec elle via API (si vous avez l'autorisation au niveau du vendeur). Les méthodes suivantes sont disponibles :

• paymentOrderBinding.do – effectuer le paiement par liaison
• getBindings.do – obtenir la liste des liaisons du client
• getBindingsByCardOrId.do – obtenir la liste de toutes les liaisons de la carte bancaire
• unBindCard.do – désactiver la liaison existante
• bindCard.do – réactiver une liaison précédemment désactivée
• extendBinding.do — prolonger la durée de validité de la liaison.

Utilisation des liaisons dans les paiements récurrents

Vous pouvez utiliser les liaisons pour les paiements récurrents. Dans ce cas, le paramètre bindingId est utilisé dans la demande habituelle d'enregistrement de commande. Lisez plus en détail ici.

Utilisation des liaisons lors du paiement avec des portefeuilles

Vous pouvez également créer des liaisons lors des paiements via les portefeuilles Apple Pay, Google Pay et Samsung Pay. Pour cela, il est nécessaire de transmettre le paramètre clientId dans la demande de paiement ou dans la demande de finalisation de commande (voir la description des demandes API pour les portefeuilles).

Dans ce cas, la liaison connectera le numéro de la carte tokenisée du payeur (DPAN) avec son ID dans le système du magasin (par exemple, avec l'identifiant du payeur). Une telle liaison ne peut pas être utilisée pour afficher le numéro de carte sur la page de paiement (car le numéro de carte est tokenisé). Cependant, cette liaison peut être utilisée dans les paiements récurrents.

Industry Practice des opérations

Introduction

Aux transactions MIT (Merchant-initiated Transaction) Industry Practice, effectuées après la transaction initiatrice CIT (Cardholder-initiated Transaction), appartiennent les transactions du type suivant :

• Incremental Authorization Transaction (augmentation du montant)
• Resubmission Transaction (renvoi répété de la transaction)
• Delayed Charges Transaction (transaction de paiement différé)
• Reauthorization Transaction (transaction de réautorisation de paiement)
• No Show Transaction (transaction de paiement de non-présentation)

Cette fonctionnalité est disponible en présence de la permission correspondante. Pour son activation, veuillez vous adresser au service de support technique.

Conditions de possibilité d'exécution des paiements Industry Practice :

1. Permission pour effectuer les paiements Industry Practice activée.
2. Le paiement initial a été effectué en utilisant l'authentification 3DS 2.0/2.1/2.2 avec le type frictionless/challenge pour les transactions Resubmission, Reauthorization et challenge pour Incremental, Delayed charges, No show.
3. Le paiement initial représente une commande en une étape dans des statuts erronés pour les transactions Resubmission, Reauthorization, ainsi que dans le statut Terminé pour les opérations Incremental, Delayed charges, No show.
4. Commande initiale avec paiement *.Pays tokenisé.
5. Transaction CIT initiale avec tii = CI, RI, II, F (plus de détails sur les types de transactions CIT décrites ici).
6. Chez le Merchant, la fonctionnalité de liaisons est désactivée ou utilisent des liaisons V2 (sont utilisées des liaisons telles que normales, récurrentes et échelonnement).

L'exécution des paiements Industry Practice est impossible pour les types suivants d'opérations initiales avec :

• Type 3RI.

• Type MIT.

• Paiement SSL.

• Type MOTO.

• Schéma de paiement en deux étapes. Y compris les achèvements simples ou multiples.

• Avec tii = R, I, U.

• Avec utilisation de l'authentification 3DS 1.0.

• Avec features = VERIFY, où après vérification des données de carte l'autorisation financière est absente ou elle a été annulée.

• Dans le cas où chez le Merchant sont utilisées des liaisons V1.

Requête API

Pour le paiement de commande avec les signes de transaction Industry Practice est utilisée la requête /industryPractice/paymentOrder.do.

Particularités d'exécution du paiement

Pour chacun des types de paiement Industry Practice sont propres ses conditions pour une exécution réussie.

Industry Practice Incremental

• L'exécution n'est possible que le même jour ouvrable par rapport à l'opération initiale (dont le montant est sujet à augmentation).
• L'exécution est possible par les Commerçants avec les MCC suivants :
  
  • 3351-3500, 7512 Car Rental;
  • 3501-3999, 7011 Lodging;
  • 4111 Local and Suburban Commuter Passenger Transportation, including Ferries;
  • 4112 Passenger Railways;
  • 4121 Taxicabs and Limousines (Card-Absent Environment only);
  • 4131 Bus Lines;
  • 4411 Steamship and Cruise Lines;
  • 5411 Grocery Stores;
  • 5552 Electric Vehicle Charging;
  • 5812 Eating Places and Restaurants;
  • 5813 Drinking Places (Alcoholic Beverages), Bars, Taverns, Cocktail Lounges, Nightclubs and Discotheques;
  • 7033 Trailer Parks and Campgrounds;
  • 7394 Equipment, Tool, Furniture and Appliance Rental;
  • 7513 Truck Rentals;
  • 7519 Motor Home and Recreational Vehicle Rentals;
  • 7523 Parking Lots, Parking Meters and Garages;
  • 7996 Amusement Parks, Carnivals, Circuses, Fortune Tellers;
  • 7999 Recreation Services.
• Le nombre d'opérations Incremental exécutées n'est pas limité.

Industry Practice Resubmission

• En cas d'utilisation de *.Pays ou d'un autre paiement tokenisé dans l'opération initiale, l'exécution de l'opération Resubmission est possible dans les 14 jours suivant l'autorisation initiale.
• En cas d'utilisation d'un paiement habituel de l'opération initiale, l'exécution de l'opération Resubmission est possible dans les 30 jours suivant l'autorisation initiale.
• Le montant de l'opération Resubmission doit correspondre entièrement au montant de la commande initiale.
• Une seule opération Resubmission peut être exécutée avec succès.

Industry Practice Delayed Charges

• L'exécution de l'opération Delayed Charges est possible dans les 90 jours suivant l'autorisation initiale.
• Le nombre d'opérations Delayed Charges exécutées n'est pas limité.

Industry Practice Reauthorization

• En cas d'utilisation de *.Pays ou d'un autre paiement tokenisé dans l'opération initiale, l'exécution de l'opération Reauthorization est possible dans les 90 jours suivant la préautorisation initiale, à l'exception des Commerçants (voir la liste MCC ci-dessous), qui peuvent envoyer une nouvelle autorisation dans les 120 jours à compter de la date de la préautorisation initiale :
  
  • 3351–3500 Car Rental Agencies;
  • 3501–3999 Lodging Hotels, Motels, Resorts;
  • 4411 Steamship and Cruise Lines;
  • 4457 Boat Rentals and Leasing;
  • 7011 Hotels, Motels, Resorts, Central Reservations Services (Not Elsewhere Classified);
  • 7033 Trailer Parks and Campgrounds;
  • 7394 Equipment, Tool, Furniture, and Appliance Rental and Leasing;
  • 7512 Car Rental Agencies (Not Elsewhere Classified);
  • 7513 Truck and Utility Trailer Rentals;
  • 7519 Motor Home and Recreational Vehicle Rentals;
  • 7999 Recreation Services (Not Elsewhere Classified).
• En cas d'utilisation d'un paiement habituel lors de l'opération initiale, l'exécution de l'opération Reauthorization est possible dans les 180 jours suivant l'autorisation initiale.
• Le montant de l'opération Reauthorization doit correspondre entièrement au montant de la commande initiale.
• Une seule opération Reauthorization peut être exécutée avec succès.

Industry Practice No Show

• L'exécution est possible dans l'année civile suivant l'autorisation initiale.
• Le nombre d'opérations No Show exécutées n'est pas limité.

Exécution des annulations et remboursements

Pour les opérations Industry Practice de type Incremental :

• Le montant de l'annulation ne peut pas dépasser le montant cumulé de l'opération initiale et de toutes les opérations Incremental associées.
• Le montant du remboursement ne peut pas dépasser le montant total de l'opération initiale et de toutes les opérations Incremental qui y sont liées.
• Dans le cas où un annulation partielle a déjà été effectuée précédemment sur la chaîne transactionnelle avec le(s) paiement(s) Inremental lié(s), alors le montant du remboursement partiel ne peut pas dépasser l'amount du paiement initial, additionné à l'amount de toutes les opérations Inremental qui y sont liées, et en soustrayant l'amount de(s) l'annulation(s) partielle(s).
• Les annulations et remboursements pour la chaîne Incremental ne peuvent être effectués que sur la commande initiale. L'exécution d'annulations et de remboursements pour les paiements Incremental isolés est interdite.

L'exécution d'annulations et de remboursements sur les opérations Industry Practice avec un type différent d'Incremental, n'ont aucune différence par rapport à l'implémentation fonctionnelle en vigueur - elles sont exécutées séparément dans le cadre de commandes isolées.

Vérification du porteur de carte

Le porteur de carte peut être vérifié sans prélever aucun paiement. Pour cela, transmettez la valeur VERIFY dans le bloc features de toute demande de paiement.

Lorsque la fonction VERIFY est utilisée, la carte de paiement sera vérifiée pour s'assurer qu'elle est utilisée par son propriétaire légitime. Si 3-D Secure est disponible pour la carte, alors une vérification 3-D Secure sera effectuée. Dans ce cas, le paramètre amount de la demande de vérification ne peut être que 0. Même si un montant de paiement est transmis dans la demande, il ne sera pas débité du compte du client. Après un enregistrement réussi, la commande passe immédiatement au statut REVERSED (annulée).

Si la fonction VERIFY est transmise avec le paramètre clientId, elle peut être utilisée pour créer une liaison sans paiement. Pour plus de détails, consultez la section Liaisons.

Jeton Open ID

Vous pouvez générer un jeton Open ID. Ce jeton peut être utilisé à la place des identifiants pour identifier le vendeur dans la passerelle de paiement.

Le jeton Open ID n'est pas privé, il peut être publié ou intégré dans une page web. Par exemple, il peut être utilisé lorsqu'une commande est passée directement depuis le navigateur. Dans ce cas, il n'y a pas de risque de divulgation de données personnelles, car seule la passerelle de paiement peut déchiffrer le jeton.

Vous pouvez utiliser le jeton Open ID pour l'authentification du vendeur lors de l'envoi de requêtes API à la passerelle de paiement. Pour cela, transmettez le jeton Open ID dans le paramètre token au lieu de transmettre userName et password. Vous pouvez utiliser le paramètre token dans les requêtes suivantes :

• register.do
• registerPreAuth.do

• getOrderStatusExtended.do

• instantPayment.do

• motoPayment.do

Pour générer un jeton Open ID, accédez à votre espace personnel, sélectionnez Paramètres dans le menu latéral, puis sélectionnez Paramètres généraux dans le bloc Vendeur. Cliquez sur Générer à côté du champ Clé publique. Si vous connaissez déjà votre jeton, vous pouvez le saisir manuellement.

Pour plus de détails, lisez ici.

Redirection vers ACS

Si 3-D Secure est requis, alors après avoir reçu la réponse à la demande de paiement, le client doit être redirigé vers ACS. Il existe deux méthodes de redirection : normale et simplifiée.

Redirection normale

Si le paiement est effectué avec 3-D Secure, les marchands doivent rediriger leurs clients vers ACS à l'adresse spécifiée dans le paramètre acsUrl, reçu dans la réponse à la demande de paiement. Le corps de la requête doit inclure MD=mdorder&PaReq=paReq&TermUrl=termUrl, où :

• MD - identifiant unique de la commande dans la passerelle de paiement ;
• PaReq - paramètre paReq, reçu dans la réponse à la demande de paiement. C'est un message qui doit être envoyé à ACS avec la redirection et contient les données nécessaires pour l'authentification ;
• TermUrl - paramètre termUrl, reçu dans la réponse à la demande de paiement. C'est l'URL vers laquelle ACS redirige le titulaire de la carte après authentification.

Cela doit être une requête POST (pas GET).

Selon la configuration convenue avec la banque, l'acheteur après authentification dans ACS sera redirigé soit vers la boutique, soit vers la passerelle de paiement.

Exemple de requête POST pour la redirection normale :

<html>
<head><title>ACS Redirect</title></head>
<body onload="document.forms['acs'].submit()">
ACS Redirect
<form id="acs" method="post" action="[result.acsUrl]">
    <input type="hidden" id="MD" name="MD" value="[MD]"/>
    <input type="hidden" id="PaReq" name="PaReq" value="[result.PaReq]"/>
    <input type="hidden" id="TermUrl" name="TermUrl" value="[result.TermUrl]"/>
</form>
</body>
</html>

Redirection simplifiée

La boutique en ligne peut également utiliser la méthode de passerelle acsRedirect.do, qui effectuera la même redirection du titulaire de la carte vers l'ACS de l'émetteur.

Paiement avec votre propre MPI/3DS Server

Merchant Plugin Interface (MPI)/3DS Server — c'est un composant de la technologie 3D Secure, qui peut être implémenté dans la passerelle de paiement ou de votre côté. Si vous avez votre propre MPI/3DS Server, vous pouvez l'utiliser pour l'autorisation autonome 3D Secure, et dans les requêtes API indiquer seulement le fait d'avoir effectué une telle autorisation. Pour activer cette fonctionnalité, contactez le service de support technique.

Si vous utilisez votre propre MPI/3DS Server, alors dans les requêtes de paiement (par exemple, paymentOrder, paymentOrderBinding.do , ou instantPayment.do) transmettez des paramètres supplémentaires dans le bloc jsonParams : eci, cavv, xid, threeDSProtocolVersion et threeDsType. Ces paramètres sont décrits ci-dessous.

eci

eci — indicateur du commerce électronique (ECI), obtenu de votre serveur 3-D Secure. Montre le niveau de sécurité utilisé lors du paiement. Défini par le serveur DS selon les résultats d'authentification obtenus et conformément aux particularités du processus de vérification du magasin. Le paramètre est transmis dans le bloc jsonParams au format à deux chiffres, par exemple, "eci": "02".

Les codes ECI peuvent différer selon le système de paiement. Ci-dessous est fournie l'interprétation des codes ECI les plus fréquemment utilisés :

cavv, xid

Si la valeur ECI diffère de celles qui sont utilisées pour l'autorisation SSL, il faut également transmettre les paramètres suivants :

• cavv - valeur d'authentification du porteur de carte ;
• xid - identifiant de la transaction d'authentification 3DS du propriétaire de carte sur le serveur 3DS (valeur ARes.dsTransID, obtenue d'ACS).

threeDSProtocolVersion

De plus, vous pouvez transmettre dans la demande de paiement le paramètre threeDSProtocolVersion (version du protocole 3DS). Il peut prendre les valeurs suivantes :

• 2.1.0 - pour 3DS 2
• 2.2.0 - pour 3DS 2

Si threeDSProtocolVersion n'est pas transmis dans la demande, alors par défaut sa valeur est considérée comme égale à 2.1.0 - pour 3DS 2.

threeDsType

Le paramètre threeDsType (type d'authentification du paiement) est nécessaire pour le paiement via votre MPI/3DS Server avec 3DS 2.

Pour les paiements avec SSL ce paramètre est facultatif et est déterminé automatiquement en fonction de la valeur ECI.

Exemple de demande

curl --request POST \\
  --url https://dev.bpcbt.com/payment/rest/paymentorder.do \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data userName=test_user \\
  --data password=test_user_password \\
  --data MDORDER=0140dda0-71ed-7706-a61f-36bd00a7d8c0 \\
  --data '$PAN=4000001111111118' \\
  --data '$CVC=123' \\
  --data YYYY=2030 \\
  --data MM=12 \\
  --data 'TEXT=TEST CARDHOLDER' \\
  --data language=en \\
  --data 'jsonParams={
  "eci": "02",
  "cavv": "AkZO5XQAA0rhBxoaufa+MAABAAA=",
  "xid": "5010857f-8d3f-74e1-9c5a-54a000cc4110",
  "threeDSProtocolVersion": "2.2.0",
  "threeDsType": "5"
}'

Si vous utilisez votre propre MPI/3DS Server, la réponse à la demande API de paiement correspondante ne contient pas de paramètres liés à 3D Secure, tels que redirect, termUrl, acsUrl et paReq.

Exemple de réponse

{
  "redirect": "https://dev.bpcbt.com/payment/merchants/temp/finish.html?orderId=01493844-d4d3-703f-9f7e-a73900a7d8c0&lang=en",
  "info": "Your order is proceeded, redirecting...",
  "errorCode": 0
}

Gestion des débits récurrents

La passerelle de paiement permet de configurer des tâches pour les débits récurrents. Les débits configurés sont ensuite automatiquement exécutés selon le calendrier défini.

Si cette possibilité est activée pour vous par notre groupe de support, vous pouvez faire ce qui suit :

• Créer des tâches récurrentes en spécifiant les données de carte et le calendrier
• Modifier les tâches récurrentes
• Arrêter l'exécution d'une ou plusieurs tâches
• Activer les tâches récurrentes
• Exclure l'exécution d'un paiement spécifique dans une tâche récurrente

Vous pouvez gérer les débits récurrents à l'aide de l'API. Pour plus de détails, voir la section API des débits récurrents.

Autorisation 3-D Secure

Qu'est-ce que 3-D Secure

3-D Secure (également appelé 3DS) - standard technique créé par Visa et MasterCard, qui permet d'effectuer une autorisation supplémentaire du titulaire de la carte du côté de la banque émettrice. Pour finaliser la transaction, il est proposé au titulaire de la carte de confirmer son identité en saisissant un mot de passe unique, un code SMS ou un code PIN temporaire.

Le terme 3DS signifie 3 Domain Server. Cette dénomination s'explique par le fait que dans chaque transaction 3-D Secure participent trois parties :

1. Domaine acquéreur. Agit en tant que 3DS requestor – initiateur du processus d'autorisation.
2. Domaine émetteur. Inclut l'ACS (Access Control Server), qui assure la confirmation de l'identité du payeur par la banque émettrice.
3. Domaine d'interaction. Agit en tant que lien entre les deux premiers domaines. En règle générale, c'est le système de paiement.

Versions du protocole

La passerelle de paiement prend en charge l'autorisation 3-D Secure pour vous protéger, vous et vos clients, de la menace de fraude aux paiements.

Pour les transactions dans le navigateur, nous utilisons 3-D Secure v2 (également appelé 3DS2) - version mise à jour du protocole 3-D Secure, qui assure une meilleure interaction entre les trois participants de la transaction. Le protocole de vérification d'authenticité 3DSv2 selon les paramètres ACS de la banque émettrice permet d'effectuer la vérification d'authenticité sans participation du client (schéma Frictionless). Dans ce cas, le client n'aura pas besoin d'effectuer d'actions pour l'authentification, telles que la saisie d'un mot de passe à usage unique ou d'autres actions.

Scénarios d'intégration

Si la page de paiement se trouve du côté de la passerelle de paiement, le marchand n'a pas besoin d'effectuer d'actions supplémentaires et peut utiliser l'API standard de la passerelle de paiement.

Si la page de paiement est située du côté du marchand, lors de l'utilisation de l'authentification du client par le protocole 3DSv2 pour chaque transaction, le marchand doit envoyer une série de requêtes API supplémentaires à la passerelle de paiement.

Les schémas d'intégration sont décrits ici.

Autorisation 3RI

3RI – c'est un type d'autorisation 3DS 2 qui est initié par le vendeur sans demander confirmation de paiement au titulaire de la carte. En fait, le paiement 3RI - c'est un paiement MIT avec tii=R ou tii=I, c'est-à-dire paiement récurrent ou paiement en plusieurs fois (voir Liaisons et types de transactions) avec autorisation 3DS 2 frictionless.

Le paiement récurrent 3RI ou le paiement en plusieurs fois n'est possible que dans le cas où la transaction initiante, lors de laquelle la liaison est sauvegardée, a été effectuée avec l'autorisation 3DS 2.

Si l'une des conditions suivantes est remplie :

• la transaction initiante était effectuée non pas via la passerelle de paiement,
• la transaction initiante était effectuée avec votre propre MPI/3DS Server,
• la transaction initiante était effectuée sans sauvegarder la liaison,

alors il est nécessaire dans le bloc jsonParams d'envoyer les paramètres supplémentaires suivants :