Conception d'un moteur de paiement de production (Conception Dun Moteur DE Paiement DE Production)

Cette série a commencé avec l'abstraction du fournisseur et s'est poursuivie avec la fiabilité des webhooks, l'idempotence, la saga, le bail, le consensus, l'observabilité, le pipeline de récupération et le traitement efficace une fois. Cette dernière section technique est la synthèse de ce parcours : si vous concevez un moteur de paiement qui fonctionne en production, quelles décisions devez-vous prendre et dans quel ordre ?

La liste de contrôle n'est pas une liste de fonctionnalités. Chaque élément est un test mesurable d'un principe préconisé dans une ou plusieurs parties de la série. Ce n'est pas « Y a-t-il une idempotence ? » La question est : « L'API de clé d'idempotence, la dédup de webhook et le trio d'unicité de base de données fonctionnent-ils ensemble ? »```text Production Payment Engine ├─ Boundaries (orchestrator ↔ gateway) ├─ State & Evidence ├─ Reliability (retry, lease, outbox) ├─ Recovery (reconciliation, runbooks) └─ Observability (payment id, step log, metrics)

## Concepts à la première mention```text
📦 Checkout Orchestrator
Ödeme niyetini yöneten, semantik sonuç gören, PSP detayı bilmeyen servis.

📦 Provider Gateway
PSP SDK'sını, webhook çevirisini ve provider'a özgü akışları sahiplenen servis.

📦 Production Readiness
Sistemin sadece happy path'te değil, arıza, yarış ve sürüklenme anlarında da doğru davranması.

📦 Architectural Checklist
Tasarım kararlarının ölçülebilir, evet/hayır testlerine dönüştürülmüş hali.
```Le moteur de paiement de production ne signifie pas que « l'API de facturation fonctionne » ; Il s'agit de répondre à la question « Que se passe-t-il lorsque la charge échoue, que le webhook arrive en retard, que le travailleur plante ? »

## 1. Limites : aucune fuite du SDK

- [ ] L'orchestrateur Checkout n'importe-t-il aucun type de SDK PSP ?
- [ ] Orchestrator ne voit-il que la sémantique `ChargeRequest` / `ChargeResult` ?
- [ ] Le webhook atteint-il l'aval en tant que charge utile brute du fournisseur ou en tant qu'événement sémantique ?
- [ ] La passerelle du fournisseur est-elle l'unique propriétaire de la table de mappage d'événements du fournisseur → table de mappage d'événements sémantiques ?
- [ ] L'ajout d'une nouvelle PSP ne nécessite-t-il aucune ligne de modification du code de l'orchestrateur ?

Cet épisode est l'épisode 9-10 de la série. est l'essence de ses parties. Si la limite est franchie, chaque couche restante est construite au-dessus de cette fuite.

## 2. État et preuve : état ≠ preuve

- [ ] La machine d'état de paiement est-elle clairement définie (Traitement, FinalizePending, Capturé, Échec, Expiré) ?
- [ ] Les statuts terminaux sont-ils irréversibles ?
- [ ] L'instantané du paiement (montant, devise, panier) est-il immuable ?
- [ ] Les preuves (webhook, réponse de synchronisation) de PSP sont-elles stockées dans un tableau de preuves séparé ?
- [ ] Les transitions d'état sont-elles basées sur des preuves ou des hypothèses ?

## 3. Fiabilité : nouvelle tentative, location, boîte d'envoi

- [ ] La taxonomie des erreurs est-elle définie (BusinessDecline, Timeout, RateLimited, Infrastructure) ?
- [ ] Une politique de nouvelle tentative différente est-elle appliquée pour chaque catégorie ?
- [ ] Les tâches basées sur la base de données sont-elles traitées dans le cadre d'un bail ?
-[ ] Le gestionnaire de webhook utilise-t-il ensemble le bail et le jeton de version ?
- [ ] L'événement se trouve-t-il dans la même transaction que le modèle de boîte d'envoi avec le changement d'état ?
- [ ] Le trio API de clé d'idempotence, déduplication du consommateur et unicité de la base de données est-il réuni ?

## 4. Récupération : automatisation avant, runbook après

- [ ] Le balayeur de réconciliation vieillit-il les enregistrements d'analyse FinalizePending / Expired ?
- [ ] Le scénario de charge orpheline peut-il être résolu avec l'identifiant de corrélation ?
- [ ] Existe-t-il un verrouillage du chariot pour les chariots multi-intentions ?
- [ ] Le manuel du mur Uniqueness écrit-il dans la file d'attente de révision ?- [ ] Le runbook est-il basé sur des preuves (journal des étapes + requête PSP + audit) ?
- [ ] La décision de guérison/remboursement est-elle une procédure et non un réflexe ?

## 5. Observabilité : colonne vertébrale de l'identification du paiement

- [ ] Chaque journal, trace et métrique comporte-t-il un identifiant de paiement ?
- [ ] Le journal des événements d'étape est-il uniquement en annexe et couvre-t-il chaque étape significative ?
- [ ] Les métriques `deferred_finalize_count` et `deferred_finalize_age_seconds` sont-elles définies ?
- [ ] Le nombre de dérives génère-t-il une alerte lorsqu'il augmente soudainement ?
- [ ] Est-il possible de suivre le chemin complet depuis la caisse jusqu'à l'état du terminal avec un identifiant de paiement ?

## 6. Modèle de cohérence : éventuel, modéré, observable

- [ ] Le modèle saga + réconciliation a-t-il été choisi consciemment au lieu du 2PC ?
- [ ] L'action de compensation de chaque étape de la saga est-elle définie ?
- [ ] L'éventuelle fenêtre de cohérence est-elle mesurée et partagée avec l'équipe produit ?
- [ ] L'objectif d'une « cohérence à court terme » est-il plutôt l'illusion d'une « cohérence à tout moment » ?```text
Checklist tamamlandığında sorulacak son soru:
  'Bu sistemin en kötü gününde ne olur?'
  → Cevap runbook'ta, metriklerde ve reconciliation'da yazılı olmalı.

