> ## Documentation Index > Fetch the complete documentation index at: https://docs.lumx.io/llms.txt > Use this file to discover all available pages before exploring further. # Build marketplace seller payouts > A copy-paste prompt that builds a marketplace where each seller is onboarded, the platform takes a fee on every sale and sellers settle in local currency. Paste this prompt into your coding agent to build the payout side of a marketplace, with the platform fee taken on every sale. The agent sets up the platform fee, onboards each seller as its own customer, takes buyer payments in, pays sellers out, and reconciles all three sides of every sale. ## Before you start * A Sandbox API key. See [Authentication](/get-started/authentication). * An answer from your compliance owner on how seller funds flow. See [Nested payments](/compliance/nested-payments). * A webhook endpoint registered under **Developers > Webhooks** in the [Dashboard](https://dashboard.lumx.io). See [Webhooks](/developer/webhooks). ## Prompt ```text Prompt theme={null} You are a senior backend engineer building seller payouts for a marketplace on Lumx. The platform takes a cut of every sale; each seller gets paid in their own local currency. Ground truth. Read all three before writing any code and follow them over any prior knowledge: 1. https://docs.lumx.io/compliance/nested-payments — this decides whether the design is legal before it decides whether it works. Read it first. 2. https://docs.lumx.io/llms.txt — the documentation index; /guides/use-cases/marketplaces walks the same flow in prose. 3. https://lumx-docs-public-prod.s3.us-east-1.amazonaws.com/api-production.yaml — the OpenAPI 3.1 spec, for every field, enum and required flag. 1. Settle the structure first. Every seller must be onboarded as its own Lumx customer and receive funds in its own wallet. A design where buyer money pools in the platform's account and the platform distributes it is nesting and is not allowed. If the product spec requires that, stop and report it. 2. Configure the platform's cut once with POST /partner-fees: a name, the platform's own walletAddress, and rate in basis points plus flatAmount for onRamp and offRamp. Keep the id. 3. Onboard each seller with POST /customers — BUSINESS for incorporated sellers, INDIVIDUAL for sole traders — and pass the accounts array only for sellers who receive fiat from outside your checkout. Sellers paid through your own checkout need no account; the on-ramp credits their wallet directly. 4. Take the money in. For a buyer paying on your checkout, create POST /transactions/on-ramp on the seller's behalf with your partnerFeeId (for a locked rate, pass it when creating the exchange rate instead), then render state.payment for the buyer. For a seller collecting from an external platform into a virtual account, the deposit arrives on the account instead. 5. Pay the seller out. Register the seller's own bank account with POST /destinations using holder.relationship SELF — the seller is paying itself — and settle with POST /transactions/off-ramp. 6. Reconcile three ledgers per sale: what the buyer paid, what the seller received, and what the platform kept. Read the fee breakdown from the locked-rate response or the transaction receipt; never compute the platform's revenue by subtraction. Constraints: - A seller who has not reached APPROVED cannot receive funds. Read the status from GET /customers/{id} and model it as a product state with its own screen, not as an error. - Purpose comes from the request enum and must describe the real trade. PERSONAL_ACCOUNT is only valid with a SELF destination. - Do not state a rate limit while paying a batch of sellers. None is published. Handle 429 TOO_MANY_REQUESTS with exponential backoff. Deliverables: - A seller onboarding flow with the pending and rejected states handled. - Checkout and external-collection paths, both carrying partnerFeeId. - A three-way reconciliation per sale, read from API data rather than derived. - A written answer to the nesting question in step 1. ``` ## How to use 1. Answer the nesting question with whoever owns compliance before building. It decides the product, and no amount of code fixes a pooled design. 2. Set the platform rate with whoever owns pricing; it lands in every buyer-facing quote. 3. Onboard two sandbox sellers in different countries. One seller hides every problem this flow has. ## What the prompt builds | **Endpoint** | **What the agent uses it for** | | :- | :- | | `POST /partner-fees` | Configures the platform's cut once | | `POST /customers` | Onboards each seller | | `GET /customers/{id}` | Reads each seller's verification status | | `POST /destinations` | Registers each seller's own bank account | | `POST /transactions/on-ramp` | Takes a buyer's payment on the seller's behalf | | `POST /transactions/off-ramp` | Pays the seller out | ## Errors to expect These codes come from the [errors catalog](/developer/errors), for the resources this prompt uses. Match on `code`, not on `message`. | **Code** | **Status** | **When it happens** | | :- | :- | :- | | `KYC_NOT_APPROVED` | 403 | Customer identity verification (KYC/KYB) is not approved. | | `PARTNER_FEE_NOT_FOUND` | 404 | Partner fee does not exist. | | `INVALID_WALLET_ADDRESS` | 400 | Partner wallet address is invalid for the blockchain. | | `INSUFFICIENT_BALANCE` | 422 | Balance is too low for the operation. | ## Related resources Collect from buyers and pay sellers. Whose funds can move, and for whom. Earn a fee on every transaction you route. Pay contractors in several countries from one funded balance. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.