How money moves through Bachs, from checkout to your bank account

There's a moment every internet business hits the first time it sells past its own border. Your product, built wherever you are, which for a lot of us is Lagos or Nairobi or Accra, gets its first customer somewhere else. And in the same instant, a second job appears next to your real one.

That customer in Nairobi pays with mobile money, not a card. The next, in Lagos, wants a bank transfer. One in London wants their card, in pounds. Each one raises the same question with a different face: if you accept payments in a handful of currencies, are you now a business that has to hold a handful of currencies too? Who absorbs it when the rate moves? Which balances, in which markets you've never operated in, are suddenly yours to manage?

None of that is the product you set out to build. It's overhead you inherit for being wanted somewhere other than home. We know the shape of it precisely, because we hit the same wall running a product of our own, and the tools available assumed we were somewhere else and worked with us grudgingly. Bachs Checkout is what we built to make that second job disappear. This is how it does it.

One integration, not four

Everything starts with a checkout session. Your server asks Bachs for one, and gets back a hosted link. A single call is the whole integration surface for taking a payment. You send the customer to the link it returns, or you drop it into a modal on your own page so they never leave your site. Bachs renders the page, works out the pricing, decides which payment methods to show, handles any currency conversion, and processes the charge. When it's done, Bachs sends your server a collection.succeeded event, and that webhook, not the browser, is what you fulfil the order on. A customer can close the tab a second after paying; a webhook can't be dropped the same way.

The reason this matters isn't the elegance of one API call. It's that the alternative, in this part of the world, is usually three or four separate integrations bolted together and a pile of branching logic to decide which one a given customer should see. That's the work Bachs Checkout takes off your plate, and it's most of the second job.

Every payment method, wherever your customer is

A single Bachs checkout can offer cards, bank transfer, mobile money, and crypto, and it shows each customer only what makes sense for them. Cards clear in US Dollars and in Naira. Bank transfer covers Naira. Mobile money reaches nine currencies across the continent, from Cedi and Shilling to the CFA francs. Crypto settles in stablecoins. A buyer paying Kenyan Shillings sees mobile money; a buyer paying Naira sees bank transfer and local cards; a global buyer sees their card. You create one session, and Bachs resolves the right menu for each person.

Pricing bends the same way, through adaptive pricing. Price a product in US Dollars, and Bachs shows each customer that price converted into their own local currency at the live rate, so nobody is staring at a foreign number wondering what it'll really cost them. If you'd rather your price in a specific market not drift with the exchange rate, you pin it: set an exact local amount and everyone there pays precisely that. And if you price a product directly in a local currency instead of dollars, that price is simply fixed everywhere. The rule underneath is small and worth keeping: dollars convert at checkout, every other currency is a hard price.

The effect on your side is that you set a price once and it arrives, correctly, in front of a customer in Kampala and a customer in Toronto, without you maintaining a table of prices per country or writing a line of geography logic.

Three currencies, kept apart

This is the idea that makes the rest safe to lean on, and it's the one most payment setups get wrong.

Accepting a currency is not the same as holding one. In most systems those are welded together: the moment you take Cedi, you're holding Cedi, reconciling it, exposed to it. Bachs separates them on purpose. In any sale there are three distinct currencies, and they never have to agree. There's the one a product is priced in. There's the one a customer pays in. And there's the one you settle and keep.

You can price in any of eleven supported currencies. Your customer pays in whichever suits them. And the money lands in your balance in your settlement currency, US Dollars or Naira, converted on the way in. You are never handed a balance in a currency simply because someone paid you in it. Collecting Shillings does not turn you into a business that manages Shillings, and it doesn't hand you the exchange-rate risk either. Bachs carries the conversion and the risk, so "I wonder what the rate did to my revenue this week" stops being a sentence you have to think.

So the plain answer to whether Bachs is multi-currency: yes, in the way that actually helps. Every currency on the way in, one or two you understand on the way out.

How currency settlement actually works

Settling into your balance and having money you can move are two slightly different moments, and it's worth knowing the gap so nothing surprises you.

A charge lands in your pending balance first, then becomes available on a schedule set by the currency it came in. Naira is immediate. Dollars take two days. Most other African currencies take one, released in a batch each morning rather than at some unpredictable hour. From there you withdraw to a bank account, a mobile money wallet, or a crypto wallet, or you set a payout schedule and let each settled balance pay itself out to your default destination without you touching it again. Turn on an instant schedule and the money leaves for your bank about a minute after it settles, bundled into a single payout rather than a fee per sale.

What you get from that is a straight line. Not a relay between providers where the money goes quiet in the middle and nobody can tell you when it lands, but one system with one set of rules from a customer's tap to your account, and a settlement date you can actually put on a screen for yourself.

The point

A builder in Lagos with customers in five countries should get to spend the day on the product, the way a builder in San Francisco does. Not on foreign exchange, not on settlement calendars, not on a spreadsheet tracking which balance holds what in a currency they never chose. Your customers pay the way they already pay. You keep the money in the currency you already use. The infrastructure underneath was built for where you are, rather than adapted to it after the fact.

If the reason you've been slow to chase that first international customer is everything that came after them last time, this is where that reason runs out. You can wire up a checkout in a sandbox today, watch the entire flow work end to end before any real money moves, and then point it at the world. The second job stays gone. You keep the first one.