Oyun Kitabı

Conception d'instantanés de paiement immuables : la décision qui gèle le panier (Conception Dinstantanes DE Paiement Immuables La Decision Qui Gele Le Panier)

La lecture du panier en direct au début du paiement laisse le montant et la devise indécis. La finalisation ne fonctionnera pas de manière fiable sans un instantané qui se fige au moment de l'intention.

Moteur de paiement distribué

Partie 4 de 22

Une série d'architectures de paiement distribuées qui comblent le fossé entre la capture et l'achèvement.

Distributed payment engine architecture diagram

Basket is a moving target

Lorsqu'un client accède à l'écran de paiement, les informations sur le prix, la campagne et le stock dans le panier sont toujours susceptibles de changer : la campagne peut expirer, le prix peut être mis à jour, le même client peut modifier le panier dans un autre onglet. Si vous ne figez pas ces informations au moment de la création de l'intention de paiement, le montant destiné au PSP et le montant attendu à la finalisation peuvent représenter deux réalités différentes.```text Sepet (canlı, değişken) --intent anında--> Payment Snapshot (donmuş, değişmez) ↓ PSP'ye gönderilen tutar = snapshot'taki tutar


## Concepts à la première mention```text
📦 Payment Intent
Müşterinin ödeme yapma niyetini temsil eden, PSP'ye gönderilecek tutarı ve para birimini taşıyan kayıt.

📦 Snapshot
Bir anlık gerçeğin (fiyat, miktar, vergi, indirim) o an olduğu haliyle donmuş, sonradan değişmeyen kopyası.

📦 Price-at-Intent
Ödeme başlatıldığı anda geçerli olan fiyatın, sonraki kampanya veya fiyat değişikliklerinden bağımsız olarak korunması ilkesi.

📦 Basket Drift
Sepetin, ödeme süreci ilerlerken (kullanıcı başka bir sekmede değişiklik yaparak veya arka plan işleriyle) snapshot'tan farklılaşması.

