Reliable Webhooks When Syncing Orders to a New Platform

When NCR Retail Online was retired, hundreds of Australian retailers discovered that the integration plumbing behind their online stores was not as sturdy as they had assumed. Orders that used to land in Counterpoint within seconds started arriving in bursts, in the wrong order, or not at all, particularly during the November trade weekends that retailers in Sydney, Melbourne, Adelaide and Brisbane rely on for a large share of annual revenue.

Webhook-driven order sync looks simple on paper: the new platform POSTs a JSON payload to your endpoint, and your back office processes it. In practice, a webhook is a contract between two systems that may live on different clouds, across different time zones, and behind different versions of carrier networks. Once you understand the moving parts, you can design an integration that tolerates the inevitable blips.

For retailers moving from NCR Retail Online to Magento, WooCommerce or another stack through an NCR Counterpoint partner, the conversation usually starts with checkout behaviour and ends with stock accuracy. Webhook reliability sits in the middle, and getting it right determines whether GST line items, Australia Post fulfilment updates and end-of-day till reconciliations stay clean during the cutover.

This guide walks through the failure modes, retry strategies, security checks and observability habits that separate a fragile order pipeline from one that survives peak trading, NBN outages and the quirks of AEST and AEDT scheduling.

Webhooks versus polling in retail order flows

A webhook is an event-driven push: the source system sends a notification the moment something happens, such as a new paid order, a refund or a fulfilment update. Polling, by contrast, requires your system to ask the source "are there any new orders?" on a schedule, often every minute or every five minutes. The two approaches feel interchangeable, but the operational differences are significant once order volume climbs.

For most Australian mid-market retailers, a hybrid model works best. Webhooks carry the immediate order, fulfilment and refund events into the back office, while a periodic reconciliation job, ideally timed for early morning AEST before stores open, catches anything that slipped through. That early-morning slot also lines up neatly with the start of a new business day across Brisbane, Sydney, Canberra and Melbourne, reducing the chance of an after-hours conflict during daylight saving transitions.

Common failure modes during platform cutover

Cutover week is when most webhook incidents surface, because the new platform is sending real traffic for the first time and the receiving endpoint has not yet absorbed a full day's pattern. The failures cluster into a handful of recurring shapes that Australian integrators see again and again.

The first is DNS or TLS misconfiguration. A new endpoint is provisioned, the certificate is issued to the wrong subdomain, and the platform's HTTP client rejects the handshake. The second is signature verification drift, where the new platform rotates a signing secret and the back-office code still validates against the old value. The third is payload schema change, where field names move from snake_case to camelCase, or where a previously nested address object becomes flat. The fourth, and often the most damaging, is silent truncation when an upstream proxy buffers the body past a size limit and forwards an empty payload that still returns a 200.

Regional networking adds another layer. NBN services in outer suburbs of Perth or in parts of regional Queensland can drop TCP connections more aggressively than the fibre-to-the-premises links common in central Sydney and Melbourne CBDs. A webhook receiver that holds a connection open for too long will appear healthy in a synthetic test from a city data centre but will fail under real conditions from a regional link.

Retry logic, backoff and dead-letter queues

Once you accept that webhooks will fail, the question becomes how your system recovers. A naïve "retry every ten seconds for ten minutes" loop will quickly overload a struggling endpoint and turn a transient blip into a self-inflicted outage. The well-trodden answer is exponential backoff with jitter, where each retry waits progressively longer and is offset by a small random delay to prevent retry storms.

For order events, a typical schedule starts at fifteen seconds, doubles to thirty, then sixty, then two, four and eight minutes, before parking the message in a dead-letter queue after roughly thirty minutes of cumulative effort. The dead-letter queue is not a failure state; it is a triage state. A well-designed queue stores the original payload, headers, signature, the response status from each attempt, and an audit trail that an operator in Adelaide can read the next morning without having to dig through logs in three places.

When the endpoint recovers, replaying the dead-letter queue in arrival order usually restores full consistency within a few minutes. The key is that replay must be safe to run more than once, which brings us to the most underrated property of a reliable webhook pipeline.

