Guide · Merchants adding cards or local bank rails to a crypto checkout

How to accept bank and card payments alongside crypto

Most checkouts make you choose: a card processor that owns the whole experience, or a crypto rail that confuses anyone not already holding assets. The useful answer is both behind one interface - cards for the buyers who reach for plastic, local bank rails where those dominate, crypto where it wins outright.

U.CASH's model keeps you the merchant of record: cards run through YOUR processor account, bank rails settle to YOUR registered accounts, and crypto goes to YOUR wallet. One checkout, three rail families, zero custody you didn't choose.

You needA U.CASH Pay account and storeFor cards: your own Stripe, Verifone, or PayPal merchant accountFor local rails: the bank or mobile-money account the rail settles to

Start now → All guides

Step by step

Every step, in order.

Step 01

Turn on the card rail

Connect your processor: Stripe, Verifone, or PayPal. The checkout hands card payments to your account under your pricing - U.CASH takes no cut of the card fee and never sits in the flow.

Step 02

Add the local rails you need

Enable bank rails per market: SEPA for the eurozone, ACH and wires for the US, M-Pesa, PIX, UPI, and the rest of the 22-rail directory. Each settles to the registered account on file for that rail.

Step 03

Set the offering per checkout

Choose what each checkout offers: crypto always, cards where your processor covers the buyer's market, local rails where they clear. Buyers see payment options that make sense for where they are.

Step 04

Price once

Checkouts price in your billing currency across all rails - the crypto legs convert at payment time, the fiat legs charge in the rail's own currency. One number for the buyer, however they pay.

Step 05

Reconcile across rails

Every payment, on every rail, lands in one order ledger with its own reference: processor charge ID, bank transfer reference, or on-chain transaction. One export covers all three families.

The part that matters

The merchant-of-record distinction is the load-bearing fact of this architecture. A card processor knows you: your account, your pricing, your payout schedule, your chargeback history. Running cards through your own account keeps that relationship - and its fees, and its risk tolerances - exactly where you negotiated them. The alternative, a platform bundling cards into its own merchant account, rents you someone else's terms at a markup and holds your money on their schedule. The local-rail leg follows the same principle with a regional accent: M-Pesa settles to the mobile-money account Safaricom knows, SEPA to the IBAN it belongs to. The rail's KYC, the rail's limits, the rail's dispute process - all of it stays between you and the rail. What the checkout adds is the unification layer: one interface, one order ledger, one webhook vocabulary describing payments that arrived by fundamentally different mechanics.

Go deeper

FAQ

Do I need my own Stripe account?

For cards, yes - and that is the point: your account, your pricing, your money on your payout schedule. U.CASH fronts the checkout, not the merchant relationship.

Can buyers pay by bank transfer?

Yes, through the 22 local bank rails - SEPA, ACH, domestic wires, M-Pesa, PIX, UPI and the rest - each settling to the registered account for that rail in its own currency.

How do refunds work across rails?

Per rail: card refunds flow back through your processor, bank-rail refunds as transfers out, crypto refunds as on-chain sends. The order view initiates all three with the rail's own semantics.

Does the card fee change because crypto is also offered?

No. Your processor prices your card volume exactly as if the checkout were cards-only; offering crypto alongside costs nothing on the card leg.

Keep going