Pourquoi la collecte (capture) est-elle facile mais la finalisation est-elle difficile ? (Pourquoi La Collecte Capture Est Elle Facile Mais La Finalisation Est Elle Difficile)

Une étape, six étapes

Lorsque vous dites « paiement reçu », vous voulez généralement dire une chose : la passerelle du fournisseur a envoyé une demande au PSP et le PSP a dit « J'ai reçu l'argent ». C'est un appel, une réponse, une confirmation. Mais ce que vous entendez par « commande terminée » est bien plus vaste : le stock a été déduit, le dossier financier a été ouvert, la commande a été confirmée, le client a été averti, le panier a été vidé et les éventuels points de fidélité ont été traités.```text Capture: Checkout Orchestrator → Provider Gateway → PSP → “alındı”

Finalization: Stok düş + Finans kaydı + Sipariş onayı + Bildirim + Sepet temizliği (altı bağımsız adım, altısı da ayrı ayrı başarısız olabilir)

## Concepts à la première mention```text
📦 Capture
PSP'nin, önceden ayrılmış veya doğrudan istenmiş bir tutarı fiilen tahsil ettiğini bildirmesi; tek bir dış sistem gerçeğidir.

📦 Finalization
Capture'dan sonra işin gerçekten bitmesi için gereken tüm iç adımların toplamı: stok, finans, onay, bildirim, temizlik.

📦 Saga
Birden fazla adımı, her biri kendi başarısızlık ve telafi mantığıyla, uçtan uca yöneten bir iş akışı deseni.

📦 Telafi Adımı (Compensating Action)
Bir saga adımı geri alınamadığında, önceki adımların etkisini dengelemek için çalıştırılan ters işlem.

📦 Adım İşaretçisi (Step Marker)
Bir saga adımının tamamlandığını kalıcı olarak işaretleyen kayıt; yeniden çalıştığında adımın tekrarlanmasını önler.
```La facilité de Capture vient du fait qu’il repose sur un seul participant (PSP) et une seule réponse. La difficulté de la finalisation vient du fait qu'elle dépend d'un grand nombre de participants qui peuvent échouer indépendamment.

## Pourquoi Capturer est simple

Le critère de réussite de Capture est une seule phrase : la PSP a-t-elle dit "Je l'ai récupéré" ou non ? Ces informations sont accompagnées d'une réponse synchrone ou d'un webhook, leur signature est vérifiée et l'enregistrement de paiement correspondant devient `Captured`. Il n'y a pas d'écriture dans plusieurs bases de données, pas d'appels de service multiples, pas d'étapes séquentielles interdépendantes ici — il y a une réponse oui/non provenant d'un système externe.```text
Provider Gateway --istek--> PSP
Provider Gateway <--"captured"-- PSP
                        ↓
                Payment.Status = Captured
                (bir yazma, bir karar)
```## Pourquoi la finalisation est une saga

Une fois la capture effectuée, le travail n’est pas terminé ; La partie vraiment compliquée commence maintenant. Pour qu'une commande soit considérée comme « vraiment terminée », toutes les étapes suivantes doivent se produire de manière fiable, dans n'importe quel ordre, jusqu'à ce qu'elles soient toutes terminées :```text
Finalization Saga
  1. Stok Servisi'nde rezervasyonu kesin düşüşe çevir
  2. Finans/Ledger'da gelir kaydını aç
  3. Sipariş satırlarını “onaylandı” olarak işaretle
  4. Müşteriye bildirim gönder
  5. Sepeti/aktif intent'i temizle
  6. (Varsa) sadakat puanı veya kampanya etkisini işle