Distinctions souvent confuses```text

❌ Checklist = feature tamamlandı demek ✓ Checklist = mimari ilkenin ölçülebilir testi

❌ Production ready = load test geçti ✓ Production ready = arıza anında doğru davranış kanıtlandı

❌ Daha fazla PSP = daha fazla karmaşıklık ✓ İyi sınırlar varsa, yeni PSP yalnızca gateway'i etkiler

| Rubrique | Épisodes de séries | Question fondamentale |
| --- | --- | --- |
| Frontières | 9-10 | Orchestrator connaît-il la PSP ? |
| Situation et preuves | 1-4, 6 | Est-ce basé sur des preuves d’État ? |
| Fiabilité | 5, 7-8, 11, 17, 20 | Que se passe-t-il en cas de dysfonctionnement ? |
| Récupération | 12-16, 19 | Comment capter la dérive ? |
| Observabilité | 18 | Le paiement bloqué est-il visible ? |
| Cohérence | 3, 16 | 2PC ou Saga ? |

## Évaluation de l'état de préparation à la production

1. Parcourez les six sections de la liste de contrôle une par une lors d'une revue de conception ; Répondez oui/non/partiellement pour chaque élément.
2. Ajoutez les réponses « Partiellement » à la liste des dettes techniques ; Établissez des priorités en fonction de l’impact commercial.
3. Exécutez le pire scénario (PSP 5xx, décalage du webhook, crash du travailleur, charge orpheline) sous forme d'exercice sur table.
4. Notez quels éléments de la liste de contrôle restent vides pendant l'exercice : ce sont les objectifs d'amélioration initiaux.
5. Conservez la liste de contrôle comme un document évolutif ; Mettre à jour l'article concerné après chaque incident de production.

## Ce qu'il faut retenir de cette série

1. Le moteur de paiement de la production est mesuré par le comportement d'échec et non par le cheminement heureux.
2. La liste de contrôle est une synthèse mesurable des 22 épisodes de la série – et non une liste de fonctionnalités.
3. Si les limites (orchestre ↔ passerelle) sont brisées, tout le reste est construit sur cette fuite.
4. La réponse à la question du pire jour doit être écrite dans le runbook, les métriques et le rapprochement.

> Concevoir un moteur de paiement de production ne consiste pas à « écrire une API de facturation » ; il s'agit plutôt de combler l'écart entre la capture et l'intégralité contrôlée, observable et récupérable.

Dans le dernier épisode, nous abordons la série dans une perspective de carrière : que recherchent réellement les entreprises de technologie financière ?