Shipping Aggregators and Your Online Store: What Your Website Must Build, Whichever You Choose

Shipping Aggregators and Your Online Store: What Your Website Must Build, Whichever You Choose

Whichever shipping aggregator you pick, your ecommerce website has to do the same six customer-facing jobs: check whether a PIN code can be served, show a shipping charge and delivery estimate before payment, pass each paid order to the aggregator exactly once, keep order status in step with the shipment, give the customer a tracking page and tracking messages they trust, and handle a failed delivery attempt without leaving the customer guessing. Aggregators such as Shiprocket and NimbusPost, which we name here only as examples, supply the courier network and the API. The storefront experience, meaning what the shopper sees and is told, is built by your website. That is where most of the avoidable support tickets come from.

This article is for founders and store managers who have chosen, or are about to choose, an aggregator and want to know what the website needs to do. It replaces an earlier piece that compared two aggregators. We have removed that comparison on purpose. Rates, courier performance and service quality vary by lane, parcel profile and contract, and the only numbers that count are the ones in your own written quote and your own pilot shipments. Nothing here ranks providers, quotes charges or claims delivery performance.

Several neighbouring guides cover other halves of the problem, and this one is deliberately different from them. If you are still deciding on a partner and its back-end connection, read what to check before you choose a logistics partner. For the courier-level build differences, see Delhivery vs Blue Dart for a D2C website. For warehouses, see choosing a 3PL for a D2C store. Here we stay at the front of the house: the product page, the cart, the order confirmation, the tracking page and the messages a customer receives when something goes wrong.

Show Shipping Rates and Delivery Estimates on Product and Cart Pages

The product page is where a shopper decides whether to continue, and delivery information is one of the things they look for. Baymard Institute's checkout research lists unexpected extra costs, including shipping, among the main reasons people abandon a cart (Baymard). The lesson for your build is to say what delivery will cost and when it will arrive as early as you reasonably can, rather than waiting for the payment step.

Where to display delivery information

• Product page. A small block near the add-to-cart button with a PIN code field and the result: serviceable or not, an estimated delivery window, and whether cash on delivery is available.
• Cart. The same PIN code, remembered from the product page, with the shipping charge shown as its own line.
• Checkout. Re-confirmed against the address the customer actually enters, because the PIN code typed on the product page may differ from the delivery address.
• Order confirmation page and email. The estimate that was shown at purchase, restated, so the customer has a reference.

Where the numbers come from

There are three common approaches, and they have different consequences for the build.

1. Live lookup through the aggregator's API. Your site sends the pickup PIN code, the delivery PIN code, the weight and the payment mode, and receives serviceability and an estimated delivery time. This is the most accurate, but it adds a network call to a page the customer is waiting on.
2. Flat or table-based rules held in your store. You define shipping charges by weight band or region, and estimated delivery windows by zone. This is fast and predictable, but someone has to keep the table honest.
3. A hybrid. Serviceability is checked live and cached, while the charge comes from your own rules. Many stores settle here because the charge is a business decision and the serviceability is a data fact.

Whichever you use, the rule is the same: the page must never promise something the shipment cannot then deliver. If your live estimate says three to five days and your tracking messages are written around two, customers will notice.

Whichever source you use, the page must never promise something the shipment cannot deliver, and it needs a graceful message when the lookup fails, such as "Delivery estimate will be confirmed after you enter your address". Keep the charge calculation in one function that the product page, cart, checkout and order record all call, so the numbers cannot drift apart.

Build a PIN Code Serviceability Check That Customers Trust

The PIN code check looks like a trivial field, but it carries a lot of expectations.

What the check should return

Practical build notes

• Validate format first. An Indian PIN code is six digits. Reject obvious typos before spending an API call.
• Cache results. Serviceability for a PIN code changes slowly. Caching for a sensible period, for example a few hours, avoids repeated calls and keeps the product page quick. Pick the period with your aggregator's guidance and your tolerance for being briefly out of date.
• Use your own endpoint. The browser should call your server, which calls the aggregator. Never put aggregator credentials in front-end code.
• Recheck at order time. The address might be in a different PIN code from the one typed earlier. Block the order, or flag it for review, if the final address is unserviceable.

Plugin or Custom API Integration on Shopify and WooCommerce

Both major platforms give you two routes, and the right one depends on how unusual your store is.

Route one: the aggregator's app or plugin

On Shopify, aggregators generally offer an app, and on WooCommerce a plugin. These usually handle order import, shipment creation and status sync, and some add a tracking page or serviceability widget. Confirm what any given plugin actually includes before you decide, because capabilities differ by provider and by version, and we do not describe them here.

Good fit when: you ship standard parcels, have a single pickup location, use common order flows, and are happy with the plugin's tracking and notification defaults.

