Add Pix, SPEI, and PSE to the checkout you already run

You can add Pix, SPEI, PSE, Transfers 3.0, ACH, wire, and RTP to the checkout you already run without rebuilding it. Keep your page and your card gateway, add a "Pay by bank" option, and route it to BlindPay. The shopper pays from their own bank in local currency, and the merchant receives the order total in USD stablecoins.

This guide covers the minimal integration as of October 2026. For the full concept, start with what a global payments checkout is. Starting from zero instead? How to build a global checkout like Stripe with BlindPay covers the whole platform.

Key takeaways

• One "Pay by bank" button can cover Brazil (Pix), Mexico (SPEI), Argentina (Transfers 3.0), Colombia (PSE), and the US (ACH, wire, RTP).
• Stripe's test of 50+ payment methods found an average 7.4% conversion lift when a relevant method beyond cards was surfaced.
• A receiver-denominated BlindPay payin quote keeps your USD total exact and shows the shopper one local amount with fees included.
• One payin endpoint serves every rail, so adding a country is a new payment_method value, not a new integration.
• The Integrate a global checkout prompt hands a coding agent the full flow, including tests.

Why add bank payments to a checkout that already works?

Because many shoppers in Latin America pay from their bank app first. Card-only checkouts lose them at the payment step.

Stripe ran a holdback test across more than 50 payment methods. When businesses dynamically surfaced at least one additional relevant method beyond cards, conversion rose 7.4% and revenue 12% on average. Results varied by method, country, and industry, and Pix was not in the test. Baymard's survey of US shoppers lists "there weren't enough payment methods" as a reason for 9% of checkout abandonments.

Adding everything is not the answer either. Stripe's localization guide says 15 options do not necessarily improve conversion, and recommends the two or three that matter for each customer segment. How many payment methods a checkout should offer has a market-by-market method map.

Which rail should each shopper see?

Show the rail that matches the shopper's country, and only that rail plus your existing methods.

Pix runs 24/7 according to Banco Central do Brasil, and BlindPay typically sees Pix, SPEI, Transfers 3.0, and PSE payins arrive in minutes. ACH and wire payins can take up to 5 business days to arrive, so present them for larger or B2B orders and say so on the page.

How do you integrate it step by step?

Six steps. Most of the code is on your side: the order model and the instructions screen.

1. Set up the merchant. Accept BlindPay's terms of service (POST /v1/e/instances/{instance_id}/tos returns a link, and the tos_id comes back on your redirect). Create a business customer with KYB, then a managed wallet. A single merchant does this once and stores the ids in config.
2. Add the option. Put "Pay by bank" next to your card form. When the shopper picks it, ask for their country.
3. Collect payer details. Only what the rail needs: pix_allowed_tax_ids for Pix (BlindPay validates CPF and CNPJ check digits at quote time), transfers_allowed_tax_id for Argentina, and the six PSE fields for Colombia.
4. Quote. POST /v1/instances/{instance_id}/payin-quotes with wallet_id, currency_type: "receiver", cover_fees: true, request_amount set to the order total in cents, payment_method, and payer_rules. Show sender_amount in local currency with a countdown to expires_at. MXN, ARS, and COP come back in whole units.
5. Create the payin. POST /v1/instances/{instance_id}/payins/evm with the payin_quote_id and an Idempotency-Key tied to the order, so a double click never creates two payins. A payin cannot be canceled, so lock the rail once it exists.
6. Fulfill on webhook. Register an endpoint, verify the svix-id, svix-timestamp, and svix-signature headers, and read the payin's status on payin.complete. completed fulfills the order, failed or refunded cancels it, and on_hold keeps it pending while compliance reviews it.

The instructions screen matters more than it looks. Bank transfer checkout UX covers how to show a Pix code, a CLABE, and a required memo so shoppers send the right amount the first time.

How do bank payments reconcile with your card orders?

Use one order table and one status field, and let the payment source fill in its own reference.

Card orders already carry the gateway's charge id. Bank orders carry the BlindPay payin id (pi_...), the rail, the local currency and amount, and the USD amount received. Status comes only from the payin's status, never from a wallet balance change, because a balance tells you money moved but not which order it belongs to.

For receipts, GET /v1/e/payins/{id} returns the payin's public fields without an API key, so your order confirmation page can show live status to the shopper.

What changes if you host checkout for other merchants?

Three things: onboarding, keys, and fees. The payment calls stay the same.

A single merchant accepts terms of service and passes KYB once. A platform runs that flow for every merchant it signs: a sign-up screen, the BlindPay terms link, a KYB form, and a status screen that waits for approval. KYB Standard takes 3 hours to 1 business day of manual review on production, so tell new merchants when to expect it. Each approved merchant gets its own managed wallet, so balances never mix.

Merchants call your API, not BlindPay's, so issue each one its own secret key and store only a hash. Then create one partner fee and pass its partner_fee_id on every payin quote. The quote reports partner_fee_amount for that payment, BlindPay collects it during the payin, and the month's total is released on the first day of the next month. Who pays the fees at a cross-border checkout covers how to show both fees on the page.

How does BlindPay fit into a global checkout?

BlindPay is the bank-rail and settlement layer next to your card gateway. It onboards the merchant with terms of service and KYB, prices each bank 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 managed wallet. From that balance the merchant withdraws with a payout quote over ACH, wire, RTP, or SWIFT (POBO/COBO) with UETR tracking and MT103 confirmations.

Hosting checkout for other businesses? Switch the prompt's mode line to "platform," onboard each merchant separately, and pass a partner_fee_id on every payin quote to earn a fee per payment.

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.

How do you test it before going live?

Run every rail on a BlindPay development instance first. Payins complete by themselves about 30 seconds after creation, KYB approves itself, and two amounts force the unhappy paths: $666.00 ends failed and $777.00 ends refunded. Payment instructions are placeholders there, so show a test-mode note instead of a QR code.

Then pay one real order per rail on production before you announce it. Real Pix codes, CLABEs, and memos only exist there.

Methodology and sources

Conversion and abandonment figures come from Stripe's test of 50+ payment methods, Stripe's payment localization guide, and Baymard's cart abandonment research. Pix availability comes from Banco Central do Brasil. BlindPay facts come from the payins, payin quotes, webhooks, and sandbox vs. production docs.

What to do next

Pick the two countries where your shoppers bounce at the card form. Create a BlindPay development instance, paste the Integrate a global checkout prompt into your coding agent with those two countries named, and pay one test order per rail before you ship the button.