Convenience-Store Pickup Logistics: The Right Way to Handle Changed Orders and Amounts

Convenience-store pickup (7-Eleven/FamilyMart) is standard equipment for Taiwanese e-commerce, and ECPay's logistics API isn't hard to integrate — follow the docs, create the shipment, print the label, ship, and you're through in a day. The real trouble starts after launch: the customer says "I want to add one more box," support says "this order needs to switch to cash on delivery," the warehouse says "the label printed wrong, reprint it." That's when you discover the hardest part of convenience-store logistics isn't the integration — it's changes.

Our own store ships convenience-store parcels every day, including cash on delivery. What follows are notes paid for with real orders.

The core concept: logistics orders have no "edit" — only "void and recreate"

Install this mental model first and everything else follows: once a logistics order is created, its amount and key details cannot be changed. To change anything, you void the old order and create a new one. There is no third option. Once that clicks, the system design direction is obvious — what you build isn't an "edit logistics order" feature; it's a "safely void and recreate" feature.

The right way to change a cash-on-delivery amount

The most common scenario: the customer wants to add or swap items after ordering, the amount changes — but it's cash on delivery and the logistics order already exists. The correct flow:

1. Void the original logistics order;
2. Create the new order with a brand-new transaction number — this is the easiest landmine to step on: a MerchantTradeNo, once used, can never be reused, even if the original order was voided. Our approach is a serial suffix on the order number, incremented on every reissue;
3. Create the new order at the updated amount and obtain a new shipping code;
4. Record the link between old and new orders — reconciliation depends on being able to trace it back.

Related: when the amount changes, the e-invoice must also be voided and reissued. Handle both together, or your books won't reconcile.

Make void-and-recreate a one-click back-office action

Running this flow manually means touching the API two or three times and remembering the invoice on top — have support verbally direct an engineer through it and something will eventually go wrong. Early on, we had exactly that: the logistics order was recreated but the invoice was never voided, discovered only at month-end reconciliation, and patching the paperwork took several times longer than doing it right would have. So we wrapped the whole sequence into a single back-office button: support edits the order and clicks; the system voids the old order, generates a new transaction number, recreates the logistics order, handles the invoice in sync, and writes every step to the audit log. Once that feature existed, "changing an order" went from an engineering task back to a support task — which is what a system is supposed to do.

A few more field notes

• Use the newer API for logistics status queries. We originally used the old query, whose status fields were incomplete — we couldn't tell where a parcel was actually stuck. Switching to the V5 query finally gave us full status. Confirm the doc version before integrating.
• Store codes go stale. Convenience stores close and get rebuilt; the store the customer chose may no longer accept parcels by ship time. Shipment-creation failures need explicit error handling that guides the customer to pick a new store — not an order stuck in the warehouse waiting on a store that no longer exists.
• Pickup deadlines and returned parcels need a process. Unclaimed after seven days, the parcel comes back. Restocking returned parcels, refunds (for unclaimed cash on delivery, it's uncollected payment), and invoice handling all need designing in advance — don't improvise when the first return shows up. Arrival-reminder messages (we send them via LINE) measurably reduce the unclaimed rate and are worth doing.
• Test-environment logistics is fake. No parcel actually enters a store in the test environment; shipping, pickup, and returns only happen for real in production. Before launch, ship a real order to yourself and experience the whole journey — it's a fixed item on our pre-launch end-to-end testing checklist.

Getting it connected only means you finished the docs; being able to change and reverse orders means you're actually operating.

Logistics, payments, and invoicing are a trinity — any change to one pulls on the other two. If your system currently handles order changes via "an engineer does it manually," it may be worth a conversation — our e-commerce build services treat these change scenarios as standard scope, and you're welcome to contact us directly.