Aller au contenu
XSIS
Parler à un ingénieur

Intégrations

Intégration des paiements et des points de vente

Paiements par carte et points de vente connectés de bout en bout, du terminal au grand livre

Intégrations ISO 8583 et passerelles de paiement, terminaux EMV, fichiers de règlement des acquéreurs et synchronisation des ventes et des stocks entre POS et ERP.

Présentation

Un paiement par carte sollicite plusieurs systèmes en quelques secondes : le terminal ou la page de paiement, une passerelle de paiement, l’acquéreur, le réseau de cartes et l’émetteur. Le lendemain, les fonds et les commissions arrivent dans des fichiers de règlement que quelqu’un doit rapprocher des ventes enregistrées dans votre ERP. Une vente en magasin modifie aussi les stocks, les prix et la comptabilité. Lorsque ces systèmes divergent, la finance traque les écarts à la main.

Nous intégrons les terminaux EMV et les paiements en ligne aux passerelles de paiement et aux acquéreurs, en ISO 8583 lorsque l’acquéreur le parle et via l’API de la passerelle sinon. Nous traitons les fichiers de règlement et de commissions, et relions les systèmes de caisse à votre ERP afin que les ventes, les retours, les stocks et les prix restent alignés dans chaque magasin.

Nous concevons les flux pour tenir les données de carte à l’écart de vos systèmes chaque fois que c’est possible, grâce à la tokenisation et aux pages de paiement hébergées, ce qui réduit la part de votre système d’information soumise à PCI DSS. Chaque flux est testé dans l’environnement de test du prestataire, piloté dans un petit nombre de magasins et supervisé une fois en service.

Ce que nous livrons

  1. Cartographie des paiements et des points de vente

    Chaque type de terminal, page de paiement, passerelle, acquéreur et système de caisse du périmètre, avec les formats et le cycle de règlement de chacun.

  2. Intégration de la passerelle et de l’acquéreur

    Les flux d’autorisation, de capture, de remboursement et d’annulation, en ISO 8583 ou via l’API du prestataire, avec le traitement de chaque code réponse.

  3. Intégration des terminaux

    Des terminaux EMV à puce et sans contact connectés à votre logiciel de caisse ou de borne, selon le protocole terminal du prestataire.

  4. Tokenisation et périmètre PCI DSS

    Une conception qui remplace les numéros de carte par des jetons, et un état écrit des systèmes qui restent dans le périmètre PCI DSS.

  5. Traitement des fichiers de règlement

    Les fichiers de règlement et de commissions des acquéreurs collectés, validés et transformés en écritures que votre ERP peut rapprocher.

  6. Synchronisation POS vers ERP

    Les ventes, retours, annulations et totaux de fin de journée de chaque magasin comptabilisés dans l’ERP, une fois et une seule.

  7. Prix, promotions et articles

    Les données articles, les prix et les promotions envoyés de l’ERP vers les points de vente, pour que chaque caisse vende au bon prix.

  8. Rapprochement des paiements

    Le rapprochement des ventes, des autorisations, des règlements et des versements, avec la liste des écarts que votre équipe doit traiter.

  9. Accompagnement aux tests et à la certification

    Des scripts de test et des preuves pour la certification de la passerelle ou de l’acquéreur, et un accompagnement à chaque cycle de certification.

  10. Supervision et alertes

    Des alertes en cas de variation du taux de refus, de fichier de règlement manquant, de magasin qui ne transmet plus ses ventes ou de terminal devenu silencieux.

Notre méthode

  1. 01

    Cartographier les flux de paiement et de magasin

    Nous suivons une vente de la caisse au grand livre avec vos équipes finance, magasins et informatique, et convenons du périmètre.

  2. 02

    Concevoir l’intégration

    Nous choisissons les protocoles, l’approche de tokenisation et les flux de messages, et rédigeons la spécification d’interface.

  3. 03

    Développer et tester

    Nous développons les flux de paiement, de règlement et de caisse avec des tests automatisés, y compris pour les refus, les expirations de délai et les remboursements.

  4. 04

    Certifier avec le prestataire

    Nous déroulons les cas de test du prestataire dans son environnement de test et corrigeons ce que sa certification relève.

  5. 05

    Piloter, puis déployer

    Nous démarrons dans quelques magasins ou canaux, comparons les totaux chaque jour, puis déployons magasin par magasin.

  6. 06

    Superviser et assister

    Nous suivons les taux d’autorisation, les règlements et les remontées des magasins, et prenons en charge les évolutions des prestataires dès leur annonce.

