Une transaction représente une demande de paiement acceptée, refusée ou abandonnée, une demande d'autorisation, de remboursement ou de crédit ou d'annulation.
L’objet transaction permet de débiter votre client de sa méthode de paiement, généralement une carte de crédit, en utilisant le cardTokenId qui vient d'être créé ou à partir d'un customer s'il a été précédemment enregistré.
Lors d'une transaction avec un cardTokenID, un objet card est retourné en tant que cardId.
La transaction est en "succès" lorsqu’une demande d’autorisation a été émise par la Banque. Le code de retour banque est = 0.
Le statut indique que la transaction a rencontré un élément en "blacklist". Cela peut provenir d’une IP, d’un numéro de téléphone, d’un email ou d’un numéro de carte.
Une transaction Success doit etre "capturé" dans un délai de 7 jours calendaire afin d'etre débité sur la carte de votre Client.
NB : par défaut une transaction est automatiquement "capturée".
La transaction est en "échec" lorsque l'autorisation n’a pas été délivrée par la Banque émettrice de la carte.
Vous recevez en complément un code de rejet émis par la banque de l'émetteur de carte (code bancaire < 100)
Voir les codes de retour
Ce statut reflète l’annulation de demande de capture avant son passage en compensation. Il est possible d’annuler une transaction entre le statut transaction success et cleared.
L'authentification 3DS a échoué. Le détenteur de la carte a soumis un code incorrect.
Une transaction "Cleared" indique qu'un débit a été réalisé sur la carte de votre Client. A ce stade, vous ne pouvez donc plus annuler (cancell) la transaction mais vous pouvez la rembourser à, l'aide de la commande "REFUND".
La transaction a été refusée car elle a rencontré un élément d’une règle d'acceptation.
Lors du premier paiement, le cardTokenID est utilisé pour créer une transaction.
Une transaction unique est une transaction qui utilise une carte de débit/de crédit pour un paiement unique.
Une fois cette étape réalisée, un customer peut être créé afin qu'il puisse être utilisé à nouveau dans le cas de paiement récurrent.
Il existe deux façons de traiter une carte de paiement dans une transaction unique :
Pour traiter des paiements ou transactions récurrents (1-clic, souscription, installment...), vous devez d'abord créer un customer dans lequel une ou plusieurs card pourront être associées. Cette opération se réalise à la suite d’une première transaction réussie.
Pour plus d’information, voir l’objet "customer"
Un chargeback (également connu sous le nom de contestation, répudiation ou impayé) se produit lorsqu’un client (détenteur de carte) conteste une transaction auprès de sa banque. La banque émettrice de la carte adresse ensuite un litige auprès de la banque acquéreur afin que cette dernière lui reverse immédiatement le paiement.
Pour tout paiement par carte bancaire, votre client a la possibilité de contester un paiement pendant 13 mois maximum. En France, une opposition n'est en principe autorisée que dans le cadre d'une utilisation frauduleuse de la carte. Cependant, dans d'autres pays européens, la carte bancaire peut être utilisée dans le cadre d’un litige commercial.
Étant donné qu'un chargeback comme un refund est toujours rattaché à une transaction initiale, c'est l'initiateur de la transaction qui est débité . Dans le cas des comptes plate-forme ou revendeurs, charge à l'initiateur de récupérer ses fonds par le biais d'un transferReversal
Objet :
Une demande d’information vous est adressée par votre client afin d’obtenir des informations sur la nature de l’opération réalisée. A ce stade ce n’est pas un impayé. Il pourra se transformer en impayé en fonction des réponses apportées.
Action :
Répondre en fournissant la nature du service délivré, la preuve de consentement du client et / ou la preuve de livraison.
Objet :
Notification que la demande d’information est close. Les informations fournies auront permis d'éviter l’impayé.
Action :
Pas d’action à réaliser
Objet :
Un impayé vous est adressé par votre client. Le montant de l’opération sera débité du compte qui a initié la transaction de manière à permettre le remboursement. Des frais de traitement non remboursables s’appliquent pour le traitement du litige.
Action :
Vous disposez d’un délai de 3 semaines pour répondre en fournissant la preuve de consentement de l’opération et / ou la preuve de livraison.
Objet :
Vous avez obtenu gain cause, l’impayé a été rejeté. Les fonds vont vous être remboursés.
Action :
Pas d’action
Objet :
Vous n’avez pas obtenu gain cause, l’impayé est conservé. Les fonds ne pourront pas vous être remboursés.
Action :
Pas d’action
Objet :
Les fonds perdus lors du chargeback vous ont été remboursés.
Action :
Pas d’action
Il existe un process de règlement des différends qui permet, dans certains cas, de contester l’impayé et de prouver que le paiement est valide.
Quand un litige se produit, une notification avec le paiement litigieux est adressée à CentralPay qui vous adressera une notification. Un objet dispute est créé avec un statut nécessitant une réponse. Si lors de votre intégration vous avez configuré des hooks vous serez également informé sous forme d’événement.
Vous avez la possibilité de consulter le statut de chacune des disputes via votre plateforme, de prendre connaissance des raisons que le client a reportées au fournisseur de carte, et de traiter le litige soit en le contestant par la soumission d’une "preuve" adéquate ou soit en l’acceptant.
Quand une transaction a été réalisée avec succès, Centralpay peut adresser un email de confirmation de paiement à l’adresse renseignée dans les paramètres de receiptEmail de la requête de transaction.
Cette confirmation de paiement possède une mise en forme affichant les différentes informations de paiement, vous pouvez cependant configurer à votre convenance plusieurs paramètres à partir du backoffice.
Voir ci-dessous un exemple d’email de confirmation de paiement :
Détails des éléments marqués d’une flèche dans l’image ci-dessus.
Informations concernant le point de vente :
Les éléments 1, 2, 3, 4 mis en évidence sont configurés dans les paramètres de votre compte "Point de vente" :
Texte du pied de page du reçu :
N.B. : un profil Merchant Admin est requis pour procéder à ces paramètrages.
Vous pouvez dorénavant entrer les paramètres suivants dans la page d’édition de la confirmation de paiement (Receipt email edition page) :
Le contenu du pied de page (champ 5) sera affiché à la fin de l’email.
Ce template sera utilisé seulement pour le(s) point(s) de vente sélectionné(s).
La langue dépendra des paramètres du browserUserAgent, du browserAcceptLanguage et de l’endUserLanguage envoyés dans votre requête de transaction.
Langue de la confirmation de paiement :
Si vous désirez que le détenteur de carte reçoive la confirmation de paiement dans une langue spécifique, vous devez renseigner la valeur endUserLanguage.
Dans le cas contraire, nous utiliserons les valeurs du champ browserAcceptLanguage et par défaut l’anglais si aucun élément n’est renseigné.
| endUserLanguage string (2) |
User language (browser default) Required: NO Validation: [a-z]{2} Alpha2 ISO 639-1 language code Note: Payment Receipt language will be defined by endUserLanguage. |
| browserAcceptLanguage string (255) |
List of languages installed in the browser Required: NO Validation: [a-z]{2}([-A-Z]{2})? Alpha2 ISO 639-1 language code and, optional, Alpha2 ISO 3166-2 country code (optional) Examples: de, en-US, en-GB | fr, es-ES, it | es, en-GB, nl, ru |
| browserUserAgent string (255) |
Browser and operating system identifier Required: NO Validation: .{0,255} Example: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 |
Fonctionnement des OTA
Les grands OTA que sont Booking.com, Expedia.com, hotels.com ou Agoda.com peuvent collecter les règlements lors de la réservation. Dans ce cas, ils fournissent aux hôteliers, non pas les données de la carte du client, mais une alias, qui est une carte virtuelle ou VCC .
Cartes virtuelles ou virtual credit card (VCC)
Une carte virtuelle ou VCC est généralement émise pour un usage encadré afin de limiter les risques de compromission.
Une carte virtuelle représente en quelque sorte l’alias d’une carte existante qui ne pourra être utilisé qu’à partir d’une certaine date et depuis un MCC défini. En l’occurrence, dans le secteur du tourisme, il est nécessaire d’avoir un contrat avec le MCC 7011 (HOTELS) pour pouvoir la débiter.
Ainsi, dans le cas où le numéro de carte tombait entre les mains d’une personne mal intentionnée, elle ne pourrait pas déclencher de débit sur la carte source.
Etant donné la nature spéciale des cartes issues par ces OTA, il est en général impossible de réaliser des demandes d’autorisation, de pré-autorisation ou de vérification au moment de la commande.
Si la carte n’est débitable que le jour de la réservation par un MCC 7011 par exemple, l’émetteur, en général MASTERCARD B2B PRODUCT, renverra un code d’erreur pour transaction invalide (12).
Carte virtuelle Booking.com
Booking.com utilise des cartes virtuelles sur certaines destinations. En fonction du paramétrage réalisé sur le site de l’hôtel, une réservation pourra être réalisée avec ou sans prise d’empreinte carte. Si l’hôtelier a choisi de demander un moyen de paiement, alors BOOKING.com génèrera une carte virtuelle et l’adressera à l’hôtelier ou à son prestataire technique. Avec la crise du covid19, booking n'autorise plus les débits de ses VCC qu'un jour après le checkin du client.
En savoir plus sur le fonctionnement des cartes virtuelles de booking.com
Carte virtuelle Expedia
Chez EXPEDIA, il est possible de laisser le visiteur choisir entre la possibilité de payer à l’hôtel (Hotel Collect) ou de payer directement lorsqu’il réalise la réservation (Expedia Collect). Cette option est appelée Expedia Traveler Preference (ETP). Si un client utilise la méthode Expedia Collect, une carte virtuelle sera alors générée.
En savoir plus sur le fonctionnement des cartes virtuelles de expedia.com
Comment gérer une carte virtuelle avec Centralpay
La meilleure méthode pour stocker une VCC et de pouvoir l'utiliser une fois disponible est de créer un « Customer » et de lui associer la carte concernée.
Deux options sont ouvertes :
Ainsi, créer un customer dans l’API Centralpay permet de tokeniser la carte virtuelle, sécuriser son stockage et de faciliter son utilisation lorsque les conditions d’acceptation initiales auront été réunies.
En savoir plus sur la création des customer