Table des matières

Historique des versions

Intégration du paiement par carte

Informations generales sur les paiement par carte

General information

Axepta BNP Paribas's payment platform processes all major cards and currencies worldwide. Card data is protected against unauthorized access by TLS encryption. Additional security functions are integrated fraud prevention and risk management. Our standardized settlement files guarantee a straightforward reconciliation processes in your accounting.

Verified by Visa and MasterCard SecureCode secure your payment claim by password validation if a customer disputes the payment later. American Express SafeKey also uses the 3D-Secure technology, which means that the card holder must confirm their identity with an authentication feature.

Transaction processing can be made via

• Payment platform forms
• Server-to-server connection
• Batch transfer

3D Secure

La plateforme de paiement de BNP Paribas prend en charge les principales cartes de paiement et devises dans le monde. Les données cartes sont protégées contre tout accès non autorisé grâce au chiffrement TLS. Des fonctions de sécurité supplémentaires sont intégrées, comme la prévention de la fraude et la gestion des risques.

MasterCard SecureCode (UCAF), MasterCard SecureCode (UCAF), Verified by Visa (VbV), Diners ProtectBuy, JCB J/Secure and American Express SafeKey are authentication methods which verify the identity of the card holder before making the payment. 

Merchants benefit from authentication with 3D Secure because the card schemes provide a liability shift.

From a technical perspective 3D Secure is an authentication process which precedes the payment: Once the card data has been entered, the payment platform checks the identity of the card holder and does not process the payment until the authentication is done.

For further steps it is important to know if the card connection is made via form interface or via Server-to-Server connection. In the first case the payment platform form assumes the further authentication process, with Server-to-Server connection the merchant has to manage the authentication through a separate interface.

et American Express SafeKey permettent de sécuriser les demandes de paiement avec une validation du porteur de la carte grâce à la technologie 3D Secure, ce qui signifie que le porteur de carte doit confirmer son identité via une fonctionnalité d’authentification.

Le traitement d’une transaction par carte peut être effectué via :

• Le formulaire de la plateforme de paiement,
• Une connexion serveur-to-serveur,
• Un transfert par batch

Les commerçants bénéficient du transfert de responsabilité lorsqu’ils utilisent l’authentification 3D Secure.

Sur le plan technique, le 3D Secure représente un processus d’authentification qui précède le paiement. Une fois les données de carte saisies, la plateforme de paiement vérifie l’identité du porteur de carte et le paiement n’est seulement exécuté qu’après l’authentification.

Il est essentiel de savoir si le paiement par carte est effectué via la page de paiement ou via une connexion serveur-to-serveur. Dans le premier cas, la page de paiement gère le processus d’authentification, alors que dans le cas d’une connexion server-to-server, le commerçant doit gérer l’authentification via une interface distincte.

Le formulaire de la page de paiement et les donnees de carte sont héberges par

BNP Paribas (payssl.aspx)

Chart of process flow

Image Removed

Schéma des flux

Image Added

Exécution d’une transaction avec

3D Secure

• The customer selects the card payment method in the shop and enters the card information.metho
• Le client sélectionne le paiement par carte sur le site et saisit les informations relatives à sa carte.
• La plateforme de paiement reçoit les informations liées à la carte et vérifie, via une connexion au réseau de la carte The payment platform receives the data and checks, via a connection to the scheme (Visa, MasterCard, Diners, JCB or , American Express) whether this card is registered for si la carte est enregistrée 3D Secure (Verified, SecureCode, Diners ProtectBuy, JCB-Card J/Secure or ou SafeKey. If the card is not registered a card payment is carried out with TLS.
• With that the transaction gets a flag which identifies payments with 3D Secure. This marking tells the Acquiring Bank that the transaction is using 3DS authentication and a secured payment claim is obtained based on the Liability Shift in case the card holder disputes the payment.
• The payment platform opens a new browser window which connects the customer to its bank. In this window the customer enters the password received by his bank.

If the password is correct, the payment platform obtains a confirmation (as signature). Only after confirmation does the payment platform start the payment and send the transaction with the signature to BNP Paribas.

• ). Si la carte ne l’est pas, le paiement se fait via TLS.
• La transaction est marquée par un « flag ». Cette marque (flag) indique à la banque acquéreur que cette transaction utilise l’authentification 3DS. Cette indication est essentielle dans le cas où le porteur de la carte contesterait le paiement car elle indique à la banque le transfert de responsabilité (Liability Shift).

