Mercanta / Confiance / Sécurité

La sécurité comme surface réduite.

Les numéros de carte n'atteignent jamais les serveurs Mercanta — ils vont directement à Stripe via Stripe Elements. Ce choix architectural unique nous maintient hors du périmètre PCI-DSS Niveau 1 et réduit drastiquement ce qu'un attaquant pourrait nous dérober. Le reste de cette page décrit ce que nous faisons pour tout le reste. Mercanta n'est pas une institution de paiement régulée. Tous les paiements, payouts et fonctions merchant-of-record sont assurés par Stripe, Inc.

Dernière mise à jour · 17 mai 2026 Signaler une vulnérabilité · contact@mercanta.io
01 / Architecture

Ce que nous ne touchons jamais.

Numéros de carte (PAN)

Stripe Elements uniquement

Les clients saisissent leurs détails carte dans des iframes servies directement par Stripe (js.stripe.com). Les données vont vers l'environnement PCI-DSS Niveau 1 de Stripe sans transiter par nos serveurs. Nous ne recevons que la référence PaymentMethod tokenisée par Stripe.

CVV / CVC

Jamais stocké, nulle part

Conformément aux règles PCI, personne ne stocke le CVV. Nous ne le voyons pas, Stripe ne le stocke pas. Il est utilisé une seule fois à l'autorisation puis détruit.

Coordonnées bancaires

Stripe / Plaid uniquement

Les coordonnées de virement SEPA et ACH sont collectées via Stripe Financial Connections (Plaid sous-jacent) et stockées chez Stripe.

Fonds

Stripe détient le solde

Mercanta ne détient à aucun moment les fonds clients. Stripe vous verse directement sur votre compte bancaire selon le calendrier de payout que vous configurez. Tous les paiements, payouts et fonctions merchant-of-record sont assurés par Stripe, Inc.

02 / Chiffrement

En transit et au repos.

En transit

TLS 1.3 · forcé

HTTPS-only sur tous les sous-domaines. HSTS avec includeSubDomains et preload. Cible SSL Labs A+ sur tous les endpoints publics.

Au repos

AES-256 · AWS KMS

Toutes les bases de données et stockage objet sont chiffrés au repos avec des clés AWS-managées (KMS). Les snapshots de sauvegarde héritent de la même politique de clé.

Secrets

AWS Secrets Manager

Clés d'API, secrets de signature et identifiants de base de données résident dans AWS Secrets Manager avec rotation automatisée. Aucun secret dans le code source. Hooks pré-commit pour scanner les fuites.

Signatures webhook

HMAC-SHA256

Chaque webhook sortant est signé avec un secret propre au marchand. Protection contre le replay via tolérance temporelle. Vérification de signature à temps constant dans tous nos SDKs.

03 / Contrôles d'accès

Moindre privilège, toujours.

Pour les employés

SSO + MFA hardware

Chaque membre de Mercanta s'authentifie via Google Workspace SSO avec une clé de sécurité hardware (FIDO2 / YubiKey). L'accès production est basé sur les rôles, just-in-time, et tracé en audit.

Pour les marchands

TOTP & passkeys

Les utilisateurs du dashboard peuvent (et devront, sur Maison et Sur-mesure) activer le MFA TOTP ou les passkeys WebAuthn. Les codes de récupération sont générés et affichés une seule fois.

Clés API

Restreintes, rotables

Clés API restreintes avec permissions au niveau ressource. Clés séparées par environnement (test / production). Rotation en un clic ; révocation immédiate.

Journaux d'audit

Chaque action, traçable

Chaque appel API, chaque action dashboard, chaque accès employé aux données production est logué avec acteur, IP et timestamp. Journaux immuables, conservés au minimum 1 an.

04 / Pratiques

Comment nous construisons et répondons.

SDLC

Revue de code & CI

Revue par les pairs obligatoire sur chaque PR. SAST et scan de vulnérabilités sur les dépendances à chaque commit. Prévention des fuites de secrets dans les hooks pré-commit. Les déploiements production sont conditionnés à un build vert.

Tests

Pen-test annuel

Test d'intrusion annuel par un tiers, planifié pour commencer dans les 90 jours suivant la disponibilité générale. Les résultats sont publiés dans notre rapport de sécurité aux clients Sur-mesure sous NDA.

Monitoring

Alertes 24/7

WAF, détection d'anomalies sur le trafic API, alertes sur les activités dashboard suspectes. Rotation PagerDuty pour les événements de sévérité élevée.

Réponse à incident

Runbook documenté

Si un incident de sécurité affecte des données marchand, nous notifions les clients concernés sans retard injustifié (sous 72h lorsque le RGPD s'applique). Un post-mortem est rédigé pour chaque incident Sév-1.

05 / Divulgation de vulnérabilités

Vous avez trouvé quelque chose ?

Nous accueillons et encourageons la recherche de sécurité responsable. Si vous avez découvert une vulnérabilité dans Mercanta, signalez-la à contact@mercanta.io avec autant de détails que possible : endpoint affecté, étapes de reproduction, impact, et votre correctif suggéré le cas échéant.

Ce que nous vous demandons :

  • Ne pas accéder, modifier ou détruire des données appartenant à d'autres utilisateurs.
  • Ne pas effectuer de tests de déni de service.
  • Utiliser les comptes en mode test pour vos preuves de concept.
  • Nous laisser 90 jours pour remédier avant toute divulgation publique.

Ce que nous nous engageons à faire :

  • Accuser réception de votre rapport sous 2 jours ouvrés.
  • Enquêter, communiquer les progrès, et vous créditer dans un hall of fame public si vous le souhaitez.
  • Une fois la phase pré-lancement terminée, verser des récompenses pour les découvertes qualifiantes dans un périmètre documenté.

Contact sécurité

contact@mercanta.io
Clé PGP disponible sur demande.

Pour les sujets non-sécurité, utilisez plutôt notre formulaire de contact.