--- title: "How to build a global checkout like Stripe with BlindPay" seoTitle: "Build a global checkout like Stripe with BlindPay (2026)" description: "Yes, you can build a Stripe-style global checkout on BlindPay: sessions, a hosted page, Pix, SPEI, PSE, Transfers 3.0, ACH, wire, and RTP, paid out in USD." date: "2026-10-30" updated: "2026-10-30" category: "payments" author: "BlindPay Team" faq: - q: "Can I build a global checkout like Stripe Checkout with BlindPay?" a: "Yes. You build the checkout sessions API and the hosted payment page, and BlindPay moves the money. Shoppers pay by Pix in Brazil, SPEI in Mexico, Transfers 3.0 in Argentina, PSE in Colombia, or ACH, wire, and RTP in the US. Each merchant receives the full USD price as stablecoins and can withdraw to a bank account with a payout quote." - q: "How long does it take to build a Stripe-style checkout on BlindPay?" a: "The fastest path is the Build a global checkout prompt on blindpay.com. A coding agent builds merchant onboarding, a checkout sessions API with signed webhooks, a hosted page for seven local rails, and a demo store, then tests every flow on a development instance. A hand-built version follows the same steps and the same BlindPay endpoints." - q: "How does the merchant get paid in dollars when the shopper pays in reais or pesos?" a: "Each payin quote uses currency_type receiver with cover_fees true. The request amount is the merchant's USD price, so the merchant receives exactly that amount in stablecoins, and the shopper's local amount already includes fees and exchange. The quote locks the numbers for 5 minutes, and the payin consumes that quote." - q: "How does a checkout platform earn a fee on every payment?" a: "Create one BlindPay partner fee with a percentage in basis points and an optional flat fee in cents, then pass its partner_fee_id on every payin quote. BlindPay collects the fee during each payin, accumulates it over the calendar month, and releases it on the first day of the next month, net of your BlindPay invoice." - q: "Do I need a separate integration for each country?" a: "No. One payin quote endpoint and one payin endpoint serve every rail. You change the payment_method field to pix, spei, transfers, pse, ach, wire, or rtp, and add payer_rules where the rail needs them: a CPF or CNPJ for Pix, a CUIT or CUIL for Argentina, and payer details for PSE." howto: name: "Build a Stripe-style global checkout on BlindPay" steps: - name: "Onboard each merchant" text: "Send the merchant through BlindPay terms of service, then create a business customer and wait for KYB approval." - name: "Give the merchant a balance" text: "Create a BlindPay-managed wallet for the merchant to receive stablecoins from every checkout." - name: "Create a platform fee" text: "Create one partner fee and store its pf_ id to pass on every payin quote." - name: "Expose a checkout sessions API" text: "Let merchants create sessions with an amount in USD, line items, success and cancel URLs, and an Idempotency-Key." - name: "Build the hosted payment page" text: "Let the shopper pick a country and rail, collect only the payer details that rail needs, and show the quoted local amount." - name: "Create the payin and show instructions" text: "Create the payin from the quote within 5 minutes and show the Pix code, CLABE, account, payment link, or bank details with memo." - name: "Track status and notify merchants" text: "Consume payin webhooks, update the session, and send your own signed webhooks to the merchant." - name: "Let merchants withdraw" text: "Create a payout quote to the merchant's bank account and execute it before the quote expires." --- Yes. You can build a global checkout like Stripe Checkout on BlindPay. Your app owns the checkout sessions API and the hosted payment page. BlindPay owns the money: merchant KYB, live payin quotes, collection over Pix, SPEI, Transfers 3.0, PSE, ACH, wire, and RTP, settlement in USD stablecoins, partner fees, and payouts to the merchant's bank. This guide maps every piece of a Stripe-style checkout to the BlindPay building block behind it, as of October 2026. For the concept first, read [what a global payments checkout is](/resources/more/what-is-a-global-payments-checkout). To skip the hand build, the [Build a global checkout prompt](/prompts/build-a-global-checkout) has a coding agent build and test the whole platform for you. **Key takeaways** - A Stripe-style checkout on BlindPay has three parts you build (sessions API, hosted page, merchant dashboard) and one money layer you call (the BlindPay API). - Shoppers pay over seven local rails: Pix, SPEI, Transfers 3.0, PSE, ACH, wire, and RTP. One payin endpoint serves all of them. - Merchants price in USD. A receiver-denominated payin quote with `cover_fees: true` delivers exactly the price, and the shopper sees one local amount that includes fees and exchange. - The platform earns a fee on every payment through `partner_fee_id`, collected by BlindPay and released monthly. - Merchants withdraw with a payout quote over ACH, wire, RTP, or SWIFT (POBO/COBO) with UETR tracking and MT103 confirmations. ## Can you really build a Stripe-style checkout on BlindPay? Yes, as long as you split the job the right way: you build the checkout experience, BlindPay moves the money. That is the same split Stripe Checkout users rarely see, because Stripe bundles both halves. A Stripe-style checkout does five things. It creates a session for an order, sends the shopper to a hosted page, collects the payment with a method that fits the shopper's country, tells the merchant when the money arrived, and pays the merchant out. BlindPay gives you an API call for every money step in that list. The page, the session object, and the merchant dashboard are yours, which also means the brand on the page is yours. Who this is for: platforms that want to sell checkout to many merchants, and single businesses selling to Latin America and the US that want shoppers to pay with the bank app they already use. ## Which BlindPay building block replaces each Stripe Checkout piece? Each Stripe Checkout concept has a direct counterpart. The table maps them, BlindPay first, using Stripe's own description of [Checkout and Checkout Sessions](https://docs.stripe.com/payments/checkout) as the reference. | Checkout piece | On BlindPay | In a Stripe Checkout integration | | --- | --- | --- | | Session for an order | Your session object, backed by a BlindPay payin quote (5-minute lock) and a payin | Checkout Session | | Payment methods | `payment_method`: `pix`, `spei`, `transfers`, `pse`, `ach`, `wire`, `rtp` | Dynamic payment methods, more than 125 local methods per Stripe | | Local currency for the shopper | `currency_type: "receiver"` with `cover_fees: true`: USD price in, exact local amount out | Adaptive Pricing | | Merchant onboarding | BlindPay terms of service, then a business customer with KYB | Stripe Connect onboarding | | Platform fee | `partner_fee_id` on every payin quote, released monthly | Platform fees through Stripe Connect | | Payment status | `payin.new`, `payin.update`, `payin.complete` webhooks, plus your own signed webhooks to merchants | Checkout and payment webhooks | | Merchant balance | A BlindPay-managed wallet holding USDC or USDT | Stripe balance | | Payouts | Payout quote to ACH, wire, RTP, or SWIFT (POBO/COBO) | Payout schedule | | Public receipt | `GET /v1/e/payins/{id}`, no API key needed | Hosted receipt | Read it row by row. Every row on the BlindPay side is either a field you set or an endpoint you call, so the checkout logic stays in your code and the rails stay behind one API. ## What does the architecture look like? Four components, one database, one BlindPay API key that never reaches the browser. 1. **Merchant onboarding.** A merchant signs up, accepts BlindPay's terms of service (`POST /v1/e/instances/{instance_id}/tos` returns a link, and the `tos_id` comes back on your redirect), then submits KYB. KYB Standard takes 3 hours to 1 business day of manual review on production. Once approved, you create a managed wallet for the merchant's balance and issue the merchant an API key of your own. 2. **Checkout sessions API.** Merchants call your `POST /checkout/sessions` with an amount in USD, line items, success and cancel URLs, and an `Idempotency-Key`. You return a session with a URL to your hosted page. 3. **Hosted payment page.** The shopper picks a country and rail. You collect only what that rail needs, create a payin quote, and show the local amount with a countdown to `expires_at`. On confirm, you create the payin and show the instructions. 4. **Merchant dashboard.** Volume from completed payins, the wallet balance, a payments list, webhook delivery logs, and a withdraw button that runs a payout quote. [Designing a checkout sessions API](/resources/more/checkout-sessions-api-design) covers the session states and why a processing session never expires: once a payin exists, it cannot be canceled. ## How does a shopper pay on each rail? The hosted page changes by rail, but the BlindPay calls do not. You set `payment_method` on the payin quote, add `payer_rules` where the rail needs them, and read the one instruction field that rail returns. - **Pix (Brazil).** Collect a CPF or CNPJ for `pix_allowed_tax_ids`. BlindPay validates the check digits at quote time, so a typo fails before the shopper opens their bank app. Show `pix_code` as a QR code and copy text. Pix runs 24/7 and typically settles in minutes. [Accepting Pix from abroad](/resources/more/accept-pix-payments-from-abroad) has the details. - **SPEI (Mexico).** No payer rules. Show the `clabe` and the exact MXN amount, in whole pesos. Banco de México says [a SPEI payment should not take more than 30 seconds](https://www.banxico.org.mx/services/interbanking-electronic-payme.html) after approval. - **Transfers 3.0 (Argentina).** Collect a CUIT or CUIL for `transfers_allowed_tax_id`. Show the CBU or CVU account from `tracking_transaction.transfers_instruction`. The central bank describes [Transfers 3.0](https://www.bcra.gob.ar/en/transfers-3-0/) as transfers credited online in a maximum of 15 seconds. - **PSE (Colombia).** Collect the payer's full name, document type (`CC` or `NIT`), document number, email, phone, and bank code. Show a "Continue to your bank" button with the PSE payment link. - **ACH, wire, RTP (United States).** Show BlindPay's bank details and the `memo_code`, with a bold note that the memo is required to match the deposit. RTP is [instant, 24/7/365](https://www.theclearinghouse.org/payment-systems/rtp), while ACH and wire payin arrival can take up to 5 business days. One endpoint creates every payin: `POST /v1/instances/{instance_id}/payins/evm` with the `payin_quote_id`. The path name is historical and works for every rail. ## How do you keep the merchant's price exact? Price in USD and let the quote do the conversion. Create each payin quote with `currency_type: "receiver"`, `cover_fees: true`, and `request_amount` set to the session amount in cents. The merchant receives exactly that amount in stablecoins. The quote's `sender_amount` is what the shopper pays in local currency, fees and exchange included. Show that number large, label it "includes fees and exchange," and show the merchant's USD amount in small print. If the 5-minute quote expires before the shopper confirms, quote again on the next click. MXN, COP, and ARS amounts always come back in whole units. [Local currency pricing at checkout](/resources/more/local-currency-pricing-at-checkout) walks through display, charge, and settlement currency. ## How does the platform make money? Create one partner fee and attach it to every payin quote. `POST /partner-fees` takes `payin_percentage_fee` in basis points (100 means 1%) and `payin_flat_fee` in cents. Pass the returned `pf_...` id as `partner_fee_id`. Each quote reports `partner_fee_amount`, which is your revenue for that payment. BlindPay collects the fee during each payin, accumulates it over the calendar month, and releases it on the first day of the following month, after netting your BlindPay invoice. [Partner fees on live quotes](/resources/more/partner-fees-markup-on-live-quotes) covers fee types and how to price them. ## How do status updates and webhooks work? BlindPay tells you, you tell the merchant. Subscribe to `payin.new`, `payin.update`, and `payin.complete`. `payin.complete` fires when the payin finishes, so read its `status`: `completed` marks the session paid, while `failed` or `refunded` marks it failed. An `on_hold` payin is under manual review, so keep the session processing and tell the shopper the payment is being reviewed. Verify the `svix-id`, `svix-timestamp`, and `svix-signature` headers on every BlindPay call. Then send your own webhook to the merchant, signed with a per-endpoint secret, with retries on non-2xx responses. Send an `Idempotency-Key` on every BlindPay POST that creates a quote, payin, or payout, so a retry after a timeout replays the original response instead of creating a second payment. ## How does BlindPay fit into a global checkout? BlindPay is the money layer under the checkout you build. It runs terms of service and KYB for each merchant, prices every payment with a live payin quote, collects over Pix, SPEI, Transfers 3.0, PSE, ACH, wire, and RTP, and delivers USDC or USDT to the merchant's balance. Merchants withdraw with a payout quote to ACH, wire, RTP, or SWIFT (POBO/COBO) with UETR tracking and MT103 confirmations, and the same balance can pay out over Pix, SPEI, SEPA, and Faster Payments. Pricing: BlindPay combines a monthly plan (platform access) with per-transaction fees that vary by rail and network and are disclosed only in the live quote before execute. So the fee your checkout shows always comes from the quote's own breakdown, for that rail and that amount. Keep your card gateway for cards. BlindPay handles the local bank rails and settlement, so the two sit side by side on the same page. ## How do you build it without writing it by hand? Use the prompt. The [Build a global checkout prompt](/prompts/build-a-global-checkout) is one block of text you paste into a coding agent in an empty folder. It builds merchant onboarding with KYB, a checkout sessions API with signed webhooks, a hosted page for all seven rails, a merchant dashboard with withdrawals, a platform admin view, and a demo coffee store. Then it tests every flow end to end on a BlindPay development instance before it reports back. On a development instance, payins complete by themselves in about 30 seconds, and a $666.00 or $777.00 payment forces a failed or refunded result, so you can test every screen without moving money. Already running a store? [Integrate a global checkout](/prompts/integrate-global-checkout) adds the same flow to an existing app. ## Methodology and sources Stripe Checkout features come from [Stripe's Checkout documentation](https://docs.stripe.com/payments/checkout), read for this guide. Rail facts come from [Banco de México on SPEI](https://www.banxico.org.mx/services/interbanking-electronic-payme.html), the [BCRA on Transfers 3.0](https://www.bcra.gob.ar/en/transfers-3-0/), and [The Clearing House on RTP](https://www.theclearinghouse.org/payment-systems/rtp). BlindPay facts come from the [payins](/docs/payins), [payin quotes](/docs/payin-quotes), [partner fees](/docs/learn/partner-fees), [webhooks](/docs/learn/webhooks), and [cut-off times](/docs/kb/cut-off-times) docs. Requirements for merchant onboarding vary by jurisdiction, so confirm yours with your compliance counsel. ## What to do next Create a development instance at [app.blindpay.com](https://app.blindpay.com), add an API key to a `.env` file, and paste the [Build a global checkout prompt](/prompts/build-a-global-checkout) into your coding agent. You will have a working Stripe-style checkout with a paid order on every rail to show your team the same day.