Outgoing transfer
Send a Bre-B transfer from your tenant account to another participant.
An outgoing transfer is a Bre-B payout: funds leave your tenant account at Mono and arrive at a destination identified by a payment key — an alias such as a phone number, document ID, email, an alphanumeric Bre-B identifier, or a merchant code. Unlike a card or ACH transfer, Bre-B transfers settle in real time, 24/7, and the destination is resolved at runtime against the central directory.
Use this flow when your business pushes money to an end user — refunds, payroll over Bre-B, marketplace seller payouts, treasury sweeps to another participant, or customer withdrawals.
This page is a flow scaffold. The full version will include code samples for each step and reconciliation patterns. The sequence, lifecycle, and error catalog are already documented in detail — see below and the linked pages.
Before you start
You will need:
- A Bre-B participant account with Mono and OAuth client credentials. See Authentication.
- A tenant account with sufficient balance to cover the transfer.
- The appropriate scopes:
target_resolutionsfor a known key,target_discoverieswhen the key is unknown, andoutgoing_transfersto send the payment. - A webhook endpoint subscribed to outgoing-transfer events and target-resolution events, with signature verification in place.
- An idempotency key per transfer.
Sequence overview
- Obtain the target — if you know the exact payment key, resolve it. If you know the beneficiary and account but not the key, discover the target. Both paths return the holder and destination data for confirmation.
- Confirm with the payer — show the resolved name to the user and obtain explicit confirmation before dispatching.
- Dispatch the transfer — call the outgoing-transfer endpoint with the resolved target, amount, currency, and idempotency key.
- Track the lifecycle — the transfer moves through pending, sent, accepted, settled, or rejected states. Webhooks fire on every transition.
- Reconcile — on settlement, credit the operation in your books; on rejection, surface the failure reason to the user using the error catalog.
Steps
The full step-by-step (with curl, Node.js, and Python samples) is pending. Until it is published, see:
- Outgoing transfer states — the complete state machine, transitions, and terminal states.
- Target discovery — find a key from beneficiary and account data before sending.
- Outgoing transfer errors — rejection reasons and recommended handling.
- Webhook payloads — the envelope and event schemas.
- Webhook signatures — HMAC-SHA256 verification.
- Sandbox: outgoing transfers — simulate the full lifecycle without real money.
- Sandbox: target discovery — obtain deterministic single-use targets before sending.
Next steps
- QR collection — the payin counterpart of this flow.
- Outgoing transfer states — the lifecycle every outgoing transfer follows.
- Idempotency Keys — required for safe retries on every dispatch.