📦 Amount Reconciliation
PSP'den gelen gerçek tahsilat tutarının, snapshot'taki beklenen tutarla karşılaştırılması.
```L'instantané n'est pas une « photo » du panier ; L’état actuel du panier est figé comme un enregistrement juridique qui ne peut être modifié ultérieurement.

## Pourquoi lire les paniers en direct est trompeur

Certains systèmes examinent à nouveau le panier pour obtenir le « montant actuel » pendant la phase de finalisation après la création de l'intention de paiement. Cette approche semble séduisante car elle donne le sentiment que les « données les plus récentes » sont utilisées ; mais en réalité, cela confond deux réalités différentes à deux moments différents.```text
t0: Müşteri ödeme başlatır  → Sepet: 3 ürün, 450 TL, kampanya aktif
t1: PSP'ye 450 TL isteği gider
t2: Kampanya süresi dolar, sepet artık 480 TL gösterir
t3: Finalization, sepete tekrar bakar → 480 TL bekler ama PSP 450 TL tahsil etmiştir
```Cette incompatibilité laisse la saga de finalisation dans une situation où elle ne peut pas décider quel montant considérer comme « correct ». Le résultat : une vérification manuelle, une plainte d'un client ou un dossier financier silencieusement incorrect.

## Problème résolu par Snapshot

L'approche correcte consiste à geler l'état actuel du panier au moment de la création de l'intention de paiement (montant, devise, éléments de ligne, taxe, remise) en tant qu'enregistrement distinct et immuable. Cet enregistrement est indépendant de la table du panier ; Même si le panier change, la campagne se termine ou le prix du produit est mis à jour, l'instantané reste le même.```text
PaymentSnapshot
  amount: 450.00
  currency: TRY
  lines: [...]
  createdAt: t0
  (sepet t1, t2, t3'te değişse de bu kayıt asla değişmez)
```Le montant envoyé à la PSP est toujours lu à partir de l'instantané et non à partir du panier en direct. La saga Finalisation fait toujours référence à cet instantané dans les étapes de baisse des stocks, d'enregistrement financier et de confirmation de commande. Ainsi, quel que soit l’avenir du panier, toutes les décisions liées au paiement reposent sur la même vérité fixe.

## Vérification du montant et de la devise

L'instantané ne se contente pas de se figer ; Vous devez également vérifier le montant réel de la collecte retourné par le PSP. Si le montant dans la réponse du PSP ne correspond pas au montant dans l'instantané (par exemple une différence d'arrondi, une erreur de conversion de devise ou un défaut d'intégration), cet événement ne doit pas être automatiquement marqué comme « terminé » ; devrait tomber dans une file d'attente de litige.```text
PSP cevabı: amount=450.00, currency=TRY
Snapshot:   amount=450.00, currency=TRY
            → eşleşti, işleme devam

PSP cevabı: amount=449.99, currency=TRY
Snapshot:   amount=450.00, currency=TRY
            → eşleşmedi, finalization DURDURULUR, inceleme kuyruğuna düşer
```Cette étape de vérification détecte très tôt les erreurs d’intégration et les éventuels scénarios de falsification.

## Leurre « Retour au panier en direct »

Même une fois le mécanisme d'instantané établi, certaines équipes reviennent au panier lors de la finalisation en disant "mais le stock a peut-être changé, regardons les données actuelles". Cela va à l’encontre de l’objectif de l’instantané : le contrôle des stocks doit être traité comme une étape distincte (et avec sa propre logique d’échec/compensation) ; La décision concernant le montant et la devise ne doit jamais s’appuyer sur des données en direct. Confondre les deux, c’est comme rouvrir à la discussion un dossier juridique gelé.

## Les confrontations les plus déroutantes de cet épisode```text
❌ Finalization'da sepete tekrar bakmak, “en güncel veri” kullanmaktır
✓ Finalization'da sepete tekrar bakmak, iki farklı zaman noktasındaki gerçeği karıştırmaktır

❌ Snapshot sadece bir loglama/audit kaydıdır
✓ Snapshot, ödeme ve finalization kararlarının tek referans kaynağıdır

❌ PSP'den gelen tutar her zaman beklenen tutarla eşleşir, doğrulama gereksizdir
✓ Tutar/para birimi uyuşmazlığı otomatik değil, kuyruğa düşen bir olay olmalıdır

❌ Stok güncelliği ile ödeme tutarı aynı mekanizmayla kontrol edilebilir
✓ Stok kontrolü ayrı bir adımdır; tutar kararı asla canlı veriye dönmemelidir

Instantané de votre liste de contrôle de conception

  1. Le montant que vous avez envoyé à la PSP est-il lu à partir du panier en direct ou d'un enregistrement instantané gelé ?
  2. À partir de quelle source (instantané ou table en direct) chaque étape de la saga Finalisation lit-elle le montant ?
  3. Que se passe-t-il si le montant renvoyé par la PSP ne correspond pas au montant indiqué dans l'instantané ? Est-ce que ça passe automatiquement ou est-ce que ça s'arrête ?
  4. Avez-vous vérifié que l'instantané ne change pas même si la table du panier change après la création de l'instantané ?
  5. Le champ de devise du Snapshot est-il toujours le même que la devise envoyée à la PSP ? S'il y a une conversion, où cette étape est-elle enregistrée ?

Si vous ne parvenez pas à répondre clairement à l’une de ces cinq questions, il existe probablement un risque de « dérive silencieuse des montants » dans votre système.

Choses à retenir de cette section

  1. Dès que l'intention de paiement est créée, le montant du panier, les lignes et la devise doivent être gelés en tant qu'instantané distinct et immuable.
  2. La saga Finalisation ne doit à aucun moment revenir au panier en direct ; Chaque décision doit faire référence à l’instantané.
  3. Le montant réel restitué par la PSP doit être comparé au montant attendu dans l'instantané ; Le différend ne devrait pas être résolu automatiquement, mais devrait être soumis à un examen.
  4. Le contrôle à jour des stocks est une responsabilité distincte ; À ne pas confondre avec la décision montant/devise.

Le panier est un modèle pour l'avenir ; Le paiement est une décision figée dans le passé. Lire ces deux extraits du même disque, c’est faire apparaître deux époques différentes comme une seule réalité.

FAQ

Frequently asked questions

Qu’est-ce que l’intention de paiement ?

Un enregistrement qui représente l'intention de payer du client et indique le montant et la devise à envoyer au PSP.

Qu'est-ce qu'un instantané ?

Une copie figée d'une réalité momentanée (prix, quantité, taxe, remise) telle qu'elle est à ce moment-là, qui ne change pas par la suite.

Est-il vrai que « Revoir le panier lors de la finalisation signifie utiliser les « données les plus récentes » ? »

Regarder à nouveau le panier dans Finalisation confond la réalité à deux moments différents

Que corrige cette section ?

Cette section explique pourquoi « revenir au panier actif » est un risque, pas un raccourci, et comment un instantané immuable le résout. Dès que l'intention de paiement est créée, le montant du panier, les lignes et la devise doivent être gelés en tant qu'instantané distinct et immuable. Lorsqu'un client accède à l'écran de paiement, les informations sur le prix, la campagne et le stock dans le panier sont toujours susceptibles de changer : la campagne peut expirer, le prix peut être mis à jour, le même client peut modifier le panier dans un autre onglet. Si vous ne figez pas ces informations au moment de la création de l'intention de paiement, le montant destiné au PSP et le montant attendu à la finalisation peuvent représenter deux réalités différentes.

Principes d'ingénierie appris

  • Dès que l'intention de paiement se produit, le montant du panier, les lignes et la devise doivent être gelés comme un instantané immuable.
  • Les décisions de finalisation ne doivent jamais revenir au panier en direct ; doit toujours faire référence à l'instantané.
  • Si le montant renvoyé par la PSP et l'instantané ne correspondent pas, cela ne devrait pas être un événement automatique mais devrait être soumis à un examen.

Continuer la lecture

Continuer la lecture

Suivant en série

Suivant en série

Même série

Paylaş