Skip to main content
In this guide you’ll create an account, send it through onboarding, create a checkout that charges the account and takes your platform fee out of it, and read that fee back once the charge settles. By the end you’ll have run a full direct charge without moving real money.

Before you start

  • A sandbox API key (sk_sandbox_...). See Authentication.
  • The connect capability active on your account. See Become a platform.
  • A product to sell. See Products.
  • A webhook endpoint with event_source set to connect or all, so your platform receives an event that originates with the account. See Connect events.

Steps

1

Create the account

This account is going to be the merchant of record on a direct charge, so it needs a payment-accepting capability, and it will also be paid out, so it needs the recipient persona too. Name both as keys in configuration, and name each capability it needs under the persona it belongs to.
The response carries exactly the three capabilities named above. Keep the id. Every step below uses it.
In sandbox, a capability whose persona is applied is granted active at creation, with no review. card_collection is requested against merchant, named in the same call, so it comes back active immediately, unlike in production, where it lands restricted until a reviewer enables it. See Testing.
card_collection accepts cards charged in USD. To accept Nigerian naira cards as well, request ngn_card_collection alongside it — it is a separate capability, so this NG merchant would name both under merchant.capabilities. Requesting one does not enable the other. See Capabilities.
2

Send it through onboarding

card_collection is already active, but a real account still needs its requirements satisfied to stay eligible, and this is the flow that collects them.
Open url and complete the flow. To build the interface yourself instead, see Onboard through the API.
3

Confirm the capability is active

Confirm the state at any point rather than waiting on it, since in sandbox card_collection is already active from step 1:
In production, the same create call leaves card_collection restricted, and enabling it on review fires capability.updated:
capability.updated
4

Create the checkout as the account

Send X-Account-Id with the account’s id. Its presence, on its own, is what makes this a direct charge: the account becomes the merchant of record, and the sale lands in its balance. Add platform_fee for your cut, in the base currency of the sale, taken from the account’s proceeds.
Out of the 100000.00 NGN the customer pays, 20000.00 is your cut. The rest, minus Bachs’s processing fee, is the account’s. See Platform fees and Direct charges.
5

Send the customer to the checkout

Redirect the customer to checkout_url. Bachs hosts the payment page and collects the charge against the account.
6

Receive the webhook

Bachs sends checkout.completed once the customer finishes. Check data.payment_status: paid means a charge was made.A direct charge’s event originates with the account, not your platform. This is why the webhook endpoint you set up before starting needed event_source set to connect or all: with the default, account, this event never reaches you.
Event
7

Read your cut back

Your platform fee is not a transfer: it settles as its own record once the charge settles, never sooner. Read it from GET /v1/platform_fees:
collected_from is the account whose sale funded the fee, and earned_by is your platform. charge ties it back to the checkout’s charge.

What happens next

You have run a direct charge end to end: an account that accepts money, and a platform fee that comes back to you. Going live is a key swap: the same calls against https://api.bachs.io with an sk_live_ key. See Take Connect live.

Next steps