Métadonnées et identifiants

Référence des identifiants de corrélation entre SI ministry, ERP, portail citoyen et Epayment.

Identifiants checkout ministry

Identifiant	Émetteur	Stabilité	Usage
`order_id`	SI ministry	Stable par obligation métier	Idempotence métier, webhook, GET session
`session_id`	Epayment	Une par tentative checkout (`chs_…`)	Webhooks, SDK embed, journal
`notice_id`	Epayment	UUID interne	Quittance, webhooks, lifecycle
`payment_ref`	Epayment	Code guichet citoyen	Agence, confirmation ERP `notice_ref`
`Idempotency-Key`	SI ministry	Par requête create	Retry HTTP sans double session (corps identique)

Règle : débloquer le dossier sur order_id connu + paid: true, pas sur session_id seul (nouvelle session possible après échec).

Identifiant	Format	Usage
`tenant_id`	UUID	Régie cible ; obligatoire avec clé plateforme
`application_id`	UUID	Application ministry ; présent dans webhooks
`service_code`	string ≤ 50	Catalogue régie ; webhook optionnel
`service_label`	string ≤ 200	Libellé affichage ; webhook optionnel

Champ metadata à la création : map clé-valeur string.

Contrainte	Valeur
Clés	≤ 64 caractères
Valeurs	≤ 500 caractères
Retour	Repris dans webhooks checkout

Exemple casier : { "tribunal": "Brazzaville", "dossier_ref": "DOS-2026-12" }.

Ne pas y stocker données de paiement (téléphone, canal) : Epayment choisit le connecteur.

Identifiant	Côté ERP	Côté Epayment
`subject_ref`	ID contribuable / bénéficiaire	Liaison citoyen-régie
`erp_due_ref`	Clé ligne créance	Panier, metadata checkout, confirmation
`revenue_line_code`	Code ligne budgétaire	Mapping → `service_code`
`batch_ref`	Référence lot ERP	Import batch disbursement
`line_ref`	Clé ligne payout	Traçabilité disbursement
`beneficiary_ref`	ID bénéficiaire ERP	Rapport batch

Identifiant	Type	Usage
`x-epayment-event-id`	UUID livraison	Idempotence réception webhook
`completion_token`	Token one-shot	Embed : preuve synchrone avant webhook
`client_secret`	Secret session	SDK ; format `{session_id}:{secret}`

Index payloads : payloads-index.