Make conversion and refund events reliable

Before you begin

A received event is not yet a correct commission. Messages can repeat, refunds can arrive before processing finishes and a service can respond while business recording fails. This method helps programme and integration owners define necessary evidence. Confirm transport properties in your provider’s documentation; Stripe is used here as a documented technical example.

Separate three identifiers

Distinguish message ID, business-operation ID and partner ID. The first identifies another delivery of the same message, the second connects orders, invoices, cancellations and exports, and the third carries attribution. Add event type, version and business timestamp to the test record. Do not infer a reliable order identifier from a monetary amount and customer address.

Verify before processing

Use the provider’s documented authenticity mechanism, including signature verification where available. Do not change secrets or their configuration as part of an editorial acceptance test. Define what is recorded after an invalid signature and avoid personal information in public logs. A successful HTTP response does not prove authenticity or successful business processing.

Make retries safe from duplicate effects

Specify what happens when an event returns: retrieve the existing result rather than create another commission. Keep processing evidence linked to the business operation. API idempotency keys and inbound-event deduplication address different problems. Stripe documents them separately; do not assume one automatically protects the other.

Handle events arriving out of order

Transport may not guarantee the expected sequence. Describe a refund received before its order exists locally. Prepare controlled waiting or retrieval from the source system where supported. An older update should not overwrite a newer state without an explicit rule. Preserve occurrence and receipt times to explain chronology.

Test failure and recovery

In an authorised environment, simulate unavailability, delayed responses and repeated receipt. Check the provider’s retry limits and timing. Manual replay may coexist with automatic retry; understand their interaction. Define who can replay an operation, required evidence and post-processing checks. The goal is a single business effect, not merely a successful message status.

Reconcile with business records

Regularly compare source orders and invoices with eligible platform operations. Distinguish normal delay, documented rejection and actual loss. Reconcile counts and amounts by currency: one monetary total can conceal duplicates offset by missing records. Preserve end-to-end identifier samples for purchases, partial refunds and cancellations.

Prepare useful incident evidence

For each discrepancy, collect business reference, event type, timestamps, version, expected state and observed state without exposing secrets. Identify the first divergent step. Link the record to the tracking incident method and assign an owner and resolution deadline. After correction, replay neighbouring cases as well: fixing refunds must not duplicate purchases.

Practical answers

Questions to settle before signing