Ecommerce Website Development in Pune: How to Build an Order Confirmation and Thank-You Page That Reassures Buyers and Tracks Sales Correctly
A good order confirmation page does three jobs at once: it tells the customer their order went through, it tells them exactly what happens next, and it fires your sale-tracking exactly once. Most online stores in India do the first badly, ignore the second and break the third, so the customer is left refreshing the page or messaging support, and the marketing team is left with purchase numbers that never match the orders in the admin. Good ecommerce website development in Pune treats this page as part of the product, not an afterthought. This guide explains what the page and the email that goes with it should contain, how Shopify and WooCommerce handle them, and how to avoid double-counted or missing purchases.
It is written for store owners and marketing managers, and for anyone briefing a developer. Platform behaviour is described from the vendors' documentation as read in October 2026 and changes often, so verify against the current docs before building. Examples are hypothetical and numbers are illustrations. Payment, tax and shipping-rate topics are left out on purpose; this guide is about the page and the tracking.
How this differs from other store guides
We have already written about recovering abandoned carts, guest checkout and checkout form design, upsells and bundles and GA4 setup for Indian ecommerce stores. This article covers what happens in the minute after the customer pays, which those guides touch only in passing.
What the page is for
The moment after payment is when a customer is most anxious and most attentive. They have handed over money to a store they may know only from an ad. If the screen says nothing clear, they worry. If it says something clear, they relax, and some will read what you put next.
Three audiences use this page:
- The customer, who needs reassurance and next steps.
- Your support team, who will receive fewer "did my order go through?" messages if the page and email are clear.
- Your analytics and ad platforms, which need one clean purchase event per order.
Design for all three, in that order.
What the customer needs to see
A plain confirmation
Say that the order is confirmed, in words, near the top: "Thank you, Priya. Your order is confirmed." Show the order number, large and copyable. Avoid vague headlines such as "Success!" that could describe anything.
What they ordered and what they paid
Repeat the items, quantities, variants and the total, plus the delivery address and the contact details used. This lets a customer catch a mistake while it can still be fixed, and it is the reference they will screenshot. Do not show more personal information than necessary on screen; if the page can be revisited by link, think about who might see it on a shared device.
What happens next, with honest timing
Tell them the sequence: confirmation email, order packed, dispatched, delivered. Give a delivery estimate only if your operations can keep it. A range with a condition ("usually 3 to 5 working days after dispatch, depending on your PIN code") is better than a promise you cannot keep. If some items ship separately, say so before the customer discovers it.
How to change or cancel
Say clearly whether an order can be changed, until when, and how. For a store that confirms cash-on-delivery orders by phone or WhatsApp, say that too: "We will message you on WhatsApp to confirm your delivery address." Surprises make customers nervous; announced steps do not.
How to reach you
Show a support route that you really staff: a WhatsApp number with working hours, an email address, and a link to your order-tracking or returns page. Our guide to designing the returns process and request form shows how to build the page this link should open.
Optional extras, with restraint
The page can carry a few extras, as long as they do not crowd out the confirmation:
- A short, optional survey asking how they found you. Shopify's documentation lists surveys, social sharing and download links for digital goods as examples of what a thank-you page can carry through its extensions, and product reviews and upsell offers for the order status page.
- A WhatsApp opt-in for order updates, shown as an unticked choice, with clear wording about what messages they will get. See WhatsApp order updates and our opt-in compliance checklist.
- An offer to create an account, with one tap, so they can track the order. Avoid forcing it.
- A link to related products or care instructions, but not a full-page advertisement.
A guiding rule: if an extra delays the customer from seeing their order details, remove it.
The confirmation email
The email is the page's twin. Customers search their inbox for it later, and your support team will point to it. Include:
- Order number, date, items, total, delivery address and payment method (never full card details).
- The same next steps as the page.
- A link to track the order, and a link to a page where they can see or change details while that is possible.
- Your support contact and your returns page.
- A clear sender name and a subject line that includes the order number, so it can be found.
Make it readable on a phone, in plain text as well as HTML, and test that it lands in the inbox and not in spam. Sending domain authentication (SPF, DKIM and DMARC) matters for transactional mail as much as for newsletters; see our email deliverability guide.
Transactional emails like order confirmations are different from marketing emails. Keep promotional content in them small, and follow your privacy and consent rules for anything that goes beyond the order itself.
How Shopify and WooCommerce handle the page
Shopify
Shopify's developer documentation describes two pages. The Thank you page is the first confirmation shown after checkout, and the Order status page is what a returning customer sees if they open the link from their confirmation email. Both can be customised with checkout UI extensions. According to the documentation, on the thank-you page the order may not yet exist at the moment of rendering, but its ID is available through the order confirmation API, after which order details can be fetched with the GraphQL API once the order has been created. On the order status page, the order always exists. The documentation also says UI extensions cannot directly change orders, and that a post-purchase extension is the route for changing the order being created.
Practical consequences:
- Customising these pages on Shopify depends on your plan and on how the store was set up, so confirm what is available before promising a design. Shopify's documentation also changes, and older approaches such as pasting scripts into a checkout settings box have been replaced on current stores; check the current help centre and ask a developer who has built on the current system.
- Put purchase tracking in the platform's supported place, such as the customer events and pixels area, or the app that manages your tags, rather than in a custom hack. A hack may stop working when the platform changes.
- Order notification emails are edited in the notification templates and use Liquid variables. Test with a real order.
WooCommerce
WooCommerce shows an "order received" page at the end of checkout, and a store can customise it with templates, hooks or a plugin. Newer stores use the block-based checkout, where the layout and extension points differ from the older shortcode checkout, so check which one the store uses before choosing an approach. Order emails are edited in the WooCommerce email settings or with an email-customiser plugin.
Two WooCommerce cautions:
- The order-received address contains an order key. Treat it like a private link; do not post it or leave it in analytics page paths where it can leak. Strip query strings from page-path reporting where the order key appears.
- Caching plugins can serve the same confirmation page to different people if the page is cached by mistake. Exclude cart, checkout and order-received pages from page cache. This is a standard setting in good caching plugins, and a common cause of "wrong customer name on thank-you page" complaints.
Tracking the purchase exactly once
This is where most stores lose accuracy. The page loads, the purchase fires. The customer refreshes, opens the email link, or navigates back, and the purchase fires again. Or it never fires, because the tag was blocked or the page was cached.
What a purchase event needs
For Google Analytics 4, Google's recommended purchase event expects an order identifier, the value, the currency and the items. Check the current event reference at Google's documentation for the full list. The order identifier matters most: GA4 uses it to recognise repeat sends of the same transaction. Send the real order number, not a random value generated on each load.
Make firing idempotent
"Idempotent" means that doing the same thing twice has the same result as doing it once. For purchases that means:
- Fire once per order per browser. Store the order ID in the browser after the event fires, and skip the event if the same ID is seen again.
- Do not fire on pages that are not the first confirmation. The order status page, opened from an email, is not a new purchase. Decide explicitly which page fires the event and keep the others silent.
- Fire on a real success state. Do not fire when the page loads for an unpaid, failed or pending payment. Where your payment flow returns to your site, check the order status before sending the event.
- Send cash-on-delivery orders carefully. A COD order is placed, not yet paid. Decide whether your sales report counts orders placed or orders delivered, and be consistent. Many stores track "order placed" in analytics and reconcile deliveries separately.
- Handle cancellations and returns in your accounting, not in a browser tag. The browser knows the customer clicked; it does not know the parcel was refused.
Server-side or deduplicated sending
Browsers block, delay or lose tags for many reasons: consent choices, ad blockers, slow networks, a customer closing the tab. Some stores add a server-side send, where the store's server tells the platform about the order. If you do both browser and server sends, they must carry the same event identifier so the platform can deduplicate them. Our guide to Meta's Conversions API explains the deduplication idea for leads, and the same logic applies to purchases.
Consent
Marketing and analytics tags should follow the visitor's consent choice where your consent setup requires it. If a visitor declines, the purchase event for ad platforms should not fire. Your own order records, which you keep to fulfil the order, are separate from marketing tags. See our guide to Enhanced Conversions and Consent Mode and our DPDP compliance guide for websites.
Reconcile weekly
Compare three numbers each week: orders in the store admin, purchases in GA4, and purchases in the ad platform. They will not match exactly, because of consent, blockers, attribution windows and unpaid COD orders. What you are looking for is a stable gap. A sudden change, such as GA4 showing double the admin count, is a bug. Most such bugs come from a purchase tag firing on a refresh or on two pages.
A hypothetical worked example
A Pune home-decor store sells online; in one week the admin shows 60 orders, of which 20 are cash on delivery and 40 are prepaid.
The owner opens GA4 and sees 95 purchases for the same week. Admin says 60. The developer investigates and finds two causes: the purchase tag fires on both the thank-you page and the order status page, and customers who refresh the page trigger it again because the order ID is never stored.
The fix: fire only on the thank-you page, use the real order number as the transaction ID so GA4 can recognise repeats, and store the order ID in the browser so a refresh does nothing. The following week GA4 shows 52 purchases against 60 in the admin, and the owner can account for the gap: consent declines and blocked tags, plus a few visitors who closed the tab before the tag loaded.
The numbers here are invented to show how to read the gap. Your own gap will vary, and the lesson is to look for a stable, explainable difference.
Cash on delivery, and the order that is not really final
Many Indian stores ship COD, and a COD order is a promise, not a payment. The confirmation page for a COD order should say so plainly: that the customer pays on delivery, how much, in what form, and that someone may call or message to confirm. If you verify addresses by phone or WhatsApp, say that the order will be confirmed after that. Our guide to Shopify COD setup and order verification covers the build side.
Where a COD order may later be cancelled, your analytics should say "order placed" rather than "revenue earned". Tell your marketing team which one the numbers show, so no one compares a placed-order figure to a bank-statement figure and concludes tracking is broken.
Testing before and after launch
Run these tests on a staging copy, then again on the live store with a real small order.
- Place a prepaid order and a COD order. Check the page text, the email, the admin record.
- Refresh the thank-you page five times. Confirm only one purchase event reaches analytics.
- Open the order status link from the email. Confirm no new purchase fires.
- Decline consent and place an order. Confirm marketing tags stay quiet and the order still works.
- Block third-party scripts with a browser extension and place an order. Confirm the page and email still work.
- Open the page on a mid-range phone on a slow connection. Confirm the order number and next steps are visible without waiting for scripts.
- Check the email in Gmail and one other mail app, on a phone, in dark mode.
- Check caching: place two orders from two browsers and make sure each sees its own details.
- Check the page speed; heavy scripts on the confirmation page slow the moment you most want to feel smooth. Our store speed guide covers measurement.
Document the results so the next developer knows what was verified.
What to ask an ecommerce developer in Pune about this page
- What will the customer see, in words, on the confirmation page, and how does a COD order differ?
- Which page fires the purchase event, and how do you stop it firing twice?
- Which order identifier is sent to analytics, and does it match the admin order number?
- How do you handle consent, and what happens to tracking when the visitor declines?
- Do you send events from the server as well, and how are they deduplicated?
- How is the order key protected on WooCommerce, or how are extensions handled on Shopify?
- Is the confirmation page excluded from caching?
- Who will test with real orders, and what will be documented?
Working with Govindani Infotech on store checkout and confirmation
Govindani Infotech is a Pune-based website and software company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build e-commerce stores on Shopify, WooCommerce and custom stacks; our e-commerce development service page describes the range, and our checkout system service covers the build of the buying flow itself. You can see examples in our e-commerce portfolio.
If your store's order numbers and analytics purchases disagree, or customers keep asking whether their order went through, the most useful first step is a short review of the confirmation page, the email and the tracking. Send us the store address on WhatsApp at wa.me/919201958278 or through our contact page, and we will tell you what we would check first before any work is scoped.
Frequently Asked Questions
What should an order confirmation page include?
A plain statement that the order is confirmed, the order number, the items and total, the delivery address, what happens next with honest timing, how to change or cancel, and how to contact support. Add optional extras such as a WhatsApp opt-in only if they do not push the confirmation down.
Why does GA4 show more purchases than my store admin?
The most common cause is a purchase tag firing more than once: on a page refresh, on both the thank-you and order status pages, or from duplicate tags. Send the real order number as the transaction ID, fire on one page only and store the order ID so a refresh does nothing.
Why does GA4 show fewer purchases than my store admin?
Consent declines, ad blockers, slow loads and closed tabs can all prevent the tag from firing. A stable gap is normal. A sudden drop usually means a broken tag or a checkout change. Compare weekly and investigate changes.
Can I customise the Shopify thank-you page?
Shopify's documentation says the thank-you and order status pages can be customised using checkout UI extensions, with limits: extensions cannot directly change orders. Availability depends on your plan and setup, so check the current documentation or ask a developer before promising a design.
Should cash-on-delivery orders count as purchases in analytics?
That is a business decision. Many stores record them as orders placed and reconcile deliveries separately. Whichever you choose, label it clearly in reports so nobody mistakes a placed-order figure for revenue received.
Sources: Shopify.dev: Thank you and order status pages, Google Analytics: Recommended events, purchase, Google Tag Platform: The data layer