How Bachs works

Bachs is the payments and billing platform for African internet businesses and the customers they serve anywhere: one API and one dashboard for checkout, subscriptions, payouts and sub accounts. This page gives you the model that every guide builds on.

​

The three parties

Every flow on Bachs involves the same three parties.

• You, the business. You create products, create checkouts, receive webhooks, hold a balance and withdraw from it.
• Your customer. They pay at checkout with a card, a bank transfer, mobile money or crypto, in their own currency. All payment methods are available through a single checkout, and your customer sees only the methods relevant to their currency and location.
• Bachs. It renders the hosted checkout, processes the payment, holds the funds in your Bachs balance, and sends the money to your payout destination when you ask.

Your customer pays in their currency, you settle in yours, and Bachs carries the conversion between the two.

​

The flow of a payment

A one-time sale moves through five objects: a product, a checkout session, a payment, your balance and a payout.

1. Product. One thing you sell, from your catalog. A checkout is priced with a product_cart of catalog products, or with a raw pricing amount when you have no product to reference.
2. Checkout session. It ties a price to a customer and returns a hosted checkout_url. Bachs resolves pricing, handles currency conversion, selects payment methods and processes the payment. You send the customer to the URL and listen for the result.
3. Payment. When the checkout is paid, Bachs redirects the customer to your success_url and sends checkout.completed and collection.succeeded to your webhook endpoint. Either can arrive first: fulfil the order on whichever arrives first, once. A free checkout sends only checkout.completed.
4. Balance. Funds collected through Bachs are held in your Bachs balance.
5. Payout. A payout moves money from your balance to your own bank account or wallet. You save a destination, get a quote if the currencies differ, create the payout, then track payout.paid or payout.failed. An accepted payout is not proof of completion.

​

Three currency sets

Collection currencies and withdrawal currencies are separate. What you can collect from customers is not the same as what you can withdraw. A third set matters as well: the currencies an account can hold as a balance, which is narrower than either of the other two. Holding a currency decides what an account settles in, not what it can charge in. A checkout can be priced in any supported currency, held or not, and converts on the way to the balance at the rate quoted on the charge. On the way out, international bank and mobile money withdrawals draw from your USD balance, and a payout in another currency needs a conversion quote, created before you send it, that fixes the source and destination amounts. You are never forced to convert.

​

Sandbox and live

Bachs runs two separate deployments with the same API. Endpoints, request structure and response shapes are identical; only the base URL and the keys change. API keys are environment-specific, so a key only works against its own URL. Nothing is shared between the two, not balances, customers, payout destinations, webhook endpoints or API keys. Sandbox payments are simulated, succeed by default, and send the same webhooks as production, so you can test your handler against every outcome before anything real moves. Sandbox keys are available the moment you sign up. Live keys need account verification, which happens once and covers your product, your identity and your withdrawal account. Most reviews finish within 48 hours. Once you are verified, going live means swapping your API keys.

​

Read next