WooCommerce Courier Integration in Bangladesh: Complete Guide

WooCommerce powers a large share of self-hosted online shops in Bangladesh, and almost all of them ship the same way: cash on delivery through a local courier. Yet in most of these shops, the connection between WooCommerce and the courier is a human copying names, phone numbers, and addresses from the orders screen into a courier dashboard. A proper WooCommerce courier integration removes that human bridge — orders flow to Pathao, Steadfast, RedX, or your local courier automatically, and delivery statuses flow back into WooCommerce where your team and customers can see them.

This guide covers the full picture: what the integration should do, the plugin-versus-custom-code decision, how the technical flow works inside WordPress, and the COD reconciliation step most shops forget. Where code appears, it is illustrative pseudocode — each courier’s official API documentation defines the real endpoints and fields, and you should build against that.

What a WooCommerce courier integration should actually do

A complete integration handles five jobs, in increasing order of sophistication:

1. Push orders to the courier — automatically on a status change (for example, when an order moves to “Processing” or a custom “Confirmed” status), or via a “Send to courier” button on the order screen.
2. Store the consignment ID returned by the courier as order metadata, visible on the admin order page.
3. Sync delivery status back — update the WooCommerce order (or a custom field) as the parcel moves from picked to delivered or returned.
4. Show tracking to the customer — in the order confirmation page and emails, so “where is my parcel” messages drop.
5. Reconcile COD — match delivered orders against the cash the courier actually remits.

Most off-the-shelf plugins do 1 and 2. The operational value — fewer support calls, faster returns handling, clean cash flow — lives in 3, 4, and 5.

Plugin, custom code, or platform?

You have three realistic paths in Bangladesh:

• Ready-made plugins. The WordPress ecosystem has plugins for the major local couriers (Steadfast and Pathao integrations are the most common). They are quick to install and fine for straightforward single-courier setups. Watch for: update frequency, whether the plugin stores your API keys securely, and what happens when the courier changes its API.
• Custom code. A small plugin or a snippet in your child theme that calls the courier’s API on an order event. Full control, courier-agnostic if you design it that way, but you own the maintenance. Right choice if you use multiple couriers, need custom rules (courier by district, COD threshold checks, fraud screening), or ship serious volume.
• A courier that integrates for you. Couriers running the Drix platform expose a merchant API and panel to their customers, which means the integration surface is standardized — one documented API for order creation, tracking, and webhooks regardless of which Drix-powered courier you use. If your courier offers this, your WooCommerce side gets much simpler.

If terms like endpoint and webhook are new to you, read our plain-language primer on courier API basics for merchants first — the rest of this guide assumes that vocabulary.

The technical flow inside WooCommerce

WooCommerce is event-driven, and the integration hangs off those events. The canonical pattern:

// Illustrative pseudocode — real endpoint URLs, field names, and
// auth headers come from your courier's official API documentation.

add_action('woocommerce_order_status_processing', function ($order_id) {
    $order = wc_get_order($order_id);

    // 1. Skip if already sent (idempotency)
    if ($order->get_meta('_courier_consignment_id')) {
        return;
    }

    // 2. Build the payload from order data
    $payload = [
        'invoice'   => $order->get_order_number(),
        'name'      => $order->get_shipping_first_name() . ' ' . $order->get_shipping_last_name(),
        'phone'     => normalize_bd_phone($order->get_billing_phone()),
        'address'   => format_shipping_address($order),
        'cod'       => $order->get_payment_method() === 'cod' ? $order->get_total() : 0,
    ];

    // 3. Call the courier API (endpoint per official docs)
    $response = courier_api_create_order($payload);

    // 4. Persist the consignment ID as order meta
    if ($response->ok) {
        $order->update_meta_data('_courier_consignment_id', $response->consignment_id);
        $order->add_order_note('Sent to courier: ' . $response->consignment_id);
        $order->save();
    } else {
        $order->add_order_note('Courier push failed: ' . $response->error);
        // alert an admin — do not fail silently
    }
});

Implementation notes that matter in production:

• Idempotency first. Status hooks can fire more than once (manual status flips, plugin conflicts). The meta-check at the top prevents duplicate consignments.
• Normalize phone numbers. Bangladeshi customers type +8801…, 8801…, and 01… interchangeably. Normalize to the 11-digit local format before validation; reject anything that does not resolve.
• Do not block checkout. Never call the courier API during checkout itself. Hook a post-payment/post-confirmation status, or queue the call (Action Scheduler ships with WooCommerce) so a slow courier API never slows your customer.
• Store keys safely. API credentials belong in a settings field stored server-side or in wp-config.php constants — never hard-coded in a theme file that ends up in a public repo.

Getting statuses back into WooCommerce

The return path has two options:

• Webhook receiver. Register a small REST route (register_rest_route) that the courier calls on status changes. Authenticate it with a shared secret, respond quickly, and update the order meta and notes asynchronously. This is the right answer if your courier supports webhooks.
• Scheduled polling. A WP-Cron or Action Scheduler job that queries the courier for every order not yet in a terminal state. Less elegant, but universal — and even with webhooks you want this as a nightly safety net.

Map courier statuses to a small canonical set (pending, picked, in transit, delivered, partial, returned) stored as order meta. Then surface it: a column on the orders list, a line in the customer’s “order received” page, and a trigger for a “your parcel is out for delivery” notification. If you would rather not build customer-facing tracking yourself, a dedicated parcel tracking system gives every consignment a shareable tracking timeline out of the box.

The step everyone forgets: COD reconciliation

Delivered is not the same as paid. Your courier collects cash from customers all week and remits it on a cycle — and somewhere between 100 delivered parcels and one bank transfer, discrepancies appear: a partial delivery collected less than the invoice, a return charge you did not expect, a parcel marked delivered whose cash never arrived.

WooCommerce has no native concept of any of this. At minimum, export delivered orders per settlement period and match them line-by-line against the courier’s statement. At scale, that spreadsheet becomes its own part-time job — which is exactly the problem COD management in Drix solves: parcel-level matching of delivered COD against remittances, automatic flagging of gaps, and reports showing what each courier owes you right now.

A realistic rollout plan

1. Pick one courier and get API credentials plus official docs.
2. Build or install the order-push path with idempotency and phone validation.
3. Run two weeks in parallel — keep your manual process while comparing results.
4. Add the status return path (webhook plus nightly poll).
5. Turn on customer tracking notifications.
6. Set up settlement reconciliation before you scale volume.

Shops on Shopify face the same problem with different mechanics — see our Shopify courier integration guide for that side.

Final word

A WooCommerce courier integration in Bangladesh is not exotic engineering — it is one outbound API call on an order event, one inbound status path, and disciplined reconciliation. The shops that do it ship faster, botch fewer addresses, and know exactly what their courier owes them. The couriers that make it easy — by offering real merchant APIs, as every courier running Drix does — win those shops’ volume.

Whether you are a merchant who wants this working without a development project, or a courier owner who wants to offer WooCommerce-friendly APIs to every shop you serve, book a Drix demo and see the order-to-settlement flow end to end.