Image Added

Si le mot de passe est correct, la plateforme de paiement obtient une confirmation. Ce n’est qu’après confirmation que la plateforme de paiement débute le paiement.

Paramètres de la requête de paiement

Pour effectuer un paiement par carte via le formulaire de la plateforme de paiement, accédez à l’URL suivante

Request parameters

In order to make a card payment via the payment platform form, go to the following URL :

This section explains the parameters which are the same for each connection. The second table explains all response parameters which are also the same for all card connections.

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Cette section décrit les paramètres à envoyer pour chaque connexion. Le second tableau décrit les paramètres de réponse qui sont identiques pour tous les paiements carte.

Remarque : pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de donnée approprié pour chaque paramètre.

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Pour adapter la mise en page de la page SSL de votre boutique, vous pouvez utiliser les paramètres non chiffrés suivants :

To adapt the layout of the SSL-page to your shop you can use the following unencrypted parameters to configure colours, fonts and images:

Le tableau suivant décrit les paramètres du résultat transmis par la plateforme de paiement à URLNotify, URLSuccess ou URLFailure. Si vous avez spécifié le paramètre Response=encrypt, les paramètres suivants sont envoyés chiffrés avec la méthode Blowfish à votre système :

The following table describes the result parameters that the payment platform transmits to your URLNotify, URLSuccess or URLFailure. If you have specified the Response=encrypt parameter, the following parameters are sent Blowfish encrypted to your system:

The decrypted payment platform response within the Data parameter looks like this:

PayID=a234b678e01f34567090e23d567890ce&XID=50f35e768edf34c4e090e23d567890ce&Trans ID=100000001&Status=AUTHORIZED&Description=AUTHORIZED&Code=00000000

Le formulaire de la page de paiement est héberge par le commerçant et les donnees de carte sont hébergees par BNP Paribas (paynow.aspx)

Same 3DS Process as for re direct.

Silent order post links the benefits of the payment platform forms and Server-to-Server connections: AS opposed to the payment platform form, where the form is loaded from the payment platform server by calling payssl.aspx, the Silent order post form has to be provided by the merchant’s system. The form uses the same parameters as described here below.

Même processus 3DS que pour payssl.aspx

Un Silent-order post associe les avantages des formulaires de la plateforme de paiement et de la connexions serveur-to-serveur : contrairement au formulaire de la plateforme de paiement, où le formulaire est chargé depuis le serveur de la plateforme de paiement via l’appel de payssl.aspx, le Silent order post doit être fourni par le système du commerçant. Le formulaire utilise les mêmes paramètres que ceux décrits ci-dessous.

Contrairement au formulaire de la plateforme de paiement, les paramètres ne sont pas transférés en tant que paramètres d’URL comme c’est le cas lors de l’appel payssl.aspx, mais en tant que paramètres de saisie du formulaireIn contrast to the payment platform form, the parameters are not forwarded as URL parameters as is the case when calling the payssl.aspx, but as form input parameters.

The card data must be transmitted to Les données de carte doivent être transmises à paynow.aspx with the following parametersavec les paramètres suivants :

After the customer has entered his card data, the payment data is forwarded to the Silent order post page, where the further payment processing takes place via 3D-Secure. The form details must be directly forwarded to the Silent order post page and may not be transmitted to the merchant’s system! Also, no PCI-relevant data may be transmitted to the Silent order post page as additional input parameters!

