Payé mais pas de commande : amélioration (Paye Mais Pas DE Commande Amelioration)

Dans la section précédente, nous avons vu comment le chercheur de consensus détecte les dérives. Cette section traite de la forme la plus gênante de cette dérive : le client a effectivement été facturé du côté de la PSP, mais il n'y a aucune commande en retour dans le système.

Ce scénario génère la panique car deux mauvaises solutions semblent tentantes : rembourser immédiatement (peut-être que le client voulait vraiment la commande, déclenchant un cycle de remboursement-réessaye inutile) ou créer silencieusement une nouvelle commande (risque de produire une mauvaise commande sans savoir quel panier correspond à quelle offre).```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

## Concepts à la première mention```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.
```Les frais d'orphelin proviennent souvent de la perte de l'identifiant de corrélation quelque part : l'identifiant enregistré lors de la création de l'intention est interrompu avant d'atteindre l'étape de création de la commande.

## Guide de réponse aux incidents : premières étapes

Lorsqu’une charge orpheline est détectée (généralement via un agent de rapprochement ou une réclamation client), la première étape n’est jamais d’agir, mais de rétablir la chaîne de corrélation :```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)
```L'identifiant de corrélation doit toujours être écrit dans le champ métadonnées de la PSP (lors de la création de la charge) ; Il s’agit de la décision de conception la plus importante qui permet de résoudre rétroactivement les accusations orphelines.

## Panier multi-intention : quel argent appartient à quelle commande

Si un client a ouvert la page de paiement deux fois (actualisation de l'onglet, double-clic, nouvelle tentative après un délai de réseau), deux intentions de paiement différentes peuvent se produire pour le même panier. Si les deux réussissent du côté des PSP, la question qui se pose au système n'est plus « un paiement perdu » mais « quel paiement gagne, qu'arrive-t-il à l'autre ».```text
Cart #A
  ├─ Intent #1 → PSP: Succeeded
  └─ Intent #2 → PSP: Succeeded  (aynı sepet, iki farklı charge)
```Le comportement correct ici est de verrouiller le panier (empêchant la création de nouvelles intentions sur le même panier) et de sélectionner une seule intention comme « gagnant » et de rembourser automatiquement l'autre — attacher les deux à la commande crée une double tarification.

## Nettoyer soigneusement Dedup : pourquoi la suppression « agressive » est risquée

Le plus gros piège lors de la compensation des frais d'orphelin est de baser la logique de dédoublonnage sur des critères vagues tels que « même montant, même client, heure récente ». Ce critère peut traiter à tort deux commandes intentionnelles distinctes (le client a effectivement acheté deux choses différentes) comme une seule commande.```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 décision de déduplication doit toujours être basée sur une identité (identifiant de corrélation, clé d'idempotence) générée par le système lui-même ; Les signaux indirects tels que le montant et l’heure ne doivent être utilisés que comme niveau de vérification supplémentaire, et non comme critère principal.

## Guérir ou rembourser : critères de décision

| Statut | Action correcte |
| --- | --- |
| Trouvé un panier incomplet correspondant à l'identifiant de corrélation | Guérir — créer une commande, connecter le paiement |
| L'identifiant de corrélation ne correspond à aucun enregistrement | Remboursement – ​​aucun objectif à lier |
| Deux intentions réussies dans le même panier | Guérissez l’un, remboursez l’autre |
| Panier déjà complété avec un autre paiement | Remboursement – ​​double facturation |

Chaque processus de guérison doit produire son propre enregistrement d'audit : qui/quel processus a créé cet ordre, quand et sur la base de quelles preuves. Cet enregistrement est également utilisé pour éviter que le même scénario ne se reproduise à l’avenir.

## Distinctions souvent confuses```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
```## Comparaison de la décision de guérison et de remboursement

| Critère | Guérir | Remboursement |
| --- | --- | --- |
| Correspondance de l'identifiant de corrélation | Oui | Aucun ou peu clair |
| Expérience client | Ordre visible, interruption non ressentie | Remboursé, pas de commande |
| Risque | Risque de décalage | Risque d'insatisfaction client |

## Liste de contrôle de réponse aux incidents

1. Existe-t-il un identifiant de corrélation dans les métadonnées PSP d'Orphan charge ? Sinon, c'est le signe d'un défaut de conception.
2. La décision de déduplication est-elle basée sur des signaux indirects tels que la quantité/le temps ou sur l'ID généré par le système ?
3. Dans un scénario multi-intent, le panier se verrouille-t-il après la première intention réussie ?
4. Chaque processus de guérison produit-il un dossier d'audit contenant des informations probantes sur qui/quand/quelle ?
5. Avant la décision de remboursement, est-il vérifié à deux reprises qu'aucune cible n'a effectivement été trouvée ?

## Ce qu'il faut retenir de cet article

1. La clé pour résoudre les frais orphelins est de générer en toute sécurité l’identifiant de corrélation au tout début du flux de paiement.
2. Multi-intent cart is a normal scenario; Il doit être conçu avec un verrouillage du panier et une sélection d'intention gagnante unique.
3. La décision de déduplication ne doit jamais être basée sur des signaux indirects tels que la quantité/le temps, elle doit toujours être basée sur l'identité.
4. La question de savoir s’il faut guérir ou rembourser devrait être une décision fondée sur des preuves et non un acte réflexe.

> L'action la plus sûre en période de panique n'est pas une solution miracle ; Il s'agit de ne rien faire jusqu'à ce que vous trouviez les bonnes preuves.

Dans la section suivante, nous abordons la racine d'une telle dérive : pourquoi la mise en place d'une transaction distribuée (2PC) entre PSP, commande et finance est un piège, et pourquoi saga + réconciliation est la vraie réponse.