Intégrations et secteurs

Chaque intégration utilise son propre compte technique, doté des seules autorisations nécessaires à ses flux, jamais l’identifiant d’une personne. Les secrets d’accès sont conservés dans votre coffre-fort de secrets, pas dans le code. Nos ingénieurs travaillent, dans la mesure du possible, sur des systèmes de test avec des données masquées ou fictives ; leurs accès sont nominatifs, journalisés et supprimés lorsqu’ils quittent le projet.

En savoir plus : Intégration ERPLien vers cette question

Les fichiers de paiement sont signés et chiffrés selon les exigences de chaque banque, par exemple avec OpenPGP, et ne transitent que par le canal convenu. Les clés et les certificats sont conservés dans votre coffre-fort de clés ou votre module de sécurité matériel (HSM), jamais dans le code, et seules des personnes nommément désignées peuvent y accéder. Les fichiers sont contrôlés avant leur envoi et chaque transfert est journalisé, ce qui vous permet de retrouver qui a validé et envoyé chaque paiement.

En savoir plus : Intégration bancaireLien vers cette question

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.

En savoir plus : Intégration des paiements et des points de venteLien vers cette question

Oui. Nous mettons en place l’authentification unique avec OpenID Connect ou SAML 2.0 via des fournisseurs comme Microsoft Entra ID ou Keycloak, et provisionnons automatiquement les utilisateurs avec SCIM lorsque l’application le permet. Les services s’appellent entre eux avec des jetons OAuth 2.0 limités à ce dont chacun a besoin. Votre fournisseur d’identité reste le seul endroit où les accès sont accordés et retirés.

En savoir plus : Intégration d’API et de services tiersLien vers cette question

Oui. Nous travaillons dans le cadre de vos politiques : vos règles d’accès, vos environnements, votre processus de gestion des changements et vos exigences d’audit. Avant le début des travaux, nous convenons du traitement des données, des environnements accessibles aux ingénieurs et des preuves attendues par vos équipes risques et conformité. Nous décrivons clairement les contrôles que nous appliquons, afin que vos évaluateurs puissent les examiner.

En savoir plus : Fintech et services financiersLien vers cette question

Nous concevons les systèmes de sorte que le moins possible d’entre eux voient un numéro de carte complet. Les champs de paiement hébergés, la tokenisation et les jetons réseau laissent les données de carte chez le processeur, ce qui réduit votre périmètre PCI DSS. Lorsqu’un système doit traiter des données de carte, nous le construisons selon les contrôles PCI DSS applicables et les documentons pour votre évaluateur.

En savoir plus : Fintech et services financiersLien vers cette question

Nous ne collectons que les données dont une fonctionnalité a besoin, les conservons dans la région et l’environnement de votre choix, et les chiffrons en transit et au repos. L’accès suit les rôles et il est journalisé. Nos ingénieurs travaillent avec des données synthétiques ou anonymisées chaque fois que possible, et avec des données réelles uniquement avec votre accord et sous votre supervision.

En savoir plus : SantéLien vers cette question

La conformité relève de votre organisation et de la façon dont elle exploite un système : aucun fournisseur de logiciel ne peut à lui seul vous rendre conforme. Ce que nous faisons, c’est concevoir et développer selon les exigences applicables, documenter les mesures de contrôle et accompagner vos équipes confidentialité et sécurité dans leurs évaluations.

En savoir plus : SantéLien vers cette question

Là où vos règles le prévoient. Nous travaillons avec des régions de cloud de l’État ou de cloud souverain, des clouds commerciaux agréés ou vos propres centres de données, et nous concevons le système pour que la décision d’hébergement vous revienne. Les sauvegardes, les journaux et les accès du support suivent la même règle, car c’est souvent par eux, plutôt que par l’application, que les données quittent une région.

En savoir plus : Secteur publicLien vers cette question

Oui. La validation reste dans votre ERP, avec ses contrôles existants. La couche d’intégration journalise chaque fichier qu’elle crée, signe, envoie et reçoit, avec l’horodatage, les identifiants et le compte technique utilisé. Ce journal relie chaque paiement figurant dans le compte rendu de statut de la banque à la pièce de l’ERP et à ses valideurs.

En savoir plus : ERP et banquesLien vers cette question

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.

En savoir plus : Paiements par carteLien vers cette question

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.

En savoir plus : Paiements par carteLien vers cette question

Le client voit quelles données sont partagées, dans quel but et pour quelle durée, et s’authentifie auprès de sa propre banque. Le connecteur conserve le consentement et ses jetons sous forme chiffrée, et chaque appel est rattaché à un consentement valide. Les clients peuvent retirer leur consentement ; le connecteur cesse alors d’appeler la banque concernée pour leur compte.

En savoir plus : API d’open bankingLien vers cette question

Les jetons et les enregistrements de consentement sont chiffrés au repos, seul le connecteur peut les utiliser, et chaque appel est journalisé avec le consentement qui le fonde. Nous ne collectons que les données nécessaires à la finalité et fixons leur durée de conservation. Ces données sont soumises aux règles de protection des données telles que le RGPD, et nous concevons l’architecture avec votre délégué à la protection des données (DPO).

En savoir plus : API d’open bankingLien vers cette question

Chaque webhook entrant est vérifié avant d’être traité : par signature lorsque le partenaire signe ses messages, et par contrôle du jeton, de la source et de l’horodatage dans le cas contraire. Le contenu est validé au regard du contrat d’interface, et chaque événement n’est traité qu’une seule fois, même si le partenaire l’envoie plusieurs fois.

En savoir plus : ERP et services tiersLien vers cette question