Une fois que le client a saisi les données de sa carte, les données de paiement sont transférées à la page Silent order post où le paiement est exécuté via 3D Secure. Les détails du formulaire doivent être directement transférés à la page Silent order post, mais ne doivent pas  être transmis au système du commerçant. De plus, il se peut qu’aucune donnée PCI ne soit transmise à la page Silent order post en tant que paramètres de saisie supplémentaires.

Remarque : les nouvelles tentatives automatiques au niveau de la plateforme de paiement doivent être désactivées lors de l’utilisation de Paynow.aspx. En effet, lors d’une nouvelle tentative, la plateforme de paiement ne peut pas rediriger le client vers le formulaire de saisie  de la boutique précédemment utilisé. Contactez le Support BNP Paribas pour désactiver les nouvelles tentativesNotice: Please note, that automatic retry attempts at the payment platform must be deactivated when using the Paynow.aspx. The background is that at a retry attempt, the payment platform cannot send back the customer to the previously used special shop form. Please contact the BNP Paribas Support to deactivate the retry attempts.

HTML form example:

Le formulaire de la page de paiement et les donnees carte sonf héberge par le commerçant (Serveur-to-

Serveur)

Schéma du flux d’exécution via une connexion serveur-to-

serveur

Image Removed

Image Added

Exécution d’une transaction avec 3D Secure via la connexion serveur-to-

serveur

Pour procéder à l’authentification, la plateforme de paiement connecte le porteur de carte à sa banque, qui confirme son identité. Un paiement exécuté avec Verified by Visa, To carry out authentication, the payment platform connects the card holder to his bank, which confirms the identity. A payment process with Verified by Visa or MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure or ou American Express SafeKey comprises two steps: authentication and payment.

In the next steps, there are two different cases in which the payment platform responds:

• Case 1: card registered for a 3D Secure system with a pop-up payment page

se fait en deux étapes : authentification et paiement.

Dans les étapes suivantes, la plateforme de paiement répond différemment dans deux situations :

• Cas 1: Authentification 3D Secure via une page affichée en pop-up

Si la carte est enregistrée pour Verified, If the card is registered for Verified or SecureCode, ProtectBuy, J/Secure or SafeKey, the payment platform returns the socket-connection HTML source code with a JavaScript function. This JavaScript function creates the connection to the bank with which the customer is authenticated by entering its password into a popup-window. The HTML source code with the JavaScript function Initiate3DSec() which the payment platform sends to the shop must be embedded in the response page which the shop displays in the customer's browser.

Notice: Please note that the use of a popup window can lead to problems with popup blockers in the customer's browser. Therefore case 2 describes an alternative in the form of an iFrame variant.

ou SafeKey, la plateforme de paiement retourne une page HTML affichée en pop-up (fenêtre superposée). Cette page HTML (qui contient une fonction en Javascript appelée « Initiate3DSec() ») effectue la connexion avec la banque du porteur de la carte et permet de faire la correspondance entre le code entré par le porteur (client de la boutique) et le code envoyé par la banque.  

Remarque : l’utilisation d’une fenêtre séparée peut entraîner des problèmes avec les bloqueurs de fenêtres contextuelles (pop-up) dans le navigateur du client. Par conséquent, le cas 2 décrit une alternative sous la forme d’une variante iFrame.

L’exemple suivant présente une page dans laquelle le code HTML est intégré The following example shows a response page in which the HTML code is embedded :

 Notice

: You can also use this code if you only want to verify the identity of the card holder without making a card payment. Our Support team can set your account in a way that the payment platform can carry out just the authentication with Verified or Remarque : vous pouvez aussi utiliser ce code si vous voulez uniquement vérifier l’identité du porteur de la carte sans procéder à un paiement par carte. Notre équipe support peut paramétrer votre compte de façon à ce que la plateforme de paiement puisse procéder à l’authentification avec Verified, SecureCode, ProtectBuy, J/Secure or SafeKey without payment ou SafeKey sans faire de paiement (Authentication Hostinghosting).

