IOSOR

IOSOR Guides

Porte de signature et de fenêtre de replay

Porte de production : vérifiez la signature et délimitez la fenêtre de replay avant qu'un webhook ne devienne une vérité financière ou de statut — les événements non signés ou périmés échouent de manière fermée.

L'acceptation de webhooks non authentifiés ou tardifs expose vos comptes prépayés à des fraudes par injection de faux soldes ou à des doubles débits par rejeu. Pour protéger vos actifs financiers, vous devez impérativement implémenter un verrou de sécurité qui valide la signature cryptographique et rejette tout message hors du délai de tolérance avant de modifier le solde. Approfondissez ces mécanismes avec nos guides sur la signature webhook et fenêtre de replay, les retries du webhook inbound, le langage de statut partagé et les lignes de débit face au ledger de livraison.

La vérification de la signature est une porte financière

L'argent et la vérité du statut ne commencent qu'après le passage de la vérification de la signature. Les signatures manquantes, non concordantes ou ignorées échouent de manière fermée — pas de ligne dans le grand livre, pas de « livré quand même pour le test ». Catalog Live n'autorise aucune dérogation à la porte. Profondeur des habitudes : signature webhook et fenêtre de replay. Un USD 1,000/month traite l'acceptation sans signature en staging comme une dette de production.

Fenêtre de replay avant la vérité du statut

Contrôle de la porte Le succès signifie L'échec signifie
Signature présente + valide Événement authentifié Rejet ; pas d'écriture argent/statut
Timestamp dans la fenêtre Assez récent pour être sûr Rejeté comme rejoué / périmé
ID d'événement inédit Première acceptation ACK sans second débit
Événement contractuel listé Dans le menu acheteur Suppression du type inconnu .

La livraison « au moins une fois » va réessayer. Un réessai tardif hors fenêtre n'est pas « peut-être livré ». Enregistrez les rejets de fenêtre séparément des échecs de signature. Profondeur des réessais : retries du webhook inbound.

Échec fermé lorsque la porte rejette

Les événements rejetés n'inventent jamais le succès. Le produit et la finance partagent le même vocabulaire de rejet — pas de codes en amont héroïques : Langage de statut partagé pour le produit et la finance. Les lignes de débit restent alignées uniquement sur les événements acceptés : lignes de débit et statut de livraison sur le même ledger. Les effets secondaires surviennent après l'ACK.

Produit, finance et ops partagent une seule preuve

Produit : un événement signé et dans la fenêtre peut-il mettre à jour le statut une fois ? Finance : chaque événement financier montre-t-il le passage de la porte dans la même fenêtre UTC ? Opérations : exportez les échecs de signature par rapport aux rejets de fenêtre sans archéologie Slack.

Check-list acheteur pour la porte de signature et de replay

Vérifiez que le secret partagé n'est pas exposé dans les logs. Assurez-vous que le timestamp est strictement UTC. Validez que l'ID d'événement est unique par contrat. Confirmez que le rejet de la porte renvoie une erreur 4xx pour stopper le réessai.

Commencez avec IOSOR

Dans la console: Signature + replay window gate before first webhook accept.. Nommez le propriétaire et les portes avant d’élargir.

Lié: webhook signature replay window inbound sms webhook retries idempote.

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