Watch for:

• A widget or tracking page whose look cannot match your theme.
• Notifications sent by the aggregator that duplicate or contradict your own.
• Plugin updates that change behaviour. Test updates on a staging copy first.

Route two: a custom integration using the aggregator's API

Here your developer writes code that calls the aggregator's published API directly. It takes longer and costs more to build, but you control what the customer sees and how failures are handled.

Good fit when: you need the estimate embedded in your own design, you have multiple warehouses or pickup points, you bundle or split orders, you sell made-to-order items, you want your own branded tracking page, or you want to switch aggregators later without rebuilding the storefront.

Watch for:

• API versions and authentication tokens that expire. Build token refresh and alerting in from the start.
• Rate limits on the API.

Whichever you choose, put your own thin layer between your store and the aggregator. A small internal module with functions such as "check serviceability", "create shipment" and "get status" means that your templates never talk to a specific aggregator, and a change of provider touches one module rather than the whole site. Our logistics integration service covers this kind of connection, and our broader ecommerce development work covers the store around it.

Order Push and Status Sync: The Part Customers Feel

The back-end mechanics of order push are covered in more depth in the partner-selection guide linked above. Here we focus on how sync behaviour appears to the customer.

When to push an order

Decide the trigger deliberately.

• Prepaid orders: push after the payment is confirmed on your server, not when the customer lands on a success page. A browser that closes early should not lose an order.
• COD orders: push after any confirmation step you require, such as a phone or WhatsApp confirmation for high-risk orders. Pushing before confirmation creates shipments you may need to cancel.
• Edits and cancellations: define a window during which a customer can change the address or cancel, and make sure the push waits for it or can be reversed.

Mapping statuses into customer language

An aggregator returns its own status labels. Your customer should not see them raw. Build a mapping table and keep it in one place.

The exact labels from your aggregator will differ. Take them from its documentation, and test each one with a real or sandbox shipment. Unmapped statuses should fall into a safe default, such as "In transit", and also create an internal alert so that someone adds the mapping.

Build a Tracking Page Customers Actually Use

After a purchase, "where is my order" is among the most common questions a store receives. A good tracking page answers it without a human.

Two choices: aggregator-hosted or your own

Many aggregators supply a hosted tracking page. It is quick to adopt, but it sends the customer to a different domain with different branding, and the page may carry other advertising or branding you do not control. A tracking page on your own domain keeps the customer in your store, lets you add reorder links, support options and recommendations, and lets you control the wording.

What the page should contain

• A lookup by order number plus phone or email, so that order details are not exposed to anyone who guesses a number. Do not expose an incrementing order ID with no second factor.
• A clear current status in plain language, and the estimated delivery window.
• A timeline of status changes with dates and times.
• The courier's name and tracking number, with a link to the courier's own page as a fallback.
• The order contents and delivery address, partially masked.
• Help options: a support link, a WhatsApp button, and a phone number.
• For a failed attempt, a visible action, such as "Update your address or availability".

Tracking links in email and WhatsApp

Include the tracking link in the shipped message, and make it a link to your own tracking page with the order identified in a way that does not require login. Use a signed token or unguessable identifier rather than a plain order number in the URL. For the messaging side, such as templates, consent and approval, see our guide on WhatsApp order updates through the API, and our WhatsApp commerce service if you want it built for you. Email remains useful as a record, and it is a good fallback when a phone number is wrong.

The Failed-Delivery Flow: Contact the Customer Before the Parcel Goes Back

A failed delivery attempt is the point where a happy purchase can turn into a return. Aggregators commonly report these as non-delivery events, and many provide a way to record the customer's response, though the details vary. Your website's job is to make the customer's response easy to give and easy to pass on.

A workable customer-contact flow

1. Receive the event. A webhook or status poll tells your store that an attempt failed and gives a reason if available.
2. Notify quickly. Send a WhatsApp or SMS message and an email stating that an attempt did not succeed, naming the reason in plain words, and giving one clear action.
3. Offer a simple response page. A page, opened from a signed link, where the customer can confirm the address, correct the phone number, pick a new date if the aggregator supports rescheduling, or ask for cancellation.
4. Pass the response on. Send the customer's reply to the aggregator through its supported method, or notify your own team to do it. Do not leave replies in an inbox nobody watches.
5. Escalate. If there is no response within your chosen window, send one reminder, and then decide whether to hold, retry or return according to your own policy.
6. Record the outcome. Store the reason and the response against the order, so that you can see patterns, such as one PIN code with repeated address problems.

Failure Handling: Webhooks, Retries and Duplicate Orders

A shipping integration is a distributed system with an unreliable network in the middle. Most customer-visible failures come from not planning for that.

Webhooks