After the customer has been authenticated with its bank, the bank's Lorsque le client a été authentifié grâce à sa banque, le serveur de contrôle d’accès (ACS, Access Control Server (ACS) requests the TermURL in the shop. In the case of this Request the ACS transfers the following parameters ) de la banque appelle l’url  TermURL de la boutique. Dans le cas de cette requête, l’ACS transfère les paramètres suivants via GET (QueryString) to the TermURL of the shop à l’url  TermURL de la boutique : MID, PayID and et TransID. The PARes parameter is transferred Le paramètre PARes est transféré via POST.

NoticeRemarque : The PAResponse parameter must be URL encoded but not Blowfish-encrypted since the content can include special characters.The parameter must be transferred via POST to the following URL le paramètre PAResponse doit être URL-encoded, mais non chiffré avec la méthode Blowfish, car le contenu peut inclure des caractères spéciaux.

Le paramètre doit être transféré dans son intégralité via la méthode POST à l’URL suivante :

Notice: If you forward the PARes and MID of the ACS parameters please use the specified parameter name MerchantID, PAResponse for the direct3d.aspx page.

• Case 2: card registered for a 3D Secure system with an iFramed payment page

Alternatively to the popup window, the card holder can also carry out authentication with the bank in an iFrame variant; this avoids difficulties with popup blockers in the customer's browser. Provided the card is registered on the Directory Server, the payment platform returns the following parameters via the socket connection.

Remarque : si vous transférez les paramètres PARes et MID, utilisez les paramètres MerchantID (identifiant du commerçant) et PAResponse pour la page direct3d.aspx.

• Cas 2: Authentification 3D Secure via une page affichée en iFrame

Une alternative au pop-up, le commerçant peut choisir l’iFrame comme méthode d’affichage de la page d’authentification 3DS. Le porteur de carte peut effectuer l’authentification auprès de sa banque sur la page où il se trouve via une autre interface affichée en iFrame ; cela évite les difficultés rencontrées avec les bloqueurs de fenêtres contextuelles (pop-up) dans le navigateur du client.

Si la carte est enregistrée sur le serveur (Directory Server), la plateforme de paiement renvoie les paramètres suivants via la connexion socket :

Response parameters of Socket-connection for the Authentication Request

Notice: Please note in this process that data must sometimes be transferred directly from the bank network. Therefore e.g. the ACSURL parameter is not URL-encoded, although the payment platform uses other URL-encoded data.

Remarque : dans ce processus, les données doivent parfois être transférées directement depuis le réseau de la banque. Par conséquent, le paramètre ACSURL n’est pas URL-encoded, bien que la plateforme de paiement utilise d’autres données URL-encoded.

Ces paramètres doivent être inclus en tant que champs MASQUÉS dans une page HTML qui poste elle-même vers l’URL ACS. L’exemple suivant présente cette page HTML, dans laquelle les paramètres de retour sont intégrés These parameters should be included as HIDDEN fields in an HTML page which posts itself to the ACS-URL. The following listing shows one such HTML page, in which the return parameters are embedded:

Notice: You can also use this code if you only want to verify the identity of the card holder without immediately making a card payment (Authentication Hosting). BNP Paribas Support can configure your checkout so that the payment platform can carry out Verified by Visa or SecureCode without payment.

After the customer has been authenticated with its bank, the bank's Access Control Server (ACS) requests the TermURL in the shop. In the case of this Request the ACS transfers the following parameters via GET (QueryString) to the TermURL of the shop: MID, PayID and TransID (unencrypted). The PARes parameter is transferred unencrypted via POST.

Notice: The PAResponse parameter must be URL encoded but not Blowfish-encrypted since the content can include special characters.

Remarque : vous pouvez aussi utiliser ce code si vous voulez uniquement vérifier l’identité du porteur de carte sans procéder immédiatement à un paiement par carte (hébergement d’authentification). Le Support BNP Paribas peut configurer votre paiement, afin que la plateforme de paiement puisse appliquer le Verified by Visa ou le SecureCode sans paiement.

