Paying an account without a charge

What you’ll build

Most platforms taking a cut of a sale should use a direct or destination charge, where Bachs ties the split to the charge for you. This page is for the cases those two cannot cover: paying an account with a standalone transfer, either with no charge behind it at all (a bonus, a correction, a balance top-up) or with a charge you collected on your own platform that you split afterward. By the end you’ll have sent a transfer to an account and read it back. If a charge is behind it, you’ll also have collected that charge and tied the transfer to it with transfer_group. Unlike a direct or destination charge, nothing about a charge says a split is coming, and a transfer with no charge behind it needs no charge at all. Bachs does not record a link between a charge and the transfers you send against it. If you want that link, you supply it yourself.

When to use it

You’re paying an account with no single charge behind it. A bonus, a correction, a batch of payouts on your own schedule rather than per sale, topping up an account’s balance. Direct and destination both require a charge to hang the split on, so neither can serve this case.
You need to split one charge across several accounts. Direct and destination each name a single account. Splitting one sale many ways needs this shape instead.

If there’s a charge behind the transfer, you are comfortable owning the correlation between it and the transfers that followed, since Bachs does not keep that link for you. If there’s no charge at all, there’s nothing to correlate: you send the transfer directly.

The flow

A customer pays the platform, which sends a separate transfer to each account and pays Bachs its processing fee.

When there’s a charge behind it: the customer pays your platform, the same as any charge with no account involved. Your platform settles Bachs’s processing fee out of it. Once the charge settles, you send one or more transfers out of your own available balance, each carrying the transfer_group you chose for that charge. What you never transfer out is your cut; there is no platform_fee field that moves money on this shape. When there’s no charge behind it: there’s no customer payment to wait on. You send the transfer straight out of your own available balance whenever you decide to, the same call, without a charge to settle first.

The walkthrough below is charge-based, since that’s the more involved case. If you’re paying an account with no charge behind it at all, skip straight to Transfer each account its share: it’s the same transfer call, made whenever you decide to send it, with no checkout to create and no settlement to wait on first.

Create the checkout as your platform

Do not send X-Account-Id and do not name a transfer_data.destination. The charge belongs to your platform outright.

curl https://sandbox-api.bachs.io/v1/checkout-sessions \
  -H "Authorization: Bearer sk_sandbox_abc123xyz..." \
  -H "Content-Type: application/json" \
  -d '{
    "product_cart": [
      {
        "product_id": "prod_8f2a71c4e05b",
        "quantity": 1,
        "pricing": { "price_type": "fixed", "amount": "100000.00" }
      }
    ],
    "customer": { "email": "jane@example.com" },
    "success_url": "https://example.com/thank-you",
    "cancel_url": "https://example.com/checkout"
  }'

{
  "checkout_id": "chk_5b6e19d42f8a",
  "status": "open",
  "source_type": "CHECKOUT_SESSION",
  "amount": "100000.00",
  "currency": "NGN",
  "checkout_url": "https://checkout.bachs.io/c/Sy2wKp6RmB4vNqT",
  "platform_fee": null,
  "products": [
    {
      "product_id": "prod_8f2a71c4e05b",
      "quantity": 1,
      "unit_amount": "100000.00",
      "currency": "NGN",
      "price_type": "fixed",
      "line_total": "100000.00"
    }
  ]
}

platform_fee has no effect on this shape and is left unset here; it returns null. See Platform fees if you send it anyway, since it is still bounds-checked on the request.

Send the customer to the checkout, then wait for settlement

Redirect the customer to checkout_url. Once checkout.completed arrives with data.payment_status: "paid", note data.charge.id. Transfers draw on available_balance, not pending_balance, so wait for the charge to settle before sending one. Check with GET /v1/balances and read pending_settlements_by_day. See Balances.

Transfer each account its share

Choose a transfer_group, the charge id is a convenient choice, and send it on every transfer that splits this charge. Nothing about the request ties it to the charge automatically.

curl -X POST https://sandbox-api.bachs.io/v1/transfers \
  -H "Authorization: Bearer sk_sandbox_abc123xyz..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ch_2f8a71c4e05b-seller-share" \
  -d '{
    "destination": "acct_3Wq8ZfT1yHnJ5sVe",
    "amount": "70000.00",
    "currency": "NGN",
    "transfer_group": "ch_2f8a71c4e05b",
    "description": "Order #4471 seller share"
  }'

