Architecture

Vue d'ensemble de la plateforme Epayment : couches logiques, puis flux d'intégration entre le SI métier, le checkout citoyen et les connecteurs de paiement.

Architecture en couches

Epayment orchestre les paiements sans détenir de fonds. Les canaux (L1) passent par une couche d'exposition (L2) vers les services cœur (L3), qui appellent des connecteurs interchangeables (L4). Les systèmes métier, prestataires et comptes de collecte restent hors plateforme (L5).

Architecture en couches

Architecture

L1Canaux

• Checkout hébergé
• Portail business
• Portail opérationnel
• Console d’administration
• API partenaires

L2Exposition

• Authentification
• Habilitations
• Lien de paiement sécurisé
• Webhooks entrants

L3Services cœur

• Avis et référence de paiement
• Sessions et cycle de vie
• Orchestration encaissement
• Lots de décaissement
• Validation hiérarchique
• Constatation et journal
• Preuves et reçus
• Notifications et rapports

L4Connecteurs

• Mobile moneyLivré
• Espèces en agenceLivré
• Banque BGFIEn cours
• GIMACPlanifié
• Carte acquéreurLivré

L5Hors plateforme

• Systèmes métier · ERP
• Prestataires et banques
• Comptes de collecte

Socle transverse

• Identité, rôles, MFA
• Isolation par organisation
• Journal d’audit et traçabilité
• Supervision et observabilité
• Environnements test et production

S’applique à toutes les couches.

Connecteurs interchangeables · disjoncteur, reprise sur échec, idempotence · aucun fonds ne traverse la plateforme.

Flux principaux

Collecte ministry (hosted ou embed)

Portail citoyen + ERP

Paiements en masse (disbursement)

Surfaces HTTP

Surface	Audience	Auth	Direction	Endpoints principaux
Ministry checkout	SI backend ministériel	sk_test_ / sk_live_	Intégrateur → Epayment	POST /checkout/sessions, GET /checkout/sessions, POST /checkout/sessions/verify-completion
Cash-in déprécié	Partenaires cash-in existants	apiKey + secretKey, puis Bearer oat_	Partenaire → Epayment	Mêmes chemins sous /api et /api/v1, jusqu'au 30 septembre 2027
Webhooks application	Endpoint HTTPS intégrateur	HMAC secret endpoint	Epayment → intégrateur	POST événements (checkout.completed, etc.)
ERP REST	SI régie (exposé par la régie)	API key, bearer, basic (config régie)	Epayment → ERP	GET /health, GET /dues, GET /disbursements, POST /payment-confirmations
Citizen API	Portail citoyen (BFF)	Session cookie citoyen	Portail → Epayment	GET /citizen/dues, checkout depuis panier
Checkout citoyen	Navigateur citoyen	client_secret (embed) ou session publique	Citoyen → Checkout	Pages /c/{session_id}, /embed/{session_id}
SDK embed	Navigateur ministry / eGouv	client_secret via backend	Frontend → Checkout	Script /sdk/v1.js, protocole postMessage

Règle de séparation

Surface	Audience HTTP	Auth
Ministry checkout	SI backend ministère	sk_test_ / sk_live_
Cash-in déprécié	Partenaires cash-in existants	apiKey + secretKey, puis oat_
Webhooks application	Endpoint HTTPS intégrateur	HMAC secret endpoint
ERP REST	Epayment appelle l'ERP de la régie	Config régie (API key, bearer, etc.)
Citizen API	Portail citoyen (BFF)	Session cookie citoyen

Chaque surface correspond à un contrat documenté dans les sections SI ministériel, ERP régie et eGouv. Les intégrateurs externes implémentent ou exposent uniquement les surfaces de leur périmètre.