Lorsque le client a été authentifié grâce à sa banque, le serveur de contrôle d’accès (ACS, Access Control Server) de la banque appelle l’url TermURL de la boutique. Dans le cas de cette requête, l’ACS transfère les paramètres suivants via GET (QueryString) via l’url TermURL de la boutique : MID, PayID et TransID (sans chiffrement). Le paramètre PARes est transféré sans chiffrement via POST.

Remarque : le paramètre PAResponse doit être encodé au format URL, mais non chiffré avec la méthode Blowfish, car le contenu peut inclure des caractères spéciaux.

Le paramètre doit être transféré dans son intégralité via POST à l’URL suivante The parameter must be transferred in whole via POST to the following URL:

Notice: If you forward the PARes and MID of the ACS parameters please use the specified parameter name MerchantID, PAResponse for the direct3d.aspx page.

Remarque : si vous transférez les paramètres ACS, PARes et MID, utilisez l’identifiant du commerçant et PAResponse pour la page direct3d.aspx.

Appel de l’interface : paramètres généraux

Remarque : pour les paiements par carte avec 3D Secure, prenez connaissance des différents cas expliqués dans le chapitre précédent. Si la carte est enregistrée pour Verified, SecureCode ou SafeKey, la phase suivante est divisée en deux étapes : authentification et paiement. Toutefois, cela commence toujours de la même façon via l’interface direct.aspx. La première réponse correspond à la réception du code JavaScript ou d’autres paramètres afin de procéder à un second appel de l’interface direct3d.aspx. Ce n’est qu’après que vous recevez le paramètre répertorié en tant que réponse.

Pour procéder à un paiement par carte TLS via une connexion serveur-to-serveur, appelez l’URL suivante

Call of interface: general parameters

Notice: For card payments with 3D Secure, please note the different cases as explained separately in the previous chapter. If the card is registered for Verified or SecureCode or SafeKey, the next phase is divided into two steps of authentication and payment. However, it always begins in the same way via the direct.aspx interface. The first response is the receipt of Javascript code or other parameters in order to carry out a second call up of the direct3d.aspx interface. Only after that, you receive the listed parameter as a response.

To carry out a TLS card payment via a Server-to-Server connection, call the following URL:

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

Remarque : pour des raisons de sécurité, la plateforme de paiement rejette toutes les requêtes de paiement avec des erreurs de formatage. Par conséquent, utilisez le type de donnée approprié pour chaque paramètre.

Le tableau suivant décrit les paramètres de requête de paiement chiffrés :

Le tableau suivant fournit les paramètres avec lesquels la plateforme de paiement répond :

The following table gives the parameters with which the payment platform responds:

Paiement par batch

This section describes the parameters that must be transferred within the data set (Record) for executing a card payment and which information can be found within the response file about the payment status.

Cette section présente les paramètres qui doivent être transmis dans les enregistrements du fichier Batch (Record) pour l'exécution d'un paiement par carte, ainsi que les informations pouvant être contenues dans le fichier de réponse concernant l'état du paiement.

La structure devant être utilisée pour un paiement par carte au sein d'un fichier Batch est comme suit The structure for a card payment within a Batch file to be submitted is the following :

Example for batch versionsExemple de différentes versions batch :

The following table describes the individual fields and values used within the data set (record) in the batch file:

Le tableau ci-dessous présente les différents champs et valeurs utilisés dans l'enregistrement (record) au sein du fichier batch :

Le tableau ci-dessous indique les paramètres de réponse que le gestionnaire de fichier Batch (Batch Manager) sauvegarde dans la zone d'enregistrement (Record) pour chaque transaction (les paramètres par défaut non détaillés ici tels que <TransID> ou <RefNR>, ainsi que les paramètres de requête sont retournés inchangés et correspondent à l'appel tel que spécifié plus haut) :

The following table describes the response parameters which the batch Manager saves in the “Record” area for each transaction (standard parameters not explained here, such as <TransID> or <RefNR> and request parameters are returned unchanged and correspond to the call as specified before):

