Post-Purchase Upsell and Downsell Flow, Priced on Refunds

The number that caps this work: Refund and chargeback rate, not take rate. An upsell that lifts average order value 18 percent while refunding at three times the base rate is a loss once you count gateway fees, support hours and your acquirer's tolerance for disputes. Before designing anything I model net contribution per accepting buyer at your actual refund and support cost, and on roughly a third of the offers I look at, the honest recommendation is a smaller upsell than the one I was asked for. The shape of the flow: One upsell. At most one downsell. The downsell is not the same product at a lower price, because that teaches every future buyer to decline first. It is a smaller commitment: fewer months, one seat, the first module. Three-deep stacks exist because somebody's case study said they work, and what they reliably produce is a refund cluster and a support queue your team pays for in the following month. Placement: An order bump inside checkout and an offer made after payment is captured behave differently and are priced differently. The bump belongs to something adjacent and cheap. The post-purchase slot is where a second real decision can live, because the first is already settled and there is no risk of losing the base order. I build to Shopify's post-purchase checkout extension where you are on Shopify, and to Stripe with a SetupIntent taken at first purchase where you are not. India, and the one-click myth: A true one-click second charge is not available to you here. RBI's card-on-file tokenisation and additional factor authentication rules mean the second card charge re-authenticates, and UPI Autopay mandates carry a pre-debit notification and a ceiling. So the Indian post-purchase offer is designed to survive an OTP screen: the offer is made and accepted before authentication, the wait is explained rather than hidden, and the confirmation lands where the buyer is already looking. Anyone selling you a one-click flow in this market is selling a Stripe pattern that does not apply. Testing: Below roughly 250 post-purchase sessions a month you cannot read a split test inside a quarter, and running one anyway produces a decision made on noise. At that volume I use sequential periods with a holdout and state plainly how confident the read is. Above it, we split properly and hold the test until it finishes rather than calling it on the Friday it looks good. Excluded: Checkout replatforming, subscription billing implementation beyond the offer logic, support process design, and the product itself. Excluded on principle: pre-ticked add-ons, trials that convert to a charge without notice the buyer will actually see, and cancellation flows built to be difficult. Those raise the first month and cost you the second year, and I have cleaned up after enough of them to stop building them. Who should not buy this: Anyone whose base offer is not yet converting predictably, because the upsell multiplies whatever the front end does, including nothing. Anyone selling a single product with no adjacent second purchase, where the honest answer is to raise the price rather than bolt on a flow. And anyone who wants a take rate committed in advance. I will give you the range the category supports and the reasoning, and that is what any number before launch is worth.