```Chacune de ces six étapes a son propre modèle d'erreur : le service d'inventaire peut être temporairement indisponible, le service financier peut générer une erreur de validation, le service de notification peut expirer. Il n’y avait qu’un seul « oui/non » dans Capture ; Il y a ici six « oui/non » indépendants, et aucun d’eux ne garantit l’autre.

## Finalisation partielle : l'état intermédiaire le plus dangereux

Le scénario le plus difficile est celui où la moitié de la saga fonctionne et l’autre moitié ne fonctionne pas. Par exemple, le stock a été réduit mais le dossier financier n'a pas pu être ouvert ; Le système est tombé en panne et le travailleur a besoin de savoir quelles étapes ont été effectuées lors du redémarrage.```text
Finalization saga çalışıyor
  ✓ Stok düşüldü
  ✓ Sipariş onaylandı
  ✗ Finans kaydı — worker crash oldu
  ? Bildirim — henüz denenmedi

Worker yeniden başlar: Hangi adımları TEKRAR çalıştırmalı, hangilerini ATLAMALI?
```Vous ne pouvez pas répondre à cette question sans marqueurs d'étape. Chaque étape doit enregistrer en permanence son statut d'achèvement ; Sinon, lorsque le travailleur redémarrera, soit il exécutera toute la saga depuis le début et réduira le stock deux fois, soit il ne fera rien et la commande restera inachevée pour toujours.

## Pourquoi cette distinction est considérée comme allant de soi

Lorsque la plupart des équipes parlent d’« intégration des paiements », elles entendent uniquement la capturer et la planifier comme une tâche hebdomadaire. La saga Finalisation est généralement considérée comme des « détails » et entre en production sans être conçue de manière adéquate. En réalité, la capture s'adresse à un seul système externe, comme nous l'avons montré dans les deux premières parties de cette série ; La finalisation nécessite que votre propre système soit résilient à ses propres erreurs. Cette dernière nécessite un investissement d’ingénierie beaucoup plus important.

## Les confrontations les plus déroutantes de cet épisode```text
❌ Ödeme entegrasyonu = Capture'ı çalıştırmak
✓ Ödeme entegrasyonu = Capture + finalization saga'sının tamamı

❌ Capture başarılı olduysa iş bitmiştir
✓ Capture, finalization saga'sının başlangıç tetikleyicisidir, bitişi değil

❌ Saga adımlarının sırası önemli değildir, hepsi “aynı işlem”dir
✓ Her adım bağımsız başarısız olabilir; her birinin kendi retry ve telafi mantığı gerekir

❌ Worker crash olursa saga'yı baştan çalıştırmak güvenlidir
✓ Adım işaretçisi olmadan baştan çalıştırmak, tamamlanmış adımları tekrarlayıp yan etki üretir

Liste des tests de votre saga de finalisation

1. Notez les étapes de votre saga de finalisation : combien y a-t-il d'étapes, lesquelles sont destinées aux services individuels ?
2. Testez si chaque étape est idempotente en elle-même : le résultat change-t-il si vous exécutez deux fois la même étape ?
3. Tuer délibérément l'ouvrier au milieu de la saga (test du chaos). Lorsqu’il recommence, quelles étapes saute-t-il et quelles étapes répète-t-il ?
4. Chaque étape comporte-t-elle un plan de compensation ou de nouvelle tentative pour un scénario d'échec, ou est-il rédigé en partant du principe que « cette étape réussira toujours » ?
5. Si la capture est réussie mais que la saga de finalisation n'a jamais commencé, combien de minutes faut-il pour s'en rendre compte ?

Si vous échouez à deux de ces cinq tests, votre saga de finalisation a probablement été écrite pour le « chemin heureux » et non pour le chemin de l'erreur.

Choses à retenir de cette section

1. Capture est une réponse oui/non provenant d'un seul système externe (PSP) ; C'est de là que vient sa simplicité.
2. La finalisation est une saga qui nécessite plusieurs étapes indépendantes pour être toutes complétées ; C'est de là que vient la difficulté.
3. La finalisation partielle (certaines étapes sont correctes, d'autres non) est l'état intermédiaire le plus dangereux et ne peut pas être récupéré en toute sécurité sans indicateurs d'étape.
4. Si « l'intégration des paiements » ne couvre que la capture, la partie la plus risquée du projet est exclue du plan.

La capture est le moment où la PSP est d'accord avec vous. La finalisation est le moment où vous acceptez votre système – et c'est généralement la partie la plus difficile.