Comprobante de pago y estado de pago: por qué no debe confundirse (Comprobante DE Pago Y Estado DE Pago Por Que No Debe Confundirse)

Dos preguntas diferentes, dos registros diferentes

"¿Qué dijo la PSP?" y “¿qué decidimos?” Estas son dos preguntas similares pero en realidad completamente diferentes. La respuesta a la primera es la evidencia: el webhook sin formato de la PSP, la respuesta de la API, la marca de tiempo: un registro inmutable. La respuesta a la segunda es el estado: la decisión que usted toma al combinar esta evidencia y sus reglas comerciales: pago Captured o pago Completed.```text Evidence (kanıt) State (durum) PSP'nin ham cevabı → Sizin kararınız Değişmez, append-only → Değişebilir, karar tablosu “Ne oldu” → “Biz ne yaptık”

## Conceptos en la primera mención```text
📦 Evidence (Kanıt)
Dış sistemin (PSP) size bildirdiği ham gerçeğin, yorumlanmadan ve değiştirilmeden saklanan kaydı.

📦 State (Durum)
Evidence'ları ve iş kurallarını birleştirerek sizin verdiğiniz, ikinci ve dördüncü bölümde tanımladığımız durum makinesindeki karar.

📦 Append-only Log
Sadece ekleme yapılan, mevcut kayıtların asla üzerine yazılmadığı veya silinmediği depolama şekli.

📦 Source of Truth vs. Derived Truth
Birincisi ham, tartışmasız gerçek; ikincisi bu gerçekten türetilen, yorum içeren karar.
📦 Reconciliation
Evidence kayıtlarını tekrar okuyup, mevcut state'in bu kanıtlarla hâlâ tutarlı olup olmadığını doğrulama süreci.
```El ejemplo que demuestra más claramente esta distinción es este: la carga útil del webhook enviada por PSP es una prueba; Es una decisión estatal que lea esta carga útil y escriba `Payment.Status = Captured`. La evidencia nunca cambia; El estado se puede actualizar cuando lleguen nuevas pruebas.

## ¿Por qué estos dos no pueden vivir en la misma mesa?

Algunos sistemas sobrescriben directamente la tabla `payments` con el webhook proveniente de la PSP: cuando llega un nuevo webhook, la fila correspondiente se actualiza y el valor anterior se pierde. Con este diseño, ya no puedes responder a la pregunta "¿qué dijo exactamente PSP?"; solo puedes responder a la pregunta "¿cuál fue nuestro último comentario?"```text
Yanlış model:
payments
id | status     | raw_payload
1  | Captured   | {...son webhook'un içeriği, öncekiler üzerine yazıldı...}
```Esto significa que pierde la información (cadena de evidencia pasada) que será más útil durante un incidente.

## Modelo correcto: dos espacios de almacenamiento separados.

La evidencia se almacena en su propia tabla de solo anexos; Cada nuevo webhook o respuesta API se agrega como una nueva línea, no se actualiza ni elimina ninguna línea. Estado es la decisión actual derivada de la evidencia en una tabla separada.```text
payment_evidence (append-only)
id | payment_id | source | received_at | raw_payload
1  | pay_42     | psp    | t1           | {...authorize...}
2  | pay_42     | psp    | t2           | {...captured...}
3  | pay_42     | psp    | t5           | {...captured (duplicate)...}

payments (state)
id     | status
pay_42 | Captured   ← evidence #2'den türetildi, #3 aynı sonucu doğruladı
```Gracias a esta distinción, la línea estatal nunca “olvida” cuándo y por qué cambió, porque la evidencia que la produjo todavía está ahí.

## ¿Por qué la recuperación lee la evidencia, no el estado?

Cuando necesita que su sistema vuelva al estado "correcto" después de un incidente (por ejemplo, un accidente laboral, una implementación incorrecta, una inconsistencia sospechosa), confiar en el estado actual es arriesgado, porque el estado puede ser exactamente lo que rompió el incidente. En cambio, volver a leer el registro de pruebas y reproducir el estado es una forma más confiable de recuperación.```text
Recovery süreci
  1. payment_evidence tablosundan pay_42'ye ait tüm kayıtları zaman sırasına göre oku
  2. Her evidence'ı iş kurallarına göre tekrar işle (guard'lardan geçir)
  3. Sonuçta türeyen state'i mevcut payments tablosundaki değerle karşılaştır
  4. Fark varsa, hangisi doğru olduğunu evidence'a dayanarak belirle — state'e değil
```Este proceso forma la base de los trabajadores de la reconciliación que cubriremos más adelante en esta serie: cuando el Estado está en duda, la evidencia es siempre el árbitro.

## Nunca almacene evidencia “interpretada”

Un último error: incluso cuando algunos sistemas almacenan evidencia, la "limpian" un poco: eliminando campos innecesarios y normalizando el formato. Esto pierde el valor real de la evidencia (lo que dijo exactamente la PSP, byte a byte). La evidencia debe ser la versión cruda e inalterada de la respuesta que le dio la PSP; El trabajo de interpretar y normalizar pertenece al paso de derivación del estado, no a la evidencia en sí.

## Los enfrentamientos más confusos de este episodio.```text
❌ Evidence ve state aynı satırda tutulabilir, biri diğerinin üzerine yazılabilir
✓ Evidence append-only'dir; state ayrı bir tabloda, evidence'tan türetilir

❌ Webhook payload'ını saklamadan önce “temizlemek” zararsızdır
✓ Temizlenmiş evidence, PSP'nin tam olarak ne söylediği bilgisini kaybettirir

❌ Bir incident'te mevcut state'e güvenip devam etmek en hızlı yoldur
✓ Incident sırasında state şüphelidir; evidence'tan yeniden türetmek (replay) daha güvenilirdir

❌ Evidence sadece debug/log amaçlıdır, iş kararı için gerekli değildir
✓ Evidence, reconciliation ve recovery'nin tek güvenilir kaynağıdır

Lista de verificación para su distinción de evidencia/estado

1. ¿La carga útil del webhook sin procesar de la PSP se almacena en una tabla separada de solo agregar o se sobrescribe con la tabla payments?
2. ¿El segundo o tercer webhook para el mismo pago sobrescribe el primer registro o se agrega una nueva línea de evidencia?
3. Cuando existe una sospecha de inconsistencia estatal, ¿tiene un proceso que pueda reproducir el registro de evidencia?
4. ¿Existen pasos de “limpieza” o normalización al almacenar la Evidencia? Si es así, ¿también almacena los datos sin procesar por separado?
5. ¿Puede rastrear retrospectivamente de qué registro de evidencia se derivó una fila en su tabla de estado?

Si responde “no” a una de estas cinco preguntas, es posible que no pueda responder la pregunta “¿Qué dijo realmente PSP” en un incidente?

Cosas para recordar de esta sección

1. La evidencia es la verdad cruda e inmutable que te dice la PSP; El estado es la decisión que se toma combinando estos hechos con las reglas de negocio.
2. La evidencia debe adjuntarse únicamente; Cuando llega un nuevo webhook, el anterior no se sobrescribe, sino que se agrega una nueva línea.
3. Los procesos de recuperación y reconciliación no deben depender del estado actual; Debe volver a leer el registro de pruebas y derivar el estado.
4. “Limpiar” la evidencia al ocultarla hace que se pierda el conocimiento de lo que dijo exactamente la PSP; Los datos sin procesar siempre deben estar protegidos.

El estado es tu comentario de hoy; La evidencia es el testigo que nunca cambia. Si comienza a cuestionar su propia interpretación de un incidente en lugar del testigo, perderá.