Comment tout se connecte

Paiements par carte : autorisés en caisse, réglés ensuite, rapprochés dans l’ERPLe 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.POSTerminal EMV oupaiement en lignePuce, sans contact ete-commercePasserellePasserelle depaiementTokenisation etroutageBanqueAcquéreurAutorisation etrèglementTiersRéseau de carteset émetteurAccepte ou refuseERPERPVentes, frais etreversementsXSISCouched’intégrationLecture etrapprochement desrèglementsPersonnesÉquipe desopérations depaiementÉcarts, litiges etrétrofacturations1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

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

  1. Source Terminal EMV ou paiement en ligne, destination Passerelle de paiement : Demande d’autorisation, via EMV · REST/JSON (flux principal).
  2. Source Passerelle de paiement, destination Acquéreur : Autorisation, via ISO 8583 (flux principal).
  3. Source Acquéreur, destination Réseau de cartes et émetteur : Acheminée vers l’émetteur, via ISO 8583 (flux principal).
  4. Source Acquéreur, destination Passerelle de paiement : Acceptée ou refusée, via ISO 8583 (asynchrone).
  5. Source Acquéreur, destination Couche d’intégration : Fichiers de règlement et de frais, via SFTP (asynchrone).
  6. Source Couche d’intégration, destination ERP : Ventes réglées, frais et reversements, via REST/JSON (flux principal).
  7. 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).
  8. Source Couche d’intégration, destination Équipe des opérations de paiement : Écart de règlement ou rétrofacturation (chemin d’exception).
Du POS à l’ERP : chaque vente comptabilisée une seule foisLes ventes remontent des caisses vers l’ERP sous forme d’événements ; les prix et les stocks redescendent. Un magasin hors ligne continue de vendre puis se resynchronise. Une comptabilisation en échec est relancée, puis confiée à une personne.POSTerminaux de pointde venteChaque caisse dechaque magasinStockageServeur magasinou cloud POSContinue de vendrehors ligneXSISCouched’intégrationFile d’événements,mapping, protectioncontre les doublonsERPERPVentes, stocks etfinanceServiceFile de nouvellestentativesNouvelles tentativesespacées, puis filedes messages enéchecPersonnesÉquipe desopérationsmagasins12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

Du POS à l’ERP : chaque vente comptabilisée une seule fois

Les ventes remontent des caisses vers l’ERP sous forme d’événements ; les prix et les stocks redescendent. Un magasin hors ligne continue de vendre puis se resynchronise. Une comptabilisation en échec est relancée, puis confiée à une personne.

  • Flux principal
  • Asynchrone
  • Chemin d’exception

Le flux, étape par étape

  1. Source Terminaux de point de vente, destination Serveur magasin ou cloud POS : Ventes, retours et annulations (flux principal).
  2. Source Serveur magasin ou cloud POS, destination Couche d’intégration : Événements de vente et totaux de fin de journée, via une file d’événements, via REST/JSON (asynchrone).
  3. Source Couche d’intégration, destination ERP : Ventes et mouvements de stock comptabilisés, via OData · REST/JSON (flux principal).
  4. Source ERP, destination Couche d’intégration : Prix, promotions et données articles, par API ou export de fichiers, via REST/JSON (flux principal).
  5. Source Couche d’intégration, destination Serveur magasin ou cloud POS : Mises à jour des prix et des stocks, via REST/JSON (flux principal).
  6. Source Couche d’intégration, destination File de nouvelles tentatives : Échec de comptabilisation (chemin d’exception).
  7. Source File de nouvelles tentatives, destination Couche d’intégration : Relancé (chemin d’exception).
  8. Source File de nouvelles tentatives, destination Équipe des opérations magasins : Échec persistant : alerte avec le détail (chemin d’exception).

Technologies

Langages
  • Java
  • Kotlin
Données et analytique
  • Apache Kafka
