Post-Purchase Upsell and Downsell Flow Build

The upsell happens after the first charge is captured, never inside the checkout. On Stripe that means a second PaymentIntent with off_session against the stored payment method, and a share of Israeli-issued cards will still throw a 3DS challenge the network will not waive. Either the flow carries an authenticated redirect path, or it drops those orders quietly and the dashboard shows nothing at all. The flow: One offer after purchase, on a page with no card fields, no address form, no re-entry of anything. Accept charges the saved method and returns a receipt. Decline routes once to a downsell and then to the order confirmation, and that is the end of it. Two steps, never five. The first intent is created with setup_future_usage so the method is reusable, and webhook handlers are idempotent against the event ID so a retried payment_intent.succeeded cannot bill twice. That double charge is the failure that turns into a consumer complaint, so it is what we build against first and what the handover tests cover. Israeli payment specifics: Local processors hold their own tokens and their one-click behaviour is not Stripe's. Cardcom, Tranzila and Meshulam each need the integration written against whichever one already holds your customer's card, rather than moving you to a new processor mid-quarter to suit our convenience. Instalments matter more than anything else on the page: an Israeli buyer offered tashlumim reads 1,200 shekels as 100 a month, and acceptance on an instalment upsell is not comparable to the same amount charged once. Invoicing is wired so the second charge produces a proper Green Invoice or Rivhit document against the same customer record, because an orphan charge with no invoice is what your bookkeeper escalates in week three. The guardrail: We watch refund rate and chargeback ratio for thirty days after launch against the same window before it. If refunds move more than two points, we roll the offer back ourselves and tell you, without waiting to be asked. An upsell that lifts average order value while raising refunds has not made money, it has moved money forward and added support load, and almost every flow we have been asked to review was never measured this way. The downsell rule: A downsell is the same promise in a smaller quantity, a shorter term, or a payment plan. It is not a different product. Offering something unrelated to somebody who has just said no teaches people to skip the page, and it makes both numbers uninterpretable afterwards. Not included: We do not build the checkout itself, migrate your store, or write the primary offer. Subscription billing logic, dunning and failed-payment recovery are separate work we do not take on here. We do not write returns policy or support scripts, though we will read yours before writing the decline path, because the decline path is where the policy gets tested. Who should not buy this: Businesses with an average order value below roughly forty dollars, where the arithmetic of a post-purchase offer does not close. Anyone unable to produce order-level refund data for the last two quarters, because without a baseline the guardrail is decorative. And anyone who wants a pre-ticked box, an automatic renewal disclosed in small type, or a page claiming it will never be shown again. Israeli distance-selling and cancellation law is specific about all three, and we build to it rather than to what converts in a US swipe test. What arrives: The live flow, the webhook handlers with their idempotency tests, a one-page runbook for rolling the offer back inside an hour, and the thirty-day report with refunds in it.