> ## Documentation Index > Fetch the complete documentation index at: https://docs.fade.finance/llms.txt > Use this file to discover all available pages before exploring further. # Checkout win-back > A shop puts a fixed share of each order on a ticket. About one order in a hundred comes out free. ## What the buyer sees > **Order #004821. Your order is free.** > Lucky draw won: 185.90 USDC back to your wallet. The sale stands and the buyer keeps the item. The pool pays out an amount equal to the order. The buyer has won the order back. ## Start merchant-funded There are two ways to run a checkout win-back, and they are very different in law. | | Merchant-funded | Buyer-funded | | - | - | - | | Who pays the stake | The merchant, out of its marketing budget: "1 order in 100 is on us" | The buyer, for example through a round-up | | What the merchant gets | A fixed, known cost per order. Giving orders away itself would make that cost random. | Engagement, a larger basket | | Typical legal reading | A promotional game with free participation, permitted in many jurisdictions | Stake, chance and prize: a lottery in most jurisdictions | | Who can offer it | Merchants, subject to local promotion rules | Licensed operators, or apps in compatible jurisdictions | **Lead with the merchant-funded variant.** It is a marketing product, and Fade's role in it is simple to state: the merchant pays a fixed share of sales, and the pool absorbs the variance of who wins and when. ## The arithmetic The merchant funds about 1 % of a 185.90 USDC order: a stake of **1.90 USDC**. The paytable pays the whole order back or nothing, at a 3.5 % declared edge. | | Value | | - | - | | Multiplier | `m = ceil(185.90 / 1.90 × 10 000) = 978 422` bps, 97.84× | | Probability | `p = floor(9 650 × 1e9 / 978 422) = 9 862 819`, about 1 in 101.4 | | Check | `p × m ≤ 9 650 × 1e9`: the paytable keeps its 3.5 % edge | | Protocol fee (20 bps) | 0.0038 USDC | | App fee | 0 in this example | | Pool credit | 1.8962 USDC | | Payout if won | 185.90018 USDC (`1.90 × 978 422 / 10 000`, rounded down) | | Liability reserved | 184.00 USDC | With no app fee, the pool edge is 330 bps. On an idle pool, a 184 USDC liability fits the per-wager cap from about **12 300 USDC of assets** (the 150 bps bound on assets binds first). A smaller pool backs a smaller order, or the same order at a smaller share. See [Paytables](/build/paytables) for how to size a prize against the pool. The merchant's cost is known in advance: 1.90 USDC per order, whatever happens. Over many orders the pool pays back 96.5 % of the stakes in prizes; the rest is the edge, split between the pool, the protocol and the app's own fee if it takes one. ### The buyer-funded variant A buyer rounds 47.30 up to 48.00, staking the 0.70 difference for a chance to have the whole 48.00 back: `m = 685 715` (68.57×), `p = 14 072 902`, about 1 in 71, at the same 3.5 % edge. The liability is 47.30 USDC. This variant puts the buyer's own money at stake, which changes its legal nature (see above). ## Who integrates * Wallets, with a "lucky checkout" option on payments. * Solana Pay checkouts and merchant platforms. * Stablecoin card and payment apps. ## How it is wired | Account | Merchant-funded | | - | - | | `integratorAuthority` | The checkout service's key, or its program's `["fade-integrator"]` PDA | | `payer` | The checkout service: pays the SOL rent and fees, and gets the refundable part back. The buyer never needs SOL. | | `stakeOwner`, `stakeSource` | The merchant's promotion account, which signs | | `beneficiary` | The buyer's USDC account | | `integratorFeeBps` | The service's own fee, within what the edge leaves | The open can ride in the same transaction as the payment, so the buyer signs nothing extra. The service hands the wager to a keeper, and the result lands a few seconds after the payment. See [Integration overview](/build/overview). ## Small stakes On the direct path every wager carries a fixed SOL cost for its own oracle draw, which sets a minimum stake (7.5 USDC under the protocol's reference parameters, 0.10 USDC on devnet). Round-ups of a few cents are the purpose of the [shared beacon](/protocol/shared-beacon) design, in which one draw serves a round of wagers. Until then, an app can accumulate small amounts into one ticket, as round-up savings apps do. ## Wording Say "won back", "free" or "on us". Do not call the payout a refund: the sale is not cancelled, and calling it one may mislead buyers about what happened. Prize-linked payouts are subject to local gaming and promotion law. A merchant-funded promotion with free participation is permitted in many jurisdictions, under conditions that vary by market. A buyer-funded version is usually a lottery. Confirm the rules for each market with counsel before launching. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.