Shopify Courier Integration for Bangladeshi Stores

Shopify makes it easy to launch a polished store from Dhaka, but the moment a customer places a cash-on-delivery order, you hit the gap every Shopify courier Bangladesh setup has to bridge: Shopify was designed around card payments and international carriers, while your reality is COD parcels handed to Pathao, Steadfast, RedX, or a local courier. Out of the box, nothing connects your Shopify admin to that courier — so orders get retyped into courier dashboards by hand, and tracking lives in screenshots.

This guide explains how to close that gap properly: setting up COD in Shopify, the three integration approaches available to Bangladeshi stores, how the order-to-courier flow works technically, and how to get delivery statuses and tracking back into Shopify. Code samples are illustrative pseudocode — your courier’s official API documentation defines the actual endpoints and fields, and Shopify’s own developer docs define its APIs. Verify against both.

First, get COD right in Shopify

Before any courier integration, your store needs to accept COD cleanly. Shopify supports this through manual payment methods — you enable a manual method (commonly labeled “Cash on Delivery”) so orders can complete checkout without card payment. Two practical consequences:

• COD orders arrive as unpaid/pending. Your integration and staff must treat “payment pending” as normal, and only mark orders paid after the courier actually remits the cash — not when the parcel is delivered.
• Fake orders are a real cost. With no payment at checkout, anyone can place an order. Phone confirmation before pushing to the courier is standard practice in Bangladesh; build your integration to trigger on a “confirmed” signal (a tag, a metafield, or a manual action), not on raw order creation.

Three ways to set up a Shopify courier Bangladesh integration

1. Courier or third-party apps. The Shopify App Store has apps for some local couriers, and some couriers offer their own. Check what each app actually does: pushing orders is table stakes; status sync back into Shopify and fulfillment updates with tracking are what save you support time. Also check how the app handles multi-courier routing if you use different couriers for inside and outside Dhaka.

2. A custom app you control. Shopify lets you create a custom app for your own store with API credentials scoped to what you need (orders read, fulfillments write). Your small backend service — a few hundred lines on any cheap host — subscribes to Shopify webhooks, calls the courier’s API, and writes results back. Most flexible, and the right choice for stores with volume, custom rules, or multiple couriers.

3. A courier whose platform does the work. Couriers running Drix expose a standardized merchant API — token auth, create-order, tracking lookup, and status webhooks — plus a merchant panel where your team can manage parcels without touching code. When your courier offers that, your custom app shrinks to a thin translator between Shopify’s webhook and one well-documented API.

If you are still choosing which courier to integrate with in the first place, our guide to the best couriers for F-commerce sellers compares the options merchants actually use.

The order flow, end to end

A robust Shopify-to-courier pipeline looks like this:

Shopify checkout (COD)
  -> orders/create webhook -> your service (or app)
  -> phone confirmation step (tag order "confirmed")
  -> your service builds courier payload
  -> POST to courier create-order API   (per official courier docs)
  -> consignment ID saved to the Shopify order (metafield / note / fulfillment)
  -> courier status webhooks -> your service
  -> Shopify fulfillment updated with tracking info
  -> customer notified; COD reconciled at settlement

The confirmation gate deserves emphasis: subscribing to the raw order webhook and pushing instantly to the courier means every fake order costs you a real pickup and a real return charge. Trigger on your confirmation signal instead.

The payload itself is the same data every Bangladeshi courier needs:

{
  "merchant_ref": "SHOPIFY-1042",
  "recipient_name": "Customer Name",
  "recipient_phone": "01XXXXXXXXX",
  "recipient_address": "House, Road, Area, District",
  "cod_amount": 2150,
  "items_summary": "2x T-shirt (L)"
}

Field names are illustrative — map them to whatever your courier’s official API specifies. Two Bangladesh-specific data issues to handle before sending:

• Phone normalization. Shopify stores whatever the customer typed. Normalize +880 and 880 prefixes to the 11-digit 01XXXXXXXXX form and validate before submission.
• Address structure. Shopify’s address fields (address1, city, province) rarely match how Bangladeshi couriers think about zones and areas. Concatenate carefully, and if your courier’s API uses structured location references, maintain a mapping from district/area text to those references.

Getting tracking back into Shopify

This is where Shopify integrations can genuinely shine, because Shopify has a first-class fulfillment concept. When the courier confirms pickup, your service creates a fulfillment on the order including the tracking number (the consignment ID) and a tracking URL. Shopify then shows tracking on the customer’s order status page and in notification emails automatically — no custom customer-facing UI needed.

For the tracking URL, point customers at a page that actually updates. If your courier runs on Drix, every consignment has a live tracking page powered by the platform’s parcel tracking — status timeline from pickup to delivery, the same view your own team sees.

Then handle status changes over the parcel’s life:

• Delivered — record the delivery timestamp and add the COD amount to your receivable ledger for that courier.
• Partial delivery — the collected amount differs from the invoice; store both, because settlement will only include what was collected.
• Returned — trigger your restocking flow and note any return charge.
• Stuck parcels — anything unchanged for too many days should surface on a follow-up list before the customer calls you.

Marking the Shopify order as paid should follow the money, not the status: cash is yours when the courier settles, and settlement statements never match delivered lists perfectly on the first pass. That parcel-by-parcel matching is exactly what COD management in Drix automates — delivered COD versus remitted cash, with discrepancies flagged instead of buried in a spreadsheet.

Edge cases checklist for Bangladeshi Shopify stores

• Multi-courier routing — inside-Dhaka orders to one courier, outside-Dhaka to another; implement it as a routing rule in your service keyed on district.
• Duplicate webhooks — Shopify may deliver a webhook more than once; deduplicate by order ID before creating consignments.
• Order edits and cancellations — an order edited after being pushed must flag a mismatch; a cancellation must cancel with the courier before pickup.
• Exchange parcels — replacements for returned items need their own consignment tied to the original order.
• Peak load — Eid campaigns multiply order volume; queue courier API calls rather than firing them synchronously from webhook handlers.

Stores on WordPress face the same architecture with different plumbing — see our WooCommerce courier integration guide for that ecosystem.

The bigger picture

The pattern across every successful Shopify courier Bangladesh setup is the same: a confirmation gate before pushing, one clean API call per parcel, fulfillments carrying real tracking, and money reconciled at settlement rather than assumed at delivery. None of it is difficult — but all of it depends on your courier offering a real API. Couriers running Drix do, which is why merchants increasingly ask for it by name, and why courier owners adopt Drix to offer integrations their competitors cannot.

If you want to see what that looks like — merchant API, tracking pages, COD settlement, and analytics on your delivery performance — book a Drix demo. It is the fastest way to judge whether your current courier setup is costing you orders.