IOSOR Guides
Ordre des événements et écriture au grand livre
Les événements DLR et MO désordonnés ne doivent pas briser les règles de débit prépayé ; la séquence d'arrivée n'est pas la loi de l'argent.
Les réseaux livrent des callbacks dans le désordre. Un DLR tardif, un MO précoce ou un changement de statut avant le règlement ne doivent pas inventer un second débit ni réécrire une ligne réglée. Cette page est le contrat d'ordre de comptabilisation : les règles du grand livre survivent au réarrangement — ce n'est pas une introduction à l'ID de corrélation ni un essai de facturation MO contre MT.
L'ordre d'arrivée n'est pas la loi du grand livre
L'arrivée HTTP est un accident de transport. L'argent est comptabilisé selon retenue → règlement → mise à jour du résultat — et non selon le dernier callback reçu. Une révision souple de USD 1,000/month traite le réarrangement comme un incident financier lorsque le produit affiche un succès alors que le grand livre bouge deux fois. USD 20 prouve qu'un DLR tardif forcé n'ouvre jamais de débit parallèle.
À quoi ressemble le désordre
| Modèle d'arrivée | Comptabilisation sûre | Réaction non sécurisée |
|---|---|---|
| DLR avant règlement | En attente ; régler une fois sous retenue | Débito basé sur le DLR seul |
| Échec puis livré | Mettre à jour le résultat sur place | Second frais pour inversion |
| MO avant corrélation MT | Classer en boîte de réception ; joindre au règlement MT | Facturer le MO comme sortant |
| Statut après remboursement | Pas de nouvel argent ; annoter | Re-régler l'intention libérée |
| Deux terminaux, une intention | Une ligne d'argent. |
Règles de comptabilisation qui survivent au réarrangement
Générez les clés de retenue et d'idempotence avant les effets secondaires (Contrat de webhook avant le premier envoi). Réglez une fois par intention facturable ; les événements ultérieurs mettent seulement à jour le résultat. N'ouvrez jamais de débit parallèle pour un DLR précoce ou tardif ou un MO. Rejetez ou stockez hors de la fenêtre signée — pas de succès inventé. Exportez les jointures par intention, et non par horodatage d'arrivée.
Le décalage est normal, pas l'argent double
Les réseaux mobiles échouent. Les files d'attente ralentissent pendant les heures creuses et se vident d'un coup. Lorsque les événements arrivent avec des heures de retard, le grand livre ne doit pas recalculer les soldes actifs avec des données périmées. Validez toujours la fenêtre temporelle avant de toucher au solde.
Liste de contrôle pour l'ordre des événements
Exigez que votre fournisseur prouve qu'un DLR tardif ne génère pas de second frais. Vérifiez que le rapprochement groupe par ID d'intention et non par heure d'arrivée sur le serveur web. Assurez-vous que les clés d'idempotence bloquent les replays même lorsque les statuts arrivent inversés.
Commencez avec IOSOR
Dans la console: Event order vs ledger posting must reconcile by shared id.. Nommez le propriétaire et les portes avant d’élargir.
Lié: duplicate webhook no second debit webhook consumer ops at volume.
Points IOSOR
Discipline ops de garde—pas une brochure.
Faites: name owner + gate. Ne pas: skip the gate.
Ce guide vous a-t-il aidé ?
Guides associés
- Surveillance des métriques de santé des endpoints Webhook
Apprenez à suivre la latence de réponse et les codes d'état au sein de la plateforme IOSOR pour gérer proactivement la santé des webhooks.
- Configuration des alertes Webhook pour les seuils de solde prépayé
Apprenez à configurer des webhooks de seuil de solde automatisés dans IOSOR pour surveiller les comptes prépayés, éviter les interruptions et gérer le provisionnement JIT.
- Traitement des événements de webhook de provisionnement Just-in-Time
Maîtrisez le cycle de vie en temps réel des canaux entrants grâce aux webhooks de provisionnement JIT d'IOSOR. Automatisez l'attribution des numéros et la mise à jour des grands livres pour votre CPaaS en marque blanche.