¿Por qué la recopilación (captura) es fácil pero la finalización es difícil? (Por Que La Recopilacion Captura Es Facil Pero La Finalizacion Es Dificil)

Un paso, seis pasos

Cuando dice "pago recibido", normalmente quiere decir una cosa: la pasarela del proveedor envió una solicitud al PSP y el PSP dijo "Recibí el dinero". Es una llamada, una respuesta, una confirmación. Pero lo que quieres decir cuando dices “pedido completado” es mucho más grande: se han deducido las existencias, se ha abierto el registro financiero, se ha confirmado el pedido, se ha notificado al cliente, se ha vaciado la cesta y se han procesado los puntos de fidelidad.```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)

## Conceptos en la primera mención```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 facilidad de Capture proviene del hecho de que se basa en un único participante (PSP) y una única respuesta. La dificultad de la finalización proviene del hecho de que depende de un gran número de participantes que pueden fracasar de forma independiente.

## Por qué la captura es sencilla

El criterio de éxito de Capture es una sola frase: ¿La PSP dijo "lo recogí" o no? Esta información viene con una respuesta sincrónica o webhook, se verifica su firma y el registro de pago relevante se convierte en `Captured`. Aquí no hay escrituras en múltiples bases de datos, ni múltiples llamadas de servicio, ni pasos secuenciales interdependientes: hay una respuesta de sí o no de un sistema externo.```text
Provider Gateway --istek--> PSP
Provider Gateway <--"captured"-- PSP
                        ↓
                Payment.Status = Captured
                (bir yazma, bir karar)
```## Por qué Finalization es una saga

Una vez realizada la captura, el trabajo no termina; La parte realmente complicada comienza ahora. Para que un pedido se considere "verdaderamente terminado", todos los pasos siguientes deben ocurrir de manera confiable, en cualquier orden, hasta que se completen todos:```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
```Cada uno de estos seis pasos tiene su propio patrón de error: el servicio de inventario puede no estar disponible temporalmente, el servicio de finanzas puede arrojar un error de validación y el servicio de notificación puede expirar. Sólo hubo un “sí/no” en Capture; Aquí hay seis “sí/no” independientes, y ninguno de ellos garantiza al otro.

## Finalización parcial: el estado intermedio más peligroso

El escenario más difícil es cuando la mitad de la saga funciona y la otra mitad no. Por ejemplo, se redujo el stock pero no se pudo abrir el registro financiero; El sistema falló y el trabajador necesita saber qué pasos se completaron cuando se reinicia.```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?
```No puedes responder esta pregunta sin marcadores de pasos. Cada paso debe registrar permanentemente su estado de finalización; De lo contrario, cuando el trabajador se reinicie, o ejecutará toda la saga desde el principio y reducirá el stock dos veces, o no hará nada y el pedido quedará inacabado para siempre.

## Por qué esta distinción se da por sentada

Cuando la mayoría de los equipos dicen "integración de pagos", solo se refieren a capturarlo y planificarlo como un trabajo semanal. La saga Finalization generalmente es vista como "detalles" y entra en producción sin estar adecuadamente diseñada. En realidad, la captura es hablar con un único sistema externo, como mostramos en las dos primeras partes de esta serie; La finalización requiere que su propio sistema sea resistente a sus propios errores. Esto último requiere una inversión en ingeniería mucho mayor.

## Los enfrentamientos más confusos de este episodio.```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

Lista de pruebas de tu saga de Finalización

1. Anota los pasos de tu saga de Finalización: ¿cuántos pasos hay y cuáles van a servicios individuales?
2. Pruebe si cada paso es idempotente por sí solo: ¿cambia el resultado si ejecuta el mismo paso dos veces?
3. Matar deliberadamente al trabajador en plena saga (prueba del caos). Cuando comienza de nuevo, ¿qué pasos se salta y cuáles repite?
4. ¿Tiene cada paso un plan de compensación o de reintento para un escenario de falla, o está escrito con el supuesto de que “este paso siempre tendrá éxito”?
5. Si la captura es exitosa pero la saga de finalización nunca ha comenzado, ¿cuántos minutos se necesitan para darse cuenta de esto?

Si fallas dos de estas cinco pruebas, tu saga de finalización probablemente fue escrita para el “camino feliz” y no para el camino del error.

Cosas para recordar de esta sección

1. La captura es una respuesta sí/no desde un único sistema externo (PSP); De ahí viene su sencillez.
2. La finalización es una saga que requiere múltiples pasos independientes para completarse; De ahí viene la dificultad.
3. La finalización parcial (algunos pasos están bien, otros no) es el estado intermedio más peligroso y no se puede recuperar de forma segura sin punteros de pasos.
4. Si la “integración de pagos” sólo cubre la captura, la parte más riesgosa del proyecto queda fuera del plan.

La captura es el momento en el que PSP está de acuerdo contigo. La finalización es cuando llegas a un acuerdo con tu sistema, y ​​esa suele ser la parte más difícil.