Bre-B

Collect instant COP payments through Colombia's Bre-B scheme: keys, QR codes, and limits.

Bre-B is Colombia's instant-payment scheme, operated by Banco de la República: bank-to-bank transfers that settle in seconds, around the clock, addressed by a key (llave, a short alias like a cellphone number registered in a central directory) or a QR code. co_breb is the payin method that collects over that rail: Mono registers a key for you, the payer pays to it from their own banking app, and the money is validated and credited within seconds.

It settles exclusively in COP.

How a Bre-B payin works

Every Bre-B payin follows the same five steps:

Your template (or intent) requests a Bre-B payment token. Mono registers the key with the network, an asynchronous step announced by the ready / ready_to_pay webhooks.
You show the key or QR to the payer.
The payer pays from their bank's app, by entering the key or scanning the QR. No checkout form, no card data, no credentials on your side.
The network presents the payment to Mono, which validates it against your rules (amounts, expected payers, template state) and authorizes or rejects it in the same interaction.
The payin is created and moves through its lifecycle; webhooks keep you informed.

Because the payment originates in the payer's bank, the payer's identity (instrument.payer: names, document, person type) and account (instrument.data) arrive with the payment, which is what makes expected_payers enforceable without asking the payer for anything.

Those steps run in one of two flows. The difference is whether you know which payment is which before the money arrives.

Unreferenced payment: one key for many payers

A template with key_per: "template" (the default) shares one key and, if you ask for it, a static QR. Any payer can pay to it, any number of times. Each payment is anonymous until it arrives: you learn who paid from the payin itself. It fits top-ups, donations, and in-store payments.

Referenced payment: one intent per payment

A referenced payment is one you declare before it arrives, so Mono can tie it back to your order. Each intent gets its own key and a dynamic QR with a fixed amount. The intent comes from a template with key_per: "intent", or is created directly against a subaccount. It fits checkouts and invoices.

If the attempt fails, the intent re-arms: it goes back to ready_to_pay, and the payer can retry against the same key while the 30-minute window lasts. The Collect with intents flow covers every ending.

Keys and QR codes

Token	Scope	Behavior
Key (`key_per: "template"`)	Shared: the whole template	Static: any payer, any number of payments (`multiple_use`).
Static QR	Shared: the whole template	Encodes the template key; no fixed amount.
Key (`key_per: "intent"`)	One intent	Minted per expected payment; ties the payment to the intent.
Dynamic QR	One intent	Single use, fixed amount, expires with the intent.

Key types are assigned by the network at registration: cellphone, email, alphanumeric, identification, or merchant_code. You can request a custom alias with method_params.co_breb.custom_key_value and QR merchant data with qr_code_data.

Limits and timing

Per-transaction cap: a single Bre-B payin is capped at $12,110,000 COP. This is the network's per-transaction limit as applied by Mono; the network adjusts it periodically, so treat it as a current value rather than a constant. A payment above it is rejected by the rail. A template's maximum_payin_amount can only tighten this cap, never exceed it.
Intent window: a Bre-B intent is payable for 30 minutes after ready_to_pay. Within that window, failed attempts re-arm the intent: the payer can retry against the same key.
Settlement: approved payins reach your funding account in settlement batches.

Next steps

Payment tokens: the key and QR model in detail.
Top-up flow: a permanent key per subaccount.
Collect with intents: dynamic QRs per payment.