A custom funnel that sells in India and worldwide,
without leaking a sale.
Pankaj Gupta sells books and one-on-one coaching to readers in India, who pay in rupees, often by UPI, and need GST invoices, and to readers everywhere else, who pay in dollars with PayPal. We built him two storefronts on one codebase, with the whole funnel behind them: chapter previews, checkout with order bumps, a post-purchase offer, recovery, invoicing and server-side tracking.
There are no revenue or sales-volume figures on this page, by the client's choice. The rates are real, measured from the store's own database. Below them is the 29-point checklist we scope every custom build against: use it on any quote you have been given.
- Client
- Pankaj Gupta, life coach and author
- Sites
- pankajlifecoach.com (India) · elevarelifecoaching.com (worldwide)
- Stack
- Next.js, Payload CMS, Postgres
- Payments
- Razorpay with UPI (INR), PayPal (USD)
- Live since
- July 2026
Two markets, two ways to pay.
One business.
Pankaj Gupta is a life coach and the author of The Impossible Loop series. His business is weekly one-on-one coaching. His books are how most people find him. So the site had to do two jobs at once: sell a book to a stranger in a few clicks, and turn some of those readers into coaching clients over the weeks that follow.
His readers are in two very different places. In India, UPI is how most people pay online, and every sale needs a GST invoice with the tax split worked out by the buyer's state. Everywhere else they pay in dollars, through PayPal, and those sales are exports that are invoiced without GST. A course platform or a hosted checkout will usually handle one of those markets well. He needed both, with the whole funnel under his own control.
So we built two storefronts on one codebase. One admin, one set of products and email templates, one funnel. Only the parts the payment gateway and the tax law force apart are different. The rest of this page is what that took, what it measures in production, and the checklist we use to scope builds like it.
What the buyer sees.
What runs behind it.
Eleven stages, from a stranger reading a sample chapter to a coaching client choosing a slot. The left column is the experience. The right column is the part most quotes leave out.
| Stage | What the buyer sees | What runs behind it |
|---|---|---|
| Chapter preview | Chapter 1 of each book, read in the browser, unlocked with an email address | The lead is saved with its campaign source; the preview is parsed live from the manuscript, so it never drifts from the book |
| Book page | Price in their own currency, reviews, the two-book bundle | A server-side ViewContent event with the same event ID as the Pixel, so Meta counts it once |
| Checkout | One page: UPI, cards and netbanking in India, PayPal worldwide | The order is created before payment, so a drop-off is visible; iPhones get UPI collect and QR instead of app links that fail on iOS |
| Order bump | "Add the second book" for the difference to the bundle price | Priced so book plus bump equals the bundle exactly; the server only accepts bumps from that checkout's own list |
| Payment | A confirmation page that resolves, even when the gateway is slow | The page asks the gateway directly as well as waiting for the webhook; fulfillment runs once whichever arrives first |
| Invoice | A GST invoice in India, a zero-rated export invoice elsewhere | Gapless numbering per financial year, a separate series per store, the PDF emailed with the order |
| Delivery | PDF and EPUB downloads, re-sendable from an email | Expiring, tokenized download links; a check that every product's file is actually linked |
| After purchase | One offer: a coaching session at a book-buyer price, open for 7 days | A signed offer link; the price is enforced on the server, not just shown on the page |
| Recovery | One reminder email if the checkout is left for 45 minutes | Skipped for anyone who has paid since; the resume link reopens the same order at the same price |
| Coaching | Three payment plans for one weekly session, with an enquiry-first route for the bigger plans | Preferred day and time captured at checkout and passed into the onboarding email |
| Attribution | Nothing visible | Campaign tags and ad click IDs saved on every order and lead, and Purchase sent to Meta from the payment webhook |
One codebase.
Two storefronts.
The two sites share every page, product, offer and email. They differ only where they have to.
Everything above the payment and tax seam is shared: one codebase, one admin, one set of email templates. Only what the gateway and the tax law force apart is different.
What a custom funnel build
has to include.
Every item below exists in Pankaj's build, and most are missing from a typical quote. Hold it against anything you have been offered: each gap is something you will pay to add later, usually after it has already cost you sales.
Payments
- The right gateway for each market, not one gateway everywhere (UPI matters in India, PayPal abroad)
- Prices and checkout in the buyer's currency
- Order confirmation that survives a late or missing webhook (active reconciliation with the gateway)
- Webhook events processed once, however many times they arrive
- A separate iPhone path for UPI (app-switch links fail in Safari)
- Zero-value orders (100%-off codes) that complete without a gateway round trip
Tax and invoicing
- A tax invoice generated for every paid order, not produced later in a spreadsheet
- GST split by buyer state (CGST+SGST or IGST) where it applies
- Export sales invoiced correctly, and kept in a separate series
- Gapless numbering per financial year, with no reuse across stores
- The invoice PDF emailed to the buyer with their order
Delivery
- Digital files linked to their products, with a check that none is missing
- Expiring, tokenized download links rather than public file URLs
- A way for buyers to request their download again
- For services: the buyer's preferred day and time captured at checkout
The funnel
- A lead magnet that captures an email address and records where the visitor came from
- Order bumps priced against the bundle, validated on the server
- A post-purchase offer with a real expiry and a server-enforced price
- Payment plans, and an enquiry-first route for high-ticket offers
- Abandoned-checkout recovery: one reminder, skipped if the buyer has since paid
Tracking
- Meta Pixel plus the Conversions API, sharing event IDs so nothing is counted twice
- Purchase sent from the payment webhook, not from a page load
- Campaign tags and ad click IDs saved on every order and lead
- Funnel events (page view, product view, checkout) sent from the server too
Running it
- Products, prices and offers managed in an admin panel, not in code
- Every automated email editable in the admin, with one-click unsubscribe on marketing emails
- An order and lead notification that says where the buyer came from
- Data retention that matches what the privacy policy promises
- A database backup taken before every schema change
Custom funnel build scope checklist · NCMborz · ncmborz.com/case-study-custom-funnel-build-razorpay-paypal.html
Five things that only show up
once real money moves.
Each of these was found in production, after launch. They are here because a build gets them wrong quietly: nothing errors, nothing alerts, and the damage only shows if you go looking.
The webhook that arrives late, or never
When a customer pays but never receives an order confirmation, the cause is almost always a payment webhook that arrived late, was retried, or was lost. The gateway confirms a sale by calling your server, and that call is not guaranteed. A confirmation page that trusts the webhook alone leaves a paying customer staring at a pending screen. One that trusts the browser alone hands the goods to someone who has not paid.
The fix is both paths and one source of truth: the success page asks the gateway what happened rather than waiting to be told, and fulfillment runs once no matter which path gets there first.
The invoice number that must never repeat
Sequential invoice numbering looks solved until two storefronts invoice under one tax registration. Both of these stores did, both used the same prefix, and each kept its own counter in its own database: two sequences, both starting at one.
It collided before anyone noticed, because a duplicate invoice number raises no error. It only shows up when someone reconciles the books, which is the worst possible moment to find it.
The conversion that gets counted twice
Send a purchase from the browser and again from the server, which you should because browsers block the first, and the ad platform counts two sales unless both copies carry the same event ID. Reporting then shows about double the truth, the most expensive kind of wrong number, because you will scale spend against it.
The quieter trap is the other direction: if the Purchase event fires from the confirmation page, anyone whose browser blocks the Pixel is never counted at all, and the platform optimizes toward the wrong people.
The file that was uploaded but never linked
The books were uploaded correctly into the admin, and the record that points each product at its file was left empty. The download route fell through to a fallback that did not exist, and buyers got a placeholder message instead of their book.
Nothing failed. No error, no alert, no failed payment. It ran that way for six days before anyone checked. A build is not finished when a feature works once in testing. It is finished when whatever breaks it silently has a check in front of it.
The iPhone that could not pay by UPI
On iPhones, UPI payments that hand off to a payment app never completed. Safari cannot open those app links, so the buyer sat on a waiting screen until the payment timed out. Every such attempt on iOS failed, while the same flow worked on Android.
A failed payment is not an abandoned checkout, so it got no reminder email either. Those buyers were lost without a trace, and only the gateway's error codes showed why.
When custom is worth it, and when it is not
Most people selling one product in one market should use a hosted platform and spend the money on traffic instead. A custom build earns its cost when the business does not fit the platform: two markets with different payment habits and tax rules, offers that need pricing rules the platform will not enforce, or a funnel whose tracking and data you need to own. Pankaj's needed all three. The build was done by a senior developer working with AI assistance throughout, which is why two storefronts, two gateways and two tax treatments were affordable at this size. AI shortened the time from decision to working code. It did not find the five problems above; a person watching production did, and that is the part you are paying for.
What people ask
before commissioning a build.
Can one website take Razorpay in India and PayPal for international buyers?
Yes, and there are two ways to do it. One storefront can offer both gateways and switch by the buyer's country. Or, as here, you can run two storefronts on one codebase, one per market. We chose two because the markets differ in more than the gateway: currency, tax treatment and invoice series all change, and keeping each store's orders and invoices separate makes the accounting clean. Either way, it is one codebase to maintain.
How do I sell coaching and ebooks to buyers in India and abroad from one business?
Price in each market's currency, use the payment method each market prefers (UPI in India, PayPal or cards abroad), and treat the sales as the tax law does: domestic sales with GST, and exports of services and digital products invoiced as zero-rated where they qualify. Then make the funnel identical on both sides, so what you learn in one market carries over to the other. Confirm the tax position for your own business with your accountant.
Why build a custom funnel instead of using a course platform or Shopify?
Often you should not. A hosted platform is the right answer for most single-market sellers. Custom earns its cost when you sell across markets with different payments and tax, need offers the platform will not enforce (a bump priced against a bundle, a time-limited post-purchase price), or need to own your tracking and customer data. If none of those apply, a platform plus good ads will serve you better.
What is an order bump, and does it work?
An order bump is a one-click add-on shown on the checkout itself, before payment. On this build it offers the second book for the difference to the bundle price, so taking it lands the buyer exactly on the bundle. Since the two-book offer went live, 68% of single-book checkouts have added it. It works because it is the same decision the buyer has just made, offered at a fair price, not a different product sprung on them.
What should a custom ecommerce or funnel build quote include?
Beyond design and product pages: an invoice for every order, confirmation that survives a late webhook, abandoned-checkout recovery, server-side conversion tracking that does not double-count, and secure delivery for digital products. The full list we scope against is the checklist on this page. Ask for each item by name when you compare quotes; the missing ones are expensive to add after launch because they touch the order record.
Why does a payment succeed but the order not confirm?
Almost always because the confirmation depends only on the payment gateway's webhook, and that webhook arrived late, was retried, or never arrived. The fix is for the confirmation page to ask the gateway directly as well, and for fulfillment to run exactly once whichever path arrives first.
How much does a custom funnel build cost?
Every build is a fixed-price project, agreed in writing before work starts, with 50% to begin and the balance on delivery. Our project range is on the pricing page. Where a build lands depends on the number of markets, gateways, products and offers, and we scope it on a call.
Who owns the code and the customer data?
On a build you commission, you do: the code, the database and every customer and order record belong to your business, not to us or to a platform. That ownership is a large part of why a custom build is worth paying for.
Who is a custom build not right for?
We are not the right fit if you sell one product in one market and a hosted platform already works for you, or if you are pre-revenue without a validated offer. In both cases the money does more good spent on traffic and the offer itself. We will say so on the call rather than take the build.
This is a client build for Pankaj Gupta, a life coach and author. By the client's choice there are no revenue or sales-volume figures on this page. The two rates were measured from the store's own database on 23 September 2026: the order-bump rate over single-book orders since the two-book offer went live, and the Meta figure over every paid order since the Conversions API was connected in August. We are happy to screen-share the admin and walk through any of it on a call.
Get your build scoped properly.
Planning a funnel, a store, or a move off a course platform? Bring what you have been quoted, or what you run now. We will go through the checklist on this page against it and tell you what is missing, whether or not you build with us.