Idempotency keys and deduplication

Webhook providers do not guarantee exactly-once delivery. Most expose at-least-once semantics, which means your endpoint will occasionally receive the same order event twice. If your handler creates a sales order in Counterpoint on every call, you will end up with duplicate invoices, GST double-ups and reconciliation headaches the next morning.

The fix is an idempotency key. The new platform includes a stable identifier, often the order number or a UUID generated at order creation, in every webhook payload. Your handler computes a hash of that key, stores it in a fast lookup table with a short retention window, and short-circuits if the key has already been processed. Redis, SQLite or even a simple file-based store works for stores processing under a few thousand orders a day, which covers most Australian specialty retailers.

Idempotency also protects you during manual replays. When an operator in Brisbane replays a dead-letter batch after a counter migration, the system quietly skips anything that has already been recorded and only creates the genuine new orders. This is the same pattern used by Stripe, Shopify and most modern commerce APIs, and it maps cleanly onto the order lifecycle in Counterpoint.

Securing the endpoint: signatures, IP allow-lists and TLS

A webhook endpoint is a public door into your back office, and the moment it accepts an order payload it should treat that payload as production data. Three layers of defence are worth the small upfront cost.

The first is TLS with a modern certificate, served from a subdomain dedicated to integrations rather than the main store. The second is signature verification using a shared secret rotated on a schedule; the new platform will sign the body with HMAC-SHA256 and include a timestamp header to defeat replay attacks. Your code should verify both the signature and that the timestamp falls within a five-minute window. The third layer is an IP allow-list where the platform publishes the ranges from which webhooks originate, narrowed further to the country code you expect.

For Australian retailers subject to the Privacy Act and the Notifiable Data Breaches scheme, these controls are not optional polish. They form part of the reasonable steps you are expected to take to protect personal information, and they will appear in any audit after an incident. Treat the webhook secret with the same care as your database credentials.

Observability: logging, alerting and reconciliation in AEST

Reliability without observability is just hope. Every webhook handler should emit structured logs that capture the event ID, order number, processing duration, signature verification result and final status. A central log store, whether that is a managed service or a self-hosted stack, lets you answer the two questions that always come up during a cutover: did we receive it, and what did we do with it?

Alerts should fire on three signals: rising error rates over a fifteen-minute window, dead-letter queue depth above a threshold, and reconciliation drift between the source platform and Counterpoint. The reconciliation job, run at 02:00 AEST or 03:00 AEDT during daylight saving, compares the previous day's orders on both sides and flags any that exist in one system but not the other. Time zone awareness matters here; a job that runs at "2am" in the wrong zone will land in the middle of the lunchtime rush in Perth and slow down the very traffic it is meant to monitor.

If your team is small, a weekly review of the dead-letter queue and the reconciliation report is usually enough. If you process more than a few thousand orders a day, a real-time dashboard on a wall-mounted screen in the store's back office makes the invisible integration layer visible to the people who feel its pain first, and streamlining back-office operations before cutover gives the on-call team a clear playbook when an alert fires at 3am AEDT.

Practical migration path from NCR Retail Online

For retailers leaving NCR Retail Online, the most reliable webhook pipelines share a common shape. The new platform, often Magento or WooCommerce set up through an NCR Counterpoint partner, publishes order events to a small integration service hosted in Australia or in a nearby region. That service verifies signatures, applies idempotency checks, writes the order into Counterpoint, and emits its own audit event. A nightly reconciliation job closes the loop and alerts the team to anything that needs a human look.

Two pieces of supporting work make the difference between a smooth cutover and a painful one. The first is having clean customer and product data in the new platform before go-live, so that the very first webhook payload can be processed without manual fixing. The second is investing in automated low-stock alerts so that the order pipeline is not the only signal keeping inventory honest; when a webhook is delayed, the stock alert is the safety net that prevents overselling during a weekend rush in Sydney or a sale event in Melbourne.

The practical takeaway is short: design for retries, design for duplicates, design for the network you actually have, and give your team the visibility to act before a small blip becomes a Monday morning reconciliation fire.