Systèmes ERP
  • SAP S/4HANA
  • Oracle NetSuite
  • Microsoft Dynamics 365 Business Central
  • Odoo
Standards et canaux bancaires
  • SFTP (H2H)
Paiements
  • ISO 8583
  • EMV
  • EMV 3-D Secure
  • PCI DSS
Intégration
  • REST
  • Webhooks
  • RabbitMQ

Modes de collaboration

Questions et réponses

Travaillez-vous directement en ISO 8583 ?

Oui, lorsque l’acquéreur ou le processeur le propose. ISO 8583 est un cadre plutôt qu’un format unique : chaque acquéreur publie sa propre spécification des champs, des types de messages et de la gestion réseau. Nous développons à partir de cette spécification, traitons les autorisations, les annulations et les messages de notification (advice), et testons chaque code réponse. Lorsqu’une passerelle propose une API moderne devant l’acquéreur, nous recommandons souvent cette solution.

Lien vers cette question
Comment nous maintenez-vous hors du périmètre PCI DSS ?

Nous ne pouvons pas supprimer PCI DSS, mais nous pouvons réduire la part de votre système d’information concernée. Nous utilisons des pages de paiement hébergées, le chiffrement point à point au niveau du terminal et des jetons fournis par la passerelle, afin que les numéros de carte n’atteignent jamais vos caisses, votre ERP ou votre entrepôt de données. Nous documentons les flux de données pour que votre évaluateur puisse voir quels systèmes traitent des données de carte et lesquels n’en traitent pas.

Lien vers cette question
Quels terminaux de paiement pouvez-vous intégrer ?

Nous intégrons les terminaux EMV à puce et sans contact via le protocole fourni par leur prestataire, généralement une API locale ou cloud entre la caisse et le terminal. Le terminal et son application de paiement sont certifiés par le prestataire : nous nous y intégrons donc sans les modifier. Nous confirmons avec vous et le prestataire, dès le départ, les modèles et protocoles exacts.

Lien vers cette question
Que se passe-t-il lorsqu’un magasin perd sa connexion ?

Le magasin continue de vendre. Les ventes sont stockées localement sur la caisse ou le serveur du magasin, puis envoyées à l’ERP au retour de la connexion, chacune avec un identifiant unique afin que rien ne soit comptabilisé deux fois. La possibilité de poursuivre les paiements par carte hors ligne dépend des règles de votre acquéreur et de votre appétence au risque ; nous la concevons avec vous.

Lien vers cette question
Combien de temps dure une certification de paiement ?

La durée dépend largement de la passerelle ou de l’acquéreur : leurs fenêtres de test, le nombre de cas de test et le nombre de cycles nécessaires. Nous préparons les scripts de test et les preuves avant l’ouverture de la fenêtre, ce qui raccourcit les cycles, et nous organisons le reste des travaux autour du calendrier du prestataire. Nous partageons ce plan dès que le prestataire a confirmé sa procédure.

Lien vers cette question
Qu’est-ce qui détermine le coût ?

Le nombre de prestataires, de types de terminaux et de canaux de vente, l’usage d’ISO 8583 ou d’une API par l’acquéreur, les étapes de certification exigées par chaque prestataire et le nombre de magasins à déployer. Les règles de règlement et de rapprochement demandent un effort supplémentaire lorsque les commissions et les versements sont complexes. Nous chiffrons par prestataire et par flux après l’étape de cartographie.

Lien vers cette question
Prenez-vous en charge les remboursements et les rétrofacturations ?

Oui. Les remboursements et les annulations font partie des flux de paiement que nous développons. Pour les rétrofacturations, nous importons les rapports de litiges de l’acquéreur, rattachons chacun à la vente et au règlement d’origine, et remettons à votre équipe une liste à traiter, preuves jointes. La réponse apportée à chaque litige reste votre décision.

Lien vers cette question
À qui appartiennent le code et les travaux que vous produisez ?

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela couvre le code spécifique, la documentation et les autres livrables réalisés pour vous. Les éléments préexistants que nous apportons, tels que des outils internes ou des bibliothèques, restent notre propriété, et vous recevez une licence pour les utiliser dans vos systèmes. Les composants open source conservent leurs propres licences, et nous vous en fournissons la liste.

Lien vers cette question

Dites-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