How to build a global checkout like Stripe with BlindPay

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. To skip the hand build, the Build a global checkout prompt 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 as the reference.

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 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 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 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 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, 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 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 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 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 adds the same flow to an existing app.

Methodology and sources

Stripe Checkout features come from Stripe's Checkout documentation, read for this guide. Rail facts come from Banco de México on SPEI, the BCRA on Transfers 3.0, and The Clearing House on RTP. BlindPay facts come from the payins, payin quotes, partner fees, webhooks, and 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, add an API key to a .env file, and paste the Build a global checkout prompt 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.