Automation · 05

Payment API Automation: Handle Duplicate Events Before Accounting Integration

Payment notifications may be retried. Deduplication, source verification and reconciliation prevent one transaction from creating multiple accounting records.

A payment webhook test worksheet for repeats, invalid signatures, interruptions and refunds; not test results.
Friday Works / Journal05 · 2026
ContentsTap to jump to a section
  1. 01One payment can produce repeated delivery
  2. 02Separate delivery from business completion
  3. 03Verify before updating orders
  4. 04Test controlled failures
  5. 05Reconcile missing work too
Summary
The one-minute brief
  • A repeated event is not a new payment.
  • Verify a notification before changing an order.
  • Reconcile payments and accounting records during acceptance.
01

One payment can produce repeated delivery

A provider may retry a payment notification after a network or receiver failure. A receive-and-create implementation can therefore duplicate business records.

A webhook is a server notification sent to a registered endpoint. Stripe is a documented example; other providers have their own contracts.

02

Separate delivery from business completion

Friday Works recommends recording event and transaction identifiers, receipt time and processing outcome. Distinguish received, processing, completed and review-required states.

Deduplicate by the business operation as well as the notification. Multiple event types can legitimately refer to one payment. Define eligible states, refunds and retry ownership.

03

Verify before updating orders

Stripe documents signature verification, duplicate deliveries and event-order considerations. Apply the actual provider’s verification mechanism before changing payment status.

Keep verification secrets server-side and separate test and production. Reject invalid notifications without logging unnecessary sensitive data.

04

Test controlled failures

In the approved test environment, replay an event, change delivery order and interrupt the accounting response. Inspect resulting orders and records.

If a record was created before completion tracking failed, a retry must reconcile that result before creating another. Use provider idempotency mechanisms within their documented limits.

05

Reconcile missing work too

Deduplication alone cannot detect every missing transaction. Compare provider payments, orders and accounting records periodically, with amounts, waiting time and an accountable owner.

Document safe retries and exceptions. For MISA or another ERP, validate its actual API and service-account permissions rather than assuming a built-in deduplication feature.

References

Sources used in this guide

We prioritise official guidance and primary technical sources. Visit each source for full context and the latest updates.

  1. Receive Stripe events in your webhook endpointStripe
  2. Idempotent requestsStripe
  3. Original acceptance worksheet, 16 October 2026; screenshot of an authored document, not a completed testFriday Works

Written and reviewed by

Friday Works technology team

A perspective shaped by designing websites, building software, automating operations, integrating AI and assessing security for businesses.

Content is reviewed to reflect methods that can be applied in practice. We update it when the process, technology or underlying evidence changes materially.

About Friday Works