Pagado pero sin pedido: mejora (Pagado Pero Sin Pedido Mejora)

En la sección anterior vimos cómo el trabajador de consenso detecta la deriva. Esta sección trata la forma más molesta de esa deriva: en realidad se le ha cobrado al cliente en el lado de PSP, pero no hay ningún pedido a cambio en el sistema.

Este escenario genera pánico porque dos malas soluciones parecen tentadoras: reembolsar inmediatamente (tal vez el cliente realmente quería el pedido, iniciando un ciclo innecesario de reintento de reembolso) o crear silenciosamente un nuevo pedido (riesgo de producir un pedido incorrecto sin saber qué carrito corresponde a qué oferta).```text PSP kaydı: Charge #789 → Succeeded, amount: 249.00 Local kayıt: (hiçbir Order veya Payment satırı yok) │ ▼ Bu paranın hangi sepete ait olduğunu belirle │ ▼ Sipariş oluştur (heal) VEYA güvenle refund et

## Conceptos en la primera mención```text
📦 Orphan Charge
PSP tarafında başarılı ama local sistemde hiçbir kayda bağlanamayan ücretlendirme.

📦 Multi-Intent Cart
Aynı sepet için birden fazla ödeme intent'i oluşturulmuş durum (örn. kullanıcı sayfayı iki kez yeniledi).

📦 Heal (İyileştirme)
Orphan charge'ı doğru sepete/siparişe geriye dönük olarak bağlama işlemi.

📦 Correlation ID
Bir ödeme intent'ini oluşturduğu sepete/isteğe bağlayan, ödeme akışının başında üretilen kimlik.
```El cargo huérfano a menudo surge de la pérdida de la identificación de correlación en algún lugar: la identificación registrada mientras se crea la intención se interrumpe antes de llegar al paso de creación del pedido.

## Guía de respuesta a incidentes: primeros pasos

Cuando se detecta un cargo huérfano (normalmente a través de un conciliador o de una queja de un cliente), el primer paso nunca es actuar, sino restablecer la cadena de correlación:```text
1. PSP'nin charge metadata'sından correlation id'yi çıkar
2. Bu id ile local sistemde bir cart/intent kaydı ara
3. Kayıt bulunduysa → hangi aşamada kesintiye uğradığını belirle
4. Kayıt bulunamadıysa → refund'a yönel (heal edilecek bir hedef yok)
```El ID de correlación siempre debe escribirse en el campo de metadatos de la PSP (al crear el cargo); Esta es la decisión de diseño más importante que hace que los cargos huérfanos se puedan resolver retroactivamente.

## Carro multiintención: qué dinero pertenece a qué pedido

Si un cliente abrió la página de pago dos veces (actualización de pestaña, doble clic, reintento después de un retraso en la red), pueden ocurrir dos intentos de pago diferentes para el mismo carrito. Si ambos tienen éxito por parte de PSP, la pregunta que enfrenta el sistema ya no es "un pago perdido" sino "qué pago gana, qué le sucede al otro".```text
Cart #A
  ├─ Intent #1 → PSP: Succeeded
  └─ Intent #2 → PSP: Succeeded  (aynı sepet, iki farklı charge)
```El comportamiento correcto aquí es bloquear el carrito (evitando que se creen nuevos intents en el mismo carrito) y seleccionar solo un intent como "ganador" y reembolsar automáticamente el otro; adjuntar ambos al pedido crea un precio doble.

## Limpiar Dedup con cuidado: por qué la eliminación "agresiva" es riesgosa

El mayor obstáculo a la hora de liquidar cargos huérfanos es basar la lógica de deduplicación en criterios vagos como "misma cantidad, mismo cliente, tiempo reciente". Este criterio puede tratar erróneamente dos pedidos intencionales separados (el cliente en realidad compró dos cosas diferentes) como un solo pedido.```text
❌ Gevşek dedup
Aynı müşteri + aynı tutar + 5 dakika içinde → tek sipariş say

✓ Sıkı dedup
Aynı correlation id VEYA aynı idempotency key → tek sipariş say
```La decisión de Dedup siempre debe basarse en una identidad (id de correlación, clave de idempotencia) generada por el propio sistema; Las señales indirectas, como la cantidad y el tiempo, solo deben utilizarse como un nivel adicional de verificación, no como criterio principal.

## Sanar o reembolsar: criterios de decisión

| Estado | Acción correcta |
| --- | --- |
| Se encontró un carrito incompleto que coincide con el ID de correlación | Sanar: crear pedido, conectar pago |
| El ID de correlación no coincide con ningún registro | Reembolso: no hay objetivo que vincular |
| Dos intentos exitosos en la misma canasta | Cura a uno, reembolsa al otro |
| Carrito ya completado con otro pago | Reembolso: doble cargo |

Cada proceso de curación debe producir su propio registro de auditoría: quién/qué proceso creó esta orden, cuándo y en base a qué evidencia. Este registro también se utiliza para evitar que se repita el mismo escenario en el futuro.

## Distinciones frecuentemente confusas```text
❌ Orphan charge her zaman refund edilmeli
✓ Correlation id ile eşleşen bir hedef varsa heal etmek doğru olabilir

❌ Aynı tutar + aynı müşteri = aynı sipariş
✓ Dedup, sistemin kendi ürettiği kimliğe (correlation id) dayanmalı

❌ Multi-intent bir hata durumudur, göz ardı edilebilir
✓ Multi-intent normal bir kullanıcı davranışıdır (yenileme, çift tıklama), tasarlanmalıdır
```## Comparación de la decisión de curación y reembolso

| Criterio | Sanar | Reembolso |
| --- | --- | --- |
| Coincidencia de identificación de correlación | Sí | Ninguno o poco claro |
| Experiencia del cliente | Orden visible, interrupción no sentida | Devolución de dinero, sin pedido |
| Riesgo | Riesgo de desajuste | Riesgo de insatisfacción del cliente |

## Lista de verificación de respuesta a incidentes

1. ¿Existe una identificación de correlación en los metadatos de PSP de Orphan Charge? De lo contrario, esto es un signo de un defecto de diseño.
2. ¿La decisión de Dedup se basa en señales indirectas como cantidad/tiempo o en el ID generado por el sistema?
3. En un escenario de múltiples intenciones, ¿se bloquea el carrito después de la primera intención exitosa?
4. ¿Cada proceso de curación produce un registro de auditoría con información de evidencia de quién/cuándo/qué?
5. Antes de la decisión de devolución, ¿se verifica dos veces que realmente no se encontró ningún objetivo?

## Lo que debes recordar de este artículo

1. La clave para resolver los cargos huérfanos es generar de forma segura la identificación de correlación al comienzo del flujo de pago.
2. El carrito de múltiples intenciones es un escenario normal; Debe diseñarse con bloqueo de canasta y selección de intención ganadora única.
3. La decisión de deduplicación nunca debe basarse en señales indirectas como cantidad/tiempo, siempre debe basarse en la identidad.
4. La cuestión de si sanar o reembolsar debe ser una decisión basada en evidencia, no una acción refleja.

> La acción más segura en tiempos de pánico no es una solución rápida; Se trata de no hacer nada hasta encontrar la evidencia correcta.

En la siguiente sección llegamos a la raíz de tal deriva: por qué establecer una transacción distribuida (2PC) entre PSP, orden y finanzas es una trampa, y por qué saga + reconciliación es la verdadera respuesta.