Une infrastructure de paiement vit et meurt sur sa posture de sécurité. Voici exactement ce qu'on fait, ce qu'on ne fait pas, et ce qu'on ne prétendra pas encore avoir.
1. Non-custodial par design
La garantie de sécurité la plus forte qu'on offre est architecturale : on ne détient pas les fonds des marchands. Jamais. Quand un client paie par carte, l'on-ramp convertit le fiat en USDC et notre splitter on-chain route atomiquement vers ton wallet Polygon dans la même transaction. Nos serveurs voient un événement, pas un solde. Il n'y a pas de hot wallet, pas de trésorerie poolée, pas de compte omnibus — donc pas de honeypot à casser pour un attaquant. Si Peptide-Pay disparaissait demain, tes paiements passés seraient toujours on-chain dans ton wallet.
2. Infrastructure
Hosting : Vercel, avec réseau edge global et protection DDoS.
Stockage d'état : Upstash Redis avec TLS en transit et AES-256 au repos.
Settlement : Polygon mainnet, vérifié on-chain — mêmes hypothèses de sécurité que la chaîne elle-même.
DNS & CDN : durci avec HSTS preload, records CAA épinglant l'AC, DNSSEC activé.
Secrets : stockés dans le env store chiffré de Vercel ; rotés au départ d'un employé.
3. Authentification
Email + mot de passe + wallet pour le dashboard. Les mots de passe sont hashés en scrypt (N=32768, r=8, p=1) — jamais stockés en clair, jamais loggés.
Le mode wallet-only anonyme est aussi supporté : colle ton adresse, génère un payment link, aucun email requis.
Les sessions dashboard sont courtes (7 jours) et liées au navigateur qui s'est connecté.
Les cookies de session sont HTTP-only, Secure, SameSite=Lax.
Les connexions suspectes (nouveau pays, nouvel ASN) déclenchent une alerte email et peuvent être révoquées depuis n'importe quelle session active.
4. Webhooks
Chaque webhook est signé en HMAC-SHA256 avec le secret de ton compte ; vérifie avant de faire confiance au payload.
Le header de signature inclut un timestamp ; rejette tout ce qui a plus de 5 minutes pour éviter les replays.
Queue de retry avec backoff exponentiel (30 s, 2 m, 10 m, 30 m, 1h, 3h, 12h, 24h) puis drop.
Les webhooks droppés restent rejouables depuis le dashboard pendant 30 jours.
On publie la plage d'IP d'egress courante pour que tu puisses nous allowlister au firewall.
5. Clés API
Les clés sont affichées une seule fois, stockées hashées (bcrypt) côté serveur ; on ne peut pas te les retrouver.
Rotatables à tout moment depuis /app/settings — ancienne et nouvelle clé fonctionnent en parallèle pendant 24 heures pour déployer sans downtime.
Les clés scopées sont prévues pour Q3 2026 ; pour l'instant les clés sont full-access.
Rate-limit par clé : 100 requêtes/seconde soft, 1000/seconde hard.
6. Chiffrement
En transit : TLS 1.3 sur chaque endpoint ; TLS 1.2 permis uniquement pour les consommateurs webhook legacy, flagué pour dépréciation.
Au repos : AES-256 sur Upstash Redis et Vercel blob storage.
Les emails clients sont hashés (SHA-256 avec sel par marchand) avant de finir dans les logs serveur ; seul le dashboard marchand les rend en clair.