{
  "id": "tr_8c1e04a7b93f2d6540ab",
  "source": "acct_7KpQ2mNv4XbR9dLc",
  "destination": "acct_3Wq8ZfT1yHnJ5sVe",
  "amount": "70000.00",
  "currency": "NGN",
  "status": "paid",
  "description": "Order #4471 seller share",
  "metadata": {},
  "transfer_group": "ch_2f8a71c4e05b",
  "kind": "manual",
  "source_charge_id": null,
  "created_at": "2026-08-12T10:31:00.000Z"
}

kind is manual on every transfer you send here, since you created it, rather than a payout that settlement records for a seller’s share of a destination charge. source_charge_id is null for the same reason: this transfer is not the direct product of a charge settling, so nothing populates it. transfer_group is the only field that connects this transfer back to the sale, and it is yours to set and yours to query on later. See Transfers for the object’s full field reference, the two-directions model, and the standard error table.

Read the transfer back

List by transfer_group from your own records, or by account:

curl "https://sandbox-api.bachs.io/v1/transfers?connected_account_id=acct_3Wq8ZfT1yHnJ5sVe&limit=50" \
  -H "Authorization: Bearer sk_sandbox_abc123xyz..."

Listing does not filter on transfer_group; store it against the order in your own database so you can go from a sale to the transfers that split it.

With this shape

The charge lands in your platform’s balance. Nothing about the charge names an account, so nothing splits automatically.
Bachs does not record a link between a charge and the transfers that follow it. transfer_group is the only correlation, and you own it end to end.
A transfer moves money out of available_balance only; a charge has to settle before its funds can be transferred. See Balances.
To recover funds you already sent an account, act as it with X-Account-Id and send a transfer with destination: "self". This is a second transfer in the opposite direction, not a reversal, so it only succeeds while the funds are still in the account’s balance. See Transfers.
Each transfer records as kind: "manual", distinct from the payout rows settlement writes for destination charges. A platform’s cut of a sale is never a transfer, on any shape: it settles as its own record, readable at Platform fees.
A refund debits your platform’s balance for the full amount the customer paid. Nothing about a separate transfer already sent is reversed by a refund. See Refunds.
A lost dispute drains your platform’s available balance, then its pending balance. Any amount still owed drives the available balance negative: that negative balance is the debt, and it heals as your platform’s own future settlement credits land. A dispute also debits a flat dispute fee when it opens, whether it is later won or lost. See Disputes.
The account needs transfers active to send or receive a share, and payouts active to withdraw it once it has one. Your platform needs connect active to send a transfer to an account, but not to recover one back. See Capabilities.

Errors

Transfer errors return the standard error envelope. See Transfers for the full table; the ones you’ll hit first on this shape:

Cause	Resolution
The transfer amount is more than the source’s `available_balance` in that currency (`INSUFFICIENT_BALANCE`, 400). A charge that hasn’t settled yet doesn’t count, even though the charge succeeded.	Check `GET /v1/balances` and wait for the charge to settle before transferring against it.
The account’s `transfers` capability is not `active` (`FORBIDDEN`, 403). Checked on the account regardless of direction.	Request and activate `transfers` on the account before sending or recovering a share. See Capabilities.
Your platform’s `connect` capability is not `active` on an outbound transfer (`FORBIDDEN`, 403). Not checked when recovering funds back to your platform.	Activate `connect` on your platform. See Become a platform.
The account has not activated `payouts` (no error from `/v1/transfers`; the withdrawal itself is refused). A transfer can still succeed and leave funds sitting in the account’s balance.	Request and activate `payouts` on the account before it tries to withdraw.

Get started

Core concepts

Reversals and risk

Onboard an account

Build with Connect

Go live

Paying an account without a charge

What you’ll build

When to use it

The flow

With this shape

Errors

Next steps

​What you’ll build

​When to use it

​The flow

​With this shape

​Errors

​Next steps

What you’ll build

When to use it

The flow

With this shape

Errors

Next steps