Sync Website ↔ Pancake — never oversell your stock, never lose an order
D-Solutions has delivered Pancake integrations for numerous fashion & FMCG clients. Real-time two-way inventory sync, race-condition protection, self-service shipping tracking for customers — all built in, not a bolted-on plugin.
3 pain points multi-channel shops face without proper sync
Overselling stock during sales
The website shows stock available, the customer orders successfully → Pancake shows it's out of stock → the shop has to call and apologize, cancel the order, and lose credibility. The bigger the sale, the worse it gets, since the odds of a race condition go up.
Stock mismatch between Website and Pancake
Staff confirm orders in Pancake, but it never syncs back to the website → the site keeps showing outdated stock → customers order → the mismatch grows worse. Every weekend means hours of manual reconciliation.
Customers asking "where's my order?"
Tracking codes are stored in Pancake, but the website has no idea. Customers call in → support staff look it up in Pancake → then reply. It burns staff time and frustrates customers, especially during peak hours.
Defense-in-depth — 3 sync layers, never trusting webhooks alone
Webhooks can drop. Networks can glitch. Pancake can go down for maintenance. We build 3 layers of defense so data never drifts more than a few minutes, even in the worst case.
Webhook real-time (primary)
~ a few secondsPancake updates stock → immediately fires a webhook to the website. The website creates an order → fires a webhook back to Pancake. Both inbound and outbound webhooks include signature verification and an idempotency check (storing event_id for 7 days to avoid duplicate processing), processed via an async queue so responses are never blocked.
REST polling fallback
every 5 minutes
When webhooks fail (Pancake outage, network issues), the website actively polls the Pancake API every 5 minutes to check for deltas,
with exponential backoff on errors. A cron job checks last_webhook_received_at, and if it exceeds the threshold, polling kicks in automatically.
Reconciliation cron
nightly at 02:00
Every night: compare the full inventory between Website and Pancake. Any mismatch is logged, triggers an alert, and auto-syncs
(Pancake is the source of truth). Every delta is stored in wp_stock_audit for traceability
— where it drifted, when, and by how much, all with an audit log.
Reservation pattern — temporarily holding stock the moment a user hits buy
When only 1 unit is left and two sides try to confirm it at once, the system resolves it on a clear, ordered timeline. No "figuring it out later" or leaving it to chance.
- T0
Customer A visits the product page
Stock shows 1. No one has confirmed yet.
- T1
Customer A clicks "Buy now"
The website creates a 15-minute reservation inside a DB transaction (
SELECT FOR UPDATEInnoDB row-level lock) + calls the Pancake reserve API. - T2
Customer B visits the same product
Stock shows 0 (since A already reserved it). The UI shows "Just sold out" and recommends a similar item.
- T3
Staff try to confirm in Pancake at the same time
Pancake checks stock = 0 → rejects it and shows “an online customer is currently checking out”. Pancake is the source of truth for final stock.
- T4
Resolved
If A completes checkout: the reservation converts into a confirmed order, and Pancake receives the webhook → deducts the real stock.
If A abandons cart: the reservation TTL expires after 15 minutes → stock returns to 1 → B or staff can confirm it.
Self-service tracking — cutting 50-70% of "where's my order?" calls to support
Pancake
Receives updates from GHN / GHTK / J&T / SPX via API or webhook.
Webhook to the website
The /api/shipping-update endpoint receives it and saves it to order meta (tracking code, carrier, status).
Customers self-track
The /tra-cuu-don-hang/ page + transactional email + (optional) SMS / Zalo ZNS whenever status changes.
Frequently asked questions about Pancake integration
How does inventory sync between the website and Pancake actually work?
D-Solutions uses a 3-layer architecture: real-time webhooks as the primary channel (a few seconds of latency), REST polling as a fallback when webhooks fail, and a nightly reconciliation cron job. We never rely on a single mechanism — webhooks can drop, polling can lag, but combining all three layers ensures data never drifts more than a few minutes even in the worst case.
Pancake is always the source of truth for final stock levels — since that's where staff make the most manual changes. The website only “holds” stock temporarily via the reservation pattern; it never deducts real stock until the order is confirmed.
If only 1 unit is left in stock and a customer orders on the website while staff confirm the same item in Pancake at the same time — what happens?
D-Solutions prevents overselling with a reservation pattern. When a customer adds to cart or starts checkout, the website creates a 15-minute reservation inside a DB transaction with a row-level lock, plus a call to the Pancake reserve API. If staff try to confirm the same item in Pancake at the same moment, they'll see stock = 0 and a message that “an online customer is currently checking out” — the action gets blocked.
If Pancake doesn't support the reserve API (depends on the plan/version), we can shrink the risk window down to a few seconds but can't reach an absolute 0% — D-Solutions states this plainly rather than making empty promises. In practice, race conditions at this level are extremely rare; when they do happen, the system rejects the later order with an HTTP 409 and automatically recommends a similar product to the customer.
Can customers check their shipping status directly on the website?
Yes. Pancake fires a webhook whenever the shipping carrier updates status (handed to carrier, out for delivery, delivered, returned) → the website receives it and saves it into order meta. Customers visit the /tra-cuu-don-hang/ page, enter their phone number + order code, and see a clear visual timeline. Every status change also automatically triggers a customer email — significantly reducing the load on the shop's support line.
Fallback: if Pancake hasn't fired the webhook yet, the website can call the carrier's API directly (GHN, GHTK both offer public APIs) using the tracking code already stored on the order, so customers always see the latest information.