Gestions de paiement par carte

Capture

Le commerçant peut choisir différentes options de capture :

• Manuelle
• Automatique
• Automatique avec délais personnalisable (de 1 à 696 heures)

En choisissant le mode manuel, il est nécessaire pour le commerçant de valider manuellement chacune des transactions. Le commerçant doit valider la transaction avant 7 jours (délais de garantie des fonds). Les captures manuelles sont possibles via une connexion server-to-server

Card payments management

Capture

The merchant can choose one of these different options of capture:

• Manual capture
• Automatic capture
• Automatic capture with customized delay (number from 1 to 696)

When choosing the manual mode, it’s necessary for the merchant to validate manually each transaction. A transaction must be validated before 7 days. Captures are possible via a Server-to-Server connection. To perform captures via a Server-to-Server connection please use the following URL :

https://paymentpage.axepta.bnpparibas/capture.aspx

When choosing the automatic, capture is made every day at the end of the day.

When choosing the automatic mode with customized delay, the merchant sets a delay in hours (from 1 to 696) that corresponds to the frequency of capture

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

The following table describes the payment platform‘s response parameters:

Partial captures are also possible by setting the « Amount » parameter with the partial amount to capture.

Cancellation

Cancellation function allows to cancel a transaction before it gets captured.

BNP Paribas manages the cancellation requests by proceeding to 2 verifications:

-              The amount: It’s forbidden to cancel an amount that is superior to the initial amount of the transaction. 

-              Payment capture time: Once a payment is captured, it can’t be cancelled anymore.

To make a cancellation, use the following URL:

https://paymentpage.axepta.bnpparibas/reverse.aspx

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

Notice: Reverse.aspx does not only reverse authorizations, but any last transaction stage. If the last transaction was a capture, Reverse.aspx initiates the reverse, e.g. a refund. Therefore, the utmost caution is urged. Use is at your own risk. We recommend checking the transaction status with Inquire.aspx before using Reverse.aspx.

The following table describes the encrypted payment request parameters:

The following table describes the payment platform response parameters:

Refunds

Refunds allow to re-credit a customer who was previously debited (product not delivered, product damaged, product sent back…). The customer’s bank account is credited with the exact amount as the debit amount of the merchant. The merchant can refund a customer until 12 months following the purchase.

Refunds are not permitted for unpaid transactions.

Refunds are possible via a Server-to-Server connection. The payment platform permits refunds which relate to a capture previously activated by the payment platform and allows merchants to carry out refunds without a reference transaction. This section describes the processing of refunds with reference transactions. If you refer to a capture for a refund, the amount of the refund is limited to the amount of the previous capture.

To carry out a refund with a reference transaction, please use the following URL:

https://paymentpage.axepta.bnpparibas/credit.aspx

Notice: For security reasons, the payment platform rejects all payment requests with formatting errors. Therefore, please use the correct data type for each parameter.

The following table describes the encrypted payment request parameters:

The following table describes the payment platform response parameters:

One click / wallets

One Click payment can be handled via Tokenization. The token provides merchant with a fully-fledged replacement for the card’s number. The token is generated by the platform but retains the same options and functions as the real card number. This enables merchants to avoid the process of obtaining PCI DSS (Payment Card Industry Data Security Standard) certification.

There is also an added benefit for returning customers, in that they won't need to re-enter their card details.

One click benefits:

• improving the customer´s journey for recurring buyers
• favors impulsive purchases at the same time

The merchant can use the parameter PCNr to make enable 1-Click payments. This could be possible with the CB2A protocol, if they can handle:

• an original transaction is needed for the TOKEN to be generated
• reception of the TOKEN from BNP Paribas in the response sent by the payment platform

Recurring payment (subscription)

Recurring payment allows automatic payments to be made at regular time intervals. When a user makes a subscription, there is a parameter that will be automatically defined when sending payment requests; it is the RTF parameter which will have two possibilities:

• I = Initial payment to initiate a subscription.
• R = Recurring payment.