Synthetic, no-network acceptance resource for a website integration brief. No merchant, warehouse or payment account was accessed. It checks supplied records, not live stock or refund rights.
Ask the supplier to replay a return, not just show a green status
Before accepting a Shopify-to-warehouse integration, ask what happens if the same stock event arrives twice and what happens if another system creates a second stock event for the same business operation. Those are different failures. A refund record alone is not evidence that an item reached the warehouse or became saleable.
A merchant described suspected duplicate restocking after a warehouse move in a 22 March 2023 Shopify Community question. The original post is a historical problem statement, not a verified diagnosis. The example below is new fictional data, not that merchant's order.
One filled record, two different replay tests
Assume a single fictional return line, R-DEMO-90-L1, at WH-DEMO. Two units are requested and received. Only one has a supplied resale approval. A separately supplied financial record reports two units refunded. The model deliberately does not require refunded and restocked quantities to match; it makes no judgement about whether that refund should occur.
| Supplied event | Quantity / reference | Expected observation |
|---|---|---|
| WH-1: warehouse receipt | 2; synthetic receipt evidence | Received quantity 2, saleable stock still not inferred |
| QA-1: resale approval | 1; synthetic approval evidence | Only one approved unit is available to the model's stock check |
| MOVE-1: stock record | 1; approval QA-1; operation R90-L1-RESTOCK-ONE | Reported stock quantity 1 |
| RF-1: refund record | 2; synthetic financial evidence | Reported refund quantity 2; adds no stock |
| Exact repeat of MOVE-1 | Same ID and identical record | Duplicate noted; counted once in this finite report |
| MOVE-2 for that same operation | Different event ID, same business operation | REVIEW: possible second stock operation and approval overrun |
Run the supplied evidence checker
Download the Node checker, duplicate-operation input and single-movement input into one folder. With Node 22.13 or newer:
node return-event-check.mjs --test
node return-event-check.mjs broken.json
node return-event-check.mjs corrected.jsonThe broken input produces REVIEW, identifies a repeated business operation and reports stock exceeding its referenced approval. The corrected input produces SUPPLIED_RECORDS_CONSISTENT, stockQty 1 and refundQty 2. This means only that these supplied records do not contradict the model's finite rules. It does not certify complete records, real receipt, a successful refund or actual inventory.
Keep a failed record intact while investigating. An operator must not erase a real stock movement to make this report pass. The corrected JSON is a separate teaching scenario, not a repair instruction for a merchant ledger. BLOCKED means the scope is invalid; REVIEW preserves uncertainty rather than silently calculating a clean result.
What belongs in the integration acceptance brief?
- Agree the return-line and location identity, quantity units and which system owns each business operation.
- Keep transport event IDs separate from the business-operation reference. Two systems can use different IDs for one intended movement.
- Provide a redacted approval reference for each stock record, then test exact replay, conflicting reused IDs, a second operation and partial approval.
- Test actual delivery order, durable deduplication, authentication and reconciliation separately in an authorised test environment.
This checker normalises no real Shopify payloads, writes no stock, verifies no signatures, retains no durable deduplication ledger and does not process event timing. A repeated ID counts once only within the supplied in-memory report. A production supplier must demonstrate its own mappings and persistence; this download is not a ready-to-install integration.
Official facts and version limits
Reviewed 15 October 2026: Shopify's returns-app guide describes the return lifecycle and reverse fulfilment work. The returnProcess reference displayed 2026-10 as latest, with explicit access requirements, disposition handling and optional refund processing. Its latest URL can change; an implementation needs its own supported version and permissions review. None of those API facts authenticates a physical warehouse event.
The event names, authority rule and expected quantities here are original teaching design, not Shopify webhook payloads or a claim that every 3PL has the same interface. This is not a returns-policy, consumer-rights or accounting decision. For the separate inspection and disposition decision, use the existing worked warehouse return branches.
A useful starting point for a website enquiry
Bring the store platform, warehouse connector, agreed stock owner and one fictional or properly redacted replay scenario. Ask the website supplier to demonstrate the expected failure as well as the happy path. Keep customer data, credentials and real financial exports out of a public enquiry attachment.