• Verify the sender. Use whatever signature or token mechanism the aggregator documents, and reject unverified requests.
• Respond quickly, process later. Acknowledge the webhook, put the event in a queue, and process it separately so that a slow database does not cause timeouts and repeats.
• Be idempotent. The same event may arrive more than once. Processing it twice must not send two customer messages or change a status backwards. Store an event identifier or a combination of shipment, status and timestamp, and skip repeats.
• Handle out-of-order events. A "delivered" event might arrive before an earlier "out for delivery". Compare timestamps or a status ranking before overwriting.

Retries

• If shipment creation fails because of a network error or an aggregator outage, retry with increasing delays rather than hammering the API.
• Set a limit, and when it is reached, put the order into a visible "shipment pending" state and alert someone.
• Do not retry errors that will never succeed, such as an invalid address field. Surface them to staff with the specific reason so they can fix the order.

Duplicate orders and duplicate shipments

This is the failure that costs real money, because two shipments mean two parcels or a confusing cancellation.

• Generate your own unique reference per order and send it with the shipment request. If the aggregator supports rejecting a repeated reference, rely on that, and confirm by testing it.
• Before creating a shipment, check whether your database already holds a shipment for that order, and lock the record during creation so two processes cannot proceed together.
• If a create call times out, do not assume it failed. Query the aggregator for an existing shipment with your reference before retrying.

A Test Plan Before Go-Live

Run these tests in a staging environment first, then on a small number of real orders. Record the result for each.

Serviceability and estimates

• A PIN code you know is served returns the expected result on product, cart and checkout.
• A PIN code that is not served is handled with a clear message.
• A COD-ineligible PIN code hides COD at checkout.
• The lookup still behaves sensibly when the aggregator is unreachable.
• Charge calculation is identical in cart, checkout and order record.

Order flow

• A prepaid order creates exactly one shipment after payment confirmation.
• A COD order follows your confirmation rule before dispatch.
• Closing the browser right after payment does not lose the order.
• Clicking the shipment button twice does not create two shipments.
• An order with an address the aggregator rejects shows a clear staff alert.

Tracking and messages

• Each mapped status updates the order page and sends only the intended message.
• An unmapped status falls back safely and raises an alert.
• A repeated webhook does not send a second message.
• The tracking page needs a second factor, loads quickly on a phone and is marked noindex.
• Tracking links in WhatsApp and email open the right order.

Failed delivery and returns

• A simulated failed attempt triggers the customer message.
• The customer's response reaches the aggregator or your team.

Working with Govindani Infotech

Govindani Infotech is a web design and development company in Pune. We build online stores on Shopify, WooCommerce and custom stacks, and the work in this article, meaning serviceability checks, estimate display, tracking pages, status sync and failure handling, is the kind of integration work we take on as part of a store build or as a standalone improvement. We do not sell shipping or choose couriers for you, and we do not recommend an aggregator over another here, because that depends on your quotes and pilot shipments.

If you want a second opinion on your current setup or a scoped build, send us your platform, your current aggregator or shortlist, and what you want customers to see. We will tell you plainly what is a plugin setting and what needs custom work. Message us on WhatsApp or use the contact page. If you are comparing budgets for a store build, our website pricing page describes how we scope work.

Frequently Asked Questions

Do I need a custom integration, or is the aggregator's plugin enough?

For a standard store with one pickup location and ordinary orders, the plugin is often enough, provided you are content with its tracking page, widgets and notifications. Custom work becomes worthwhile when you want the delivery estimate and tracking page to match your brand, need multiple pickup points or split shipments, or want to keep the freedom to change aggregator later. Many stores use a plugin for plumbing and custom code for the customer-facing parts.

Should I show a delivery estimate on the product page?

Generally yes. Shoppers look for delivery information before committing, and unexpected shipping costs are a recognised reason for cart abandonment. Show the estimate as a window, base it on both your handling time and transit time, and have a sensible message ready for when the lookup fails.

How do I stop duplicate shipments for one order?

Send your own unique order reference with every shipment request, check your own database before creating a shipment, lock the record while it is being created, and query the aggregator for an existing shipment before retrying a timed-out request. Also make sure the admin shipment button is safe to click twice, and test all of this before launch.

Where should customers track their parcel, on my site or the aggregator's page?

Either works, but a tracking page on your own domain keeps the customer in your store, keeps the wording under your control and lets you add support options. Whichever you choose, make sure the link in your messages opens the right order, and use a second factor or a signed link so order details are not exposed.

What should happen when a delivery attempt fails?

Tell the customer quickly, in plain words, what happened and what to do, using WhatsApp, SMS or email. Give them a simple page to confirm their address or availability, and make sure their reply reaches the aggregator or your team. Send one reminder, then follow your own policy on holding, retrying or returning the parcel.