Pipeline et Runbook de récupération des paiements (Pipeline Et Runbook DE Recuperation Des Paiements)

Dans la section précédente, nous avons vu comment la corrélation avec l'identifiant de paiement, le journal des événements d'étape et les métriques de finalisation différée alimentent l'opération. Cette section examine le processus de récupération qui s'appuie sur cette visibilité : que peut faire le système en premier lorsqu'un paiement est bloqué, et quand l'humain intervient-il ?

Le principe d'un bon pipeline de récupération est simple : l'automatisation d'abord. Travailleur de réconciliation, observateur bloqué, travailleur de nouvelle tentative – ceux-ci éliminent la plupart des dérives sans nécessiter d’intervention humaine. Les runbooks humains n’entrent en jeu que lorsque l’automatisation se heurte à des murs d’unicité ou de preuves ambiguës.```text Ödeme takıldı → otomatik: reconciliation scan → otomatik: retry with backoff → otomatik: PSP status query → insan: uniqueness wall / ambiguous evidence

## Concepts à la première mention```text
📦 Recovery Pipeline
Takılan veya tutarsız ödemeleri otomatik olarak teşhis edip düzeltmeye çalışan ardışık işlem hattı.

📦 Uniqueness Wall
Veritabanı benzersizlik kısıtının, güvenli replay veya heal girişimini engellediği durum.

📦 Evidence-Driven Runbook
Her adımın hangi kanıta (step log, PSP sorgusu, audit) dayandığını tanımlayan operasyon kılavuzu.

📦 Manual Review Queue
Otomasyonun çözemediği kayıtların biriktiği, görünür bekleme alanı.
```Runbook répond à la question « que faire » ; Le runbook fondé sur des preuves répond à la question « Que ne peut-on faire sans preuves ? »

## Avant l'automatisation : couches de pipeline de récupération

Le pipeline de récupération n’est pas constitué d’un seul travailleur, mais de couches qui se complètent. Chaque couche répond à ce que la précédente n’a pas pu résoudre ; Ni l’un ni l’autre ne devrait tenter de faire le travail du suivant.```text
Katman 1: Retry worker
  → transient hataları backoff ile tekrar dener

Katman 2: Stuck watcher
  → lease süresi dolmuş, Processing'de kalan kayıtları sıfırlar

Katman 3: Reconciliation sweeper
  → aged FinalizePending / Expired kayıtları PSP ile karşılaştırır

Katman 4: Manual review queue
  → otomasyonun çözemediği kayıtlar
```Les niveaux 1 à 3 sont entièrement automatiques et suffisent pour la majeure partie de la journée. La couche 4 n’est pas la défaillance du pipeline, mais la visibilité de sa limite.

## Mur d'unicité : là où l'automatisation s'arrête

Un agent de réconciliation voit « Réussi » sur la PSP et essaie de créer l'enregistrement local `Captured` — mais il existe déjà une ligne `Captured` avec la même clé d'idempotence dans la base de données. L'insertion ou la mise à jour échoue ; l'automatisation s'arrête.```text
Reconciliation: payment #5521 → PSP says Captured
  → local UPDATE attempt
  → UNIQUE constraint violation on idempotency_key
  → otomasyon durur
  → manual review queue'ya yaz
