Logistics Integration in Taiwan: Convenience-Store Pickup, Home Delivery, and Status Callbacks
On an e-commerce requirements list, “integrate shipping” usually takes up a single line. In practice it turns out to touch the checkout page, the fulfillment workflow, customer support lookups, returns and refunds, and the monthly reconciliation.
What makes it harder still is that logistics, unlike payments, is not a single success or failure. It is a process that runs for days and can move backwards. This guide covers the delivery types common in Taiwan, what integration actually involves, and the problems that most often surface only after launch.
Start by separating the delivery types common in Taiwan
Different delivery types make very different demands of a system:
Convenience-store pickup. The customer designates a store at checkout, the parcel is delivered there, and the customer collects it themselves. It comes in two forms, with and without payment on collection; the former is effectively cash on delivery, with the store chain collecting the money and remitting it to you later, which pulls payment reconciliation into scope. This is the most common option in Taiwan, and the most complex one to build.
Home delivery. The parcel goes to the address the customer entered. The flow is relatively simple, but you still have to handle preferred delivery windows, remote areas, and restrictions on oversized items.
Store-to-store, with the seller dropping off. The seller takes the parcel to a store counter to send it, so what the system needs to produce is the drop-off information the store can scan, not a courier waybill.
Chilled and cold chain. Common for fresh food. Beyond specifying the temperature band when the shipment is created, the restrictions on serviceable areas and delivery windows are tighter than for ambient goods, so the product page has to block undeliverable combinations up front. Discovering after the order is placed that it cannot be shipped is expensive to unwind.
Large items and delivery with installation. Furniture and appliances that need two people to carry or on-site assembly usually fall outside a standard shipping label. The common approach is to schedule them manually and have the system only record the status.
When you scope the work, list the products you will actually sell and the ways you will actually ship them, then decide which types the first version has to support. Trying to support all of them at once is usually where the schedule starts to slip. For the wider platform decision, start with Building an E-commerce Site.
”Integrating shipping” is really four separate jobs
Many people assume integration means “send the order out.” In practice there are at least four stages, and leaving any one of them out breaks the chain:
| Stage | What it does | Where it usually gets stuck |
|---|---|---|
| Creating the shipment | Sending order data to the carrier and getting a tracking number back | Address formats, store codes, missing weight and dimensions |
| Producing the waybill or label | Printing a scannable document or label | Print formats, batch printing, how fulfillment staff actually move |
| Status callbacks | The carrier pushing delivery progress back to your system | Delayed notifications, duplicate notifications, mis-mapped status names |
| Returns and reverse logistics | Handling customer returns and uncollected parcels | Refund timing, who absorbs the shipping cost, restoring stock |
The fourth is the one most often overlooked. Everybody remembers to test shipment creation and dispatch during development; returns are frequently encountered for the first time after launch. And once an uncollected parcel comes back, whether a refund is due, who absorbs the shipping cost, and when stock is restored are business rules rather than technical questions. They have to be settled by the business side during requirements. For how to get rules like these written down, see How to Write Software Requirements.
A logistics aggregator, or a direct carrier integration
Both routes have situations they suit, and neither is categorically better:
Through a logistics aggregator. One interface gives you several shipping options at once, with the store map, tracking number generation, and status callbacks all coming from the same provider, which cuts the development work noticeably. It suits teams with a simple product range, a desire to launch quickly, and no dedicated technical staff. The trade-off is that your process has to fit inside what the provider supports, and some unusual requirements may simply not be possible.
Contracting and integrating directly with carriers. You get more flexibility on service terms and process design, and you can negotiate on the strength of your own volume. But every carrier has its own documentation, status definitions, and test environment, so you are effectively doing the integration several times over, and you have to consolidate the reconciliation yourself. The development and operational resources required are clearly higher.
In practice a common pattern is to launch on an aggregator, then, once volume and process have settled, assess whether to move the main carrier to a direct integration. The reasoning closely mirrors the provider-versus-direct trade-off described in the guide to payment gateway integration in Taiwan, and the two are often evaluated together.
One caution: carriers adjust their service coverage, technical specifications, and application conditions over time. Plan against each carrier’s current official documentation rather than relying on older third-party summaries.
Designing status sync and support lookups
When a customer asks where their order is, support needs to see the answer in one place in your own admin system, not by opening five carrier websites in turn. For that to work, the system needs:
- Orders and shipments linked to each other. A single order may be split across several parcels, so the data model has to allow one-to-many. Otherwise split shipments will never reconcile.
- A history of status changes. Storing only the current status makes exceptions impossible to trace. Record the time and the source of every change.
- Your own status vocabulary. Carriers name their raw statuses inconsistently, so the storefront should display a unified set of stages the customer can understand.
- A self-service lookup for customers. Showing progress on an order tracking page or in the member area absorbs a meaningful share of support messages.
If you already have member accounts, feeding shipping status into the member order page is the least effortful option; for the design principles, see Building a Membership and CRM System. If most of your support happens in messaging apps, the lookup can be turned into an automated reply, as described in The LINE Bot Development Guide. LINE is the dominant messaging app in Taiwan, and many brands run customer service through it.
Reconciliation and exceptions: where the time actually goes after launch
Shipping accounts are more fragmented than payment accounts, because the fee varies with dimensions, weight, region, temperature band, and returns. At minimum, confirm three things while planning:
How shipping is calculated and who absorbs it. The shipping fee shown to the customer at checkout and the amount you actually settle with the carrier are not necessarily the same. The gap needs to be visible, or over time it will erode your margin with nobody noticing.
Who bears the cost of returns and uncollected parcels. This is money nobody usually counts, and it is not small once it accumulates. Settle the business rule first so the system knows which fields to record.
How the monthly invoice is checked against your own records. Carriers supply reconciliation files in different formats. If your volume is already meaningful, build the import and comparison as a feature from the start rather than handling it in a spreadsheet every month. It is more complete when viewed alongside invoicing; see the guide to e-invoice integration in Taiwan.
For exceptions, it helps to maintain an explicit list: incomplete addresses, a store temporarily not accepting parcels, lost parcels, damage, customer refusal, and return after the collection deadline. Each needs an owner and a standard set of steps, with a record of the handling kept in the system.
The scenarios to test before launch
Testing shipping cannot stop at “the shipment was created successfully.” Walk through each of the following and put them in your acceptance criteria:
- The full path from a normal order to a completed collection
- The customer changing store or address, where that is allowed
- Whether an order status gets stuck when the carrier callback fails or is delayed
- One order shipped in several batches
- Automatic return of an uncollected parcel, and the refund and stock restoration that follow
- Processing speed when a large batch of shipments is created at once
- The discrepancy report between an imported reconciliation file and your own records
For acceptance method and defect severity, see How Software Acceptance Works; for the full pre-launch sweep, see The Website Launch Checklist. If you also run physical stores, integrating stock and fulfillment brings in the considerations described in the POS and Retail System Development Guide.
The difficulty of shipping integration is not technical. It is process and rules. Settle the product types, the shipping methods, the returns policy, and who bears which cost, and development is simply a matter of writing the rules down as code. Go the other way and enter development with vague rules, and every exception after launch becomes an improvised decision.
If you are evaluating shipping options for an online store, or fulfillment and reconciliation in your current system are starting to consume real headcount, talk to NETVANA about your logistics integration. NETVANA’s software services are quoted individually rather than sold as fixed packages, and we clarify process and scope before discussing numbers; for what each service includes and delivers, see the software services overview.
Further reading: for choosing an e-commerce route, start with Building an E-commerce Site; for the trade-offs on the payment side, see the guide to payment gateway integration in Taiwan; for the general risks and acceptance criteria of connecting to outside systems, see A Guide to System Integration and API Development; for integrating fulfillment with in-store inventory, see the POS and Retail System Development Guide; and for the complete pre-launch inventory, see The Website Launch Checklist.
