Paiements directs
Description générale
Lors d'un paiement direct, la boutique en ligne possède sa propre page de paiement pour collecter les données de carte directement via son site web.
Utilisation de seToken
Si vous collectez les données de carte de votre côté et ne souhaitez pas qu'elles soient présentes sur votre serveur, vous devez utiliser seToken (Self Encrypted Token) — un jeton auto-signé utilisé pour la transmission sécurisée des données de carte. Si vous utilisez seToken, la conformité PCI DSS est également requise selon le niveau de votre activité transactionnelle. Au minimum, il est nécessaire de remplir le questionnaire d'auto-évaluation SAQ A (lire plus sur PCI DSS ici).
Veuillez noter que seToken peut être généré à l'aide du SDK.
Cliquez ici pour obtenir des informations supplémentaires sur seToken.
Schéma d'intégration
- Le client sélectionne un produit dans la boutique en ligne et clique sur le bouton Acheter.
- Le serveur de la boutique en ligne reçoit la demande d'achat et ouvre la page de paiement.
- L'acheteur saisit les données de sa carte sur la page de paiement de la boutique en ligne.
- Le serveur de la boutique en ligne collecte les données de carte.
-
Paiement. Le serveur de la boutique en ligne demande l'enregistrement et le paiement de la commande en envoyant un appel API instantPayment.do à la passerelle de paiement. Cette demande doit contenir le paramètre
amount(montant du paiement en unités minimales de devise) et le paramètrebackUrl(adresse vers laquelle le client sera redirigé après le paiement réussi à l'Étape 9). Il transmet également les données de carte à la passerelle de paiement.
Exemple de demande :
shell
curl --request POST \
--url https://dev.bpcbt.com/payment/rest/instantPayment.do \
--header 'content-type: application/x-www-form-urlencoded' \
--data userName=test_user \
--data password=test_user_password \
--data amount=100 \
--data currency=978 \
--data description=my_first_order \
--data orderNumber=1218637308 \
--data pan=5000001111111115 \
--data cvc=123 \
--data expiry=203012 \
--data cardHolderName="TEST CARDHOLDER" \
--data language=en \
--data backUrl=https%3A%2F%2Fmybestmerchantreturnurl.com \
--data failUrl=https%3A%2F%2Fmybestmerchantreturnurl.com
Exemple de réponse (3-D Secure requis) :
json
{
"errorCode": "0",
"orderNumber": "1218637308",
"orderId": "0179018d-8f96-7fbe-bc2b-4b7e00a7d8c0",
"info": "Your order is proceeded, redirecting...",
"acsUrl": "https://dev.bpcbt.com/payment/rest/getwhitepageurl.do?mdOrder=0179018d-8f96-7fbe-bc2b-4b7e00a7d8c0&threeDsServerTransId=2aa43ebc-e997-4e54-9ddc-38228bc1d302",
"paReq": "White page paReq",
"termUrl": "White page termUrl",
"orderStatus": {
"expiration": "203012",
"cardholderName": "TEST CARDHOLDER",
"depositAmount": 0,
"currency": "978",
"authCode": 2,
"ErrorCode": "0",
"ErrorMessage": "Success",
"OrderStatus": 0,
"OrderNumber": "1218637308",
"Pan": "500000**1115",
"Amount": 100,
"Ip": "x.x.x.x"
},
"is3DSVer2": false
}
Exemple de réponse (3-D Secure non utilisé) :
json
{
"errorCode": "0",
"orderNumber": "1218637308",
"orderId": "0179018d-8f96-7fbe-bc2b-4b7e00a7d8c0",
"info": "Your order is proceeded, redirecting...",
"redirect": "https://mybestmerchantreturnurl.com/?orderId=0179018d-8f96-7fbe-bc2b-4b7e00a7d8c0&lang=en",
"orderStatus": {
"expiration": "203012",
"cardholderName": "TEST CARDHOLDER",
"depositAmount": 100,
"currency": "978",
"approvalCode": "123456",
"authCode": 2,
"rrn": "111111111111",
"ErrorCode": "0",
"ErrorMessage": "Success",
"OrderStatus": 2,
"OrderNumber": "1218637308",
"Pan": "500000**1115",
"Amount": 100,
"Ip": "x.x.x.x"
},
"is3DSVer2": false
}
-
Si 3-D Secure est requis (le paramètre
acsUrlest retourné à l'Étape 5), la passerelle de paiement se connecte au Directory Server pour obtenir l'accès à ACS. Elle retourne toutes les données nécessaires pour la redirection d'ACS vers la boutique en ligne.Si 3-D Secure n'est pas utilisé, les Étapes 7–9 sont ignorées, et le client est redirigé vers la page de confirmation de paiement (Étape 10). Le paramètre
redirectdans ce cas est ignoré, car la boutique en ligne utilise sa propre page de confirmation de paiement.
-
Le serveur de la boutique en ligne demande une redirection simplifiée de l'acheteur vers ACS, en envoyant l'appel API acsRedirect.do à la passerelle de paiement. Dans la requête est utilisé le paramètre
orderId(obtenu à l'Étape 5).Exemple de requête :
https://dev.bpcbt.com/payment/acsRedirect.do?orderId=0179018d-8f96-7fbe-bc2b-4b7e00a7d8c0
Il est également possible de rediriger le client vers ACS avec une requête POST (redirection normale). La description de cette méthode est disponible ici.
La passerelle de paiement redirige le client vers ACS.
Le porteur de carte confirme la commande et ACS le redirige vers la passerelle de paiement.
-
L'acheteur retourne sur la page de la boutique en ligne (à l'adresse indiquée lors de la finalisation de la commande à l'Étape 5) ou ferme la page.
Exemple d'URL de redirection :
https://mybestmerchantreturnurl.com/?orderId=0179018d-8f96-7fbe-bc2b-4b7e00a7d8c0&lang=en
La passerelle de paiement envoie de manière asynchrone la notification de rappel au serveur de la boutique en ligne (si cette possibilité est activée).
-
(Facultatif) La boutique en ligne envoie une requête getOrderStatusExtended.do à la passerelle de paiement pour vérifier le statut de la commande et s'assurer que la commande est effectivement payée. La requête contient le paramètre
orderId, obtenu à l'Étape 5. En réponse, la passerelle de paiement retourne le statut de la commande dans le paramètreorderStatus. Le statut2signifie un paiement réussi, le statut1signifie une pré-autorisation réussie pour les paiements en deux étapes (dans ce cas, les fonds sont mis en attente). En plus, le paramètreactionCodeest retourné - il contient le code de réponse du traitement bancaire. Voir la liste des codes de réponse ici.Pour plus d'informations, voir la section Obtention du statut de la commande.