```Ce n'est pas un bug, c'est un mécanisme de protection. Le mur d'unicité empêche une double finalisation, mais il empêche également l'automatisation de dire « J'ai résolu le problème ». C’est là que le runbook fondé sur des preuves entre en jeu.

## Runbook basé sur des preuves : une procédure, pas un réflexe

Lorsqu’une intervention humaine est requise, le runbook suit cet ordre :```text
1. Step event log'u oku (payment id ile)
2. PSP status query yap (provider gateway üzerinden)
3. Local kayıtları karşılaştır (payment, order, idempotency)
4. Kanıt tablosunu doldur
5. Karar: heal / refund / no-action
6. Audit kaydı yaz
```Chaque point de décision du runbook nécessite une preuve. 'PSP dit Capturé mais local Expiré' → guérir le candidat. « PSP introuvable, traitement local » → pas de candidat au remboursement, à l'attente ou à une escalade. "Deux lignes capturées, clé d'idempotence différente" → double charge, remboursement d'une.

## File d'attente de révision manuelle : attente visible

Les enregistrements que l’automatisation ne peut pas résoudre ne doivent pas disparaître silencieusement. La file d'attente de révision manuelle est une zone visible où ces enregistrements s'accumulent, vieillissent et sont classés par priorité.

| Zone | Objectif |
| --- | --- |
| ID de paiement | Corrélation |
| Raison coincée | UnicitéMur/Evidence Ambiguë/PSPInconnu |
| preuvesRésumé | Journal des étapes + résumé des requêtes PSP |
| ibid | Depuis combien de temps attend-il |
| priorité | Montant, réclamation client, SLA |

Chaque enregistrement dans la file d'attente doit correspondre à une étape du runbook ; L'opérateur doit être capable de lire la question « que faire » dans la file d'attente.

## Exemple de Runbook : après le mur d'unicité```text
Durum: reconciliation Captured yazamadı — idempotency_key conflict

Kanıt toplama:
  □ Step log: FinalizeAttempted iki kez mi?
  □ Mevcut Captured satırı hangi webhook'tan geldi?
  □ PSP query: kaç charge var bu correlation id ile?

Karar ağacı:
  → Tek PSP charge, local çift satır → eski satırı audit ile kapat
  → İki PSP charge → birini refund et (runbook: duplicate charge)
  → PSP charge yok → local Captured yanlış → escalate

Distinctions souvent confuses```text

❌ Manual review queue = otomasyon başarısız oldu ✓ Manual review queue = otomasyonun sınırı görünür ve güvenli

❌ Runbook = deneyimli mühendisin sezgisi ✓ Runbook = kanıt tabanlı, tekrarlanabilir prosedür

❌ Uniqueness wall kaldırılmalı ✓ Uniqueness wall korunmalı; runbook duvarın ötesini yönetir

| Statut | Automatisation | Runbook humain |
| --- | --- | --- |
| Délai d'expiration transitoire | Réessayer le travailleur | Pas nécessaire |
| Âgés FinaliserEn attente | Réconciliation | Pas nécessaire |
| Conflit d'idempotence | Il s'arrête et écrit dans la file d'attente | Rassemblez des preuves, décidez |
| Réponse ambiguë de la PSP | Il s'arrête et écrit dans la file d'attente | Escalader ou attendre |

## Liste de contrôle du pipeline de récupération

1. Les couches de nouvelle tentative, d'observateur bloqué et de réconciliation fonctionnent-elles séparément et séquentiellement ?
2. La violation de la contrainte d'unicité est-elle automatiquement écrite dans la file d'attente de révision manuelle ?
3. Chaque étape du runbook définit-elle clairement les preuves requises ?
4. Les enregistrements dans la file d'attente de révision manuelle sont-ils triés par âge et priorité ?
5. L'enregistrement de l'audit et la saisie du journal des événements d'étape sont-ils obligatoires après une intervention humaine ?
6. Le taux résolu par l'automatisation est-il suivi de manière métrique (automation_resolution_rate) ?

## Ce qu'il faut retenir de cet article

1. Le pipeline de récupération repose sur le premier principe d’automatisation ; l'homme est le dernier recours.
2. Le mur unique arrête l’automatisation — cette protection n’est pas un bug.
3. Le runbook doit être fondé sur des preuves ; L'action réflexe est dangereuse.
4. La file d'attente de révision manuelle empêche les enregistrements non résolus de disparaître silencieusement.

> Un bon pipeline de rétablissement n'essaie pas de réduire l'intervention humaine à zéro : il limite l'intervention humaine au bon moment, aux bonnes preuves et à la bonne procédure.

Dans la section suivante, nous abordons la couche de messagerie : exactement une fois est un mensonge ; Comment obtenir un résultat de travail efficace en une seule fois avec une défense en profondeur ?