ThriveCart

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the checkout I actually need instead of ThriveCart — and note first that it is bought once rather than subscribed, so the money argument here is thin.

The reason to build is control: a checkout on your own domain, with the price computed by your own server, and no third party in the payment path.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- One payment provider, hosted fields or hosted checkout, so no card data touches this
- Caddy in front

THE RULE THAT MATTERS MOST
- **The price comes from the server, never from the page.** A product identifier goes up, a price comes back. Anything else means somebody edits the markup and buys the thing for one euro, and it is the most common flaw in cart implementations
- The same applies to quantity, shipping, discounts and tax. The browser displays; the server decides
- The total is recomputed immediately before the payment session is created, from identifiers and quantities alone

THE DATA MODEL
- products: id, sku, name, price_cents, currency, tax_category, delivery_kind, is_active
- offers: id, product_id, kind, config_json — an order bump, an upsell, a downsell
- carts: id, token, items_json, subtotal_cents, currency, created_at, abandoned_at, converted_at
- orders: id, number, cart_id, email, name, subtotal_cents, tax_cents, discount_cents, total_cents, currency, status, provider_ref, placed_at, refunded_at
- order_items: id, order_id, product_id, sku, name, unit_price_cents, quantity, tax_rate, tax_cents — copied at the time of order, so a later price change never rewrites history
- upsell_events: id, order_id, offer_id, shown_at, accepted_at, declined_at
- affiliates, referrals, commissions — if you need them, and the shape is under Rewardful elsewhere in this catalogue
- provider_events, for idempotency by event id

UPSELLS AFTER PAYMENT, WHICH IS THE FEATURE
- A one-click upsell charges the card again without asking for it, which requires the processor to have kept the payment method and to allow a subsequent charge. Check that your provider supports it and under what terms before designing the flow
- Every accepted upsell is its own order line with its own charge, recorded separately. Bundling it into the original order makes a refund impossible to reason about
- **A declined upsell must not block delivery of what was already bought.** Deliver the first purchase immediately, on payment, and treat the upsell as a separate transaction
- Show the upsell once. A funnel that asks three times is the pattern people complain about publicly, and it costs more in refunds than it earns

CHECKOUT
- Three fields and a payment method. Every additional field costs conversions, measurably
- The order created from the verified webhook, never from the browser returning to a success page — somebody who closes the tab after paying must still have an order
- Idempotency by event id, and out-of-order delivery handled
- Tax on digital goods is usually the buyer's rate. Collect the country, apply the rate, and store two pieces of non-conflicting evidence of where they were

AFTER THE ORDER
- Delivery through signed expiring links with a use limit, where a resumed download counts as one use rather than five
- A receipt that arrives, from your own domain with SPF, DKIM and DMARC configured
- An order-status page at a token URL, no account
- Refunds through the provider, with access revoked from the webhook

WHAT MATTERS MOST
Server-side pricing and webhook-created orders. Try to buy something at a price you edited in the browser, and close the tab immediately after paying — if either produces the wrong outcome, nothing else in the checkout matters.