Paiements par carte
Paiements par carte : du terminal à l’acquéreur, puis jusqu’au grand livre
Terminaux EMV et passerelles de paiement connectés aux acquéreurs via ISO 8583 ou des API, avec des fichiers de règlement rapprochés dans l’ERP.
Schéma
Faites défiler latéralement pour voir tout le schéma.
Paiements par carte : autorisés en caisse, réglés ensuite, rapprochés dans l’ERP
Le terminal ou la page de paiement interroge la passerelle, la passerelle interroge l’acquéreur, et l’acquéreur achemine la demande vers le réseau de cartes et l’émetteur. Les fichiers de règlement arrivent plus tard et sont rapprochés des ventes et des frais dans l’ERP. En cas d’absence de réponse dans le délai, une annulation automatique garantit que le client n’est jamais débité deux fois.
- Flux principal
- Asynchrone
- Chemin d’exception
Le flux, étape par étape
- Source Terminal EMV ou paiement en ligne, destination Passerelle de paiement : Demande d’autorisation, via EMV · REST/JSON (flux principal).
- Source Passerelle de paiement, destination Acquéreur : Autorisation, via ISO 8583 (flux principal).
- Source Acquéreur, destination Réseau de cartes et émetteur : Acheminée vers l’émetteur, via ISO 8583 (flux principal).
- Source Acquéreur, destination Passerelle de paiement : Acceptée ou refusée, via ISO 8583 (asynchrone).
- Source Acquéreur, destination Couche d’intégration : Fichiers de règlement et de frais, via SFTP (asynchrone).
- Source Couche d’intégration, destination ERP : Ventes réglées, frais et reversements, via REST/JSON (flux principal).
- Source Passerelle de paiement, destination Terminal EMV ou paiement en ligne : Pas de réponse dans le délai : annulation automatique, via ISO 8583 0400 (chemin d’exception).
- Source Couche d’intégration, destination Équipe des opérations de paiement : Écart de règlement ou rétrofacturation (chemin d’exception).
Présentation
Voici le parcours d’un paiement par carte : du terminal ou de la page de paiement en ligne jusqu’à l’acquéreur, au réseau de cartes et à l’émetteur, puis le retour. Le client attend la réponse en caisse. L’argent, déduction faite des commissions, arrive plus tard dans un fichier de règlement qui doit être rapproché des ventes enregistrées dans votre ERP.
L’architecture de référence transmet les autorisations via une passerelle de paiement qui tokenise la carte et achemine la demande vers l’acquéreur, en ISO 8583 ou par l’API de l’acquéreur. Les fichiers de règlement et de commissions sont collectés par la couche d’intégration, rapprochés des ventes d’origine et comptabilisés dans l’ERP sous forme de ventes, de commissions et de versements.
L’architecture couvre aussi les incidents. Une demande restée sans réponse dans le délai imparti est annulée, afin que le client ne soit pas débité deux fois. Un règlement qui ne correspond pas, ou une rétrofacturation, est transmis à votre équipe des opérations de paiement, avec la vente d’origine en pièce jointe.
Fonctionnement du flux
- 01
Partir du terminal ou de la page de paiement
Le terminal EMV lit la puce ou la carte sans contact, ou la page de paiement en ligne recueille la carte via une page hébergée, puis envoie une demande d’autorisation à la passerelle.
- 02
Autoriser via la passerelle
La passerelle remplace le numéro de carte par un jeton et transmet l’autorisation à l’acquéreur, en ISO 8583 ou par l’API de l’acquéreur.
- 03
Acheminer vers l’émetteur
L’acquéreur achemine la demande via le réseau de cartes jusqu’à l’émetteur, qui l’accepte ou la refuse.
- 04
Renvoyer la réponse
L’acceptation ou le refus revient par le même chemin jusqu’au terminal ou à la page de paiement, avec son code réponse.
- 05
Recevoir le règlement
L’acquéreur envoie ensuite les fichiers de règlement et de commissions, que la couche d’intégration collecte et valide.
- 06
Rapprocher et comptabiliser
La couche d’intégration rapproche les transactions réglées des ventes d’origine et comptabilise les ventes, les commissions et les versements dans l’ERP.
En cas d’erreur
Pas de réponse dans le délai
Si la passerelle ne reçoit pas de réponse dans le délai fixé par l’acquéreur, elle envoie une annulation, sous la forme d’un message ISO 8583 0400 ou de son équivalent API, afin que le client ne soit jamais débité pour une vente qui n’a pas abouti.
Un paiement est refusé
Le code réponse parvient à la caisse ou à la page de paiement avec un message clair. Les taux de refus sont supervisés : une hausse soudaine révélant une panne technique déclenche une alerte.
Le règlement ne correspond pas
Un montant réglé différent de la vente, ou une vente sans règlement, est placé dans une liste de contrôle pour votre équipe des opérations de paiement, avec les deux enregistrements côte à côte.
Un porteur conteste un paiement
Le rapport de litiges de l’acquéreur est importé et rattaché à la vente et au règlement d’origine, afin que votre équipe puisse répondre avec l’ensemble des justificatifs au même endroit.
Standards et systèmes
- Standards et canaux bancaires
- SFTP (H2H)
- Paiements
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Intégration
- REST
- Webhooks
Questions et réponses
Quelle est la différence entre une passerelle et un acquéreur ?
L’acquéreur est la banque ou l’établissement agréé qui traite les paiements par carte pour votre compte et vous reverse les fonds. La passerelle est le service technique placé en amont, qui reçoit les demandes des terminaux et des pages de paiement, tokenise les cartes et les achemine. Certains prestataires assurent les deux rôles. L’architecture fonctionne dans les deux cas et maintient une séparation claire entre ces rôles.
Lien vers cette questionCette architecture tient-elle les données de carte à l’écart de nos systèmes ?
C’est l’objectif de l’architecture. Les numéros de carte sont saisis par le terminal certifié ou par une page de paiement hébergée, puis remplacés par des jetons au niveau de la passerelle : vos systèmes de caisse, votre ERP et vos bases de données ne voient jamais que des jetons. Cela réduit la partie de votre système d’information soumise à PCI DSS. Votre auditeur PCI DSS confirme le périmètre définitif.
Lien vers cette questionISO 8583 est-il identique pour chaque acquéreur ?
Non. ISO 8583 définit une structure, et chaque acquéreur ou réseau publie sa propre spécification des champs, des types de messages et des codes. C’est pourquoi nous développons à partir de la spécification de l’acquéreur et exécutons ses tests de certification. Une API de passerelle placée devant l’acquéreur masque ces différences, ce qui est souvent plus simple pour les commerçants.
Lien vers cette questionPourquoi le règlement arrive-t-il après la vente ?
L’autorisation ne fait que réserver les fonds. L’acquéreur règle par lots, après déduction de ses commissions et des éventuels frais de réseau, et procède aux versements selon son propre calendrier. C’est pourquoi l’architecture traite l’autorisation et le règlement comme des événements distincts et les rapproche, afin que la finance voie ce qui a été vendu, ce qui a été réglé et ce qui reste à recevoir.
Lien vers cette questionPrenez-vous en charge EMV 3-D Secure pour les paiements en ligne ?
Oui. Pour les paiements par carte en ligne, nous intégrons EMV 3-D Secure via la passerelle, afin que l’émetteur puisse authentifier le porteur lorsque la réglementation ou le niveau de risque l’exige. Nous gérons dans la page de paiement le parcours avec authentification (challenge) et le parcours sans friction (frictionless), et testons les deux avec les cartes de test du prestataire.
Lien vers cette questionPouvons-nous utiliser plusieurs prestataires de paiement ?
Oui. La couche d’intégration conserve un modèle interne unique du paiement et le fait correspondre à chaque prestataire : vous pouvez ainsi router par canal, par pays ou par type de carte, ou répartir les volumes entre prestataires. Chaque prestataire nécessite néanmoins sa propre intégration et sa propre certification, que nous planifions prestataire par prestataire.
Lien vers cette questionDites-nous ce que vous devez construire ou connecter.
Décrivez les systèmes, le calendrier et les contraintes. Les ingénieurs concernés prennent ensuite le relais.
- Notre équipe vous appellera dans les 24 heures, sur le créneau de votre choix
- Notre équipe est disponible 24 h/24, 7 j/7