Payins vs other Mono products
Which Mono product to use to receive money — Core Payins, Banking collection links, or Bre-B Participant.
Mono has three products that receive money, and picking the wrong one costs an integration. They are not tiers of the same thing: each lands the money in a different kind of account, and that choice decides what you can build on top of it. This page compares them so you can tell whether Payins is what you need — and what it gives you that the others do not.
If you already know you are collecting into Core subaccounts, skip this page and start with Templates.
At a glance
| Core Payins | Banking collection links | Bre-B Participant collections | |
|---|---|---|---|
| Rails | Bre-B today; PSE and cards in progress | PSE only | Bre-B only |
| Multi-currency | In progress | COP only | COP only |
| Credits into ledger accounts | Yes | Not supported | Not supported |
| Fees charged to subaccounts | Yes — configurable to your needs | No | No |
| Getting the money to your bank | Manual or automatic settlement, depending on where your bank account is | Depends on the ACH cycles | Depends on the model you operate under: as a gateway (your own account at the allied bank) the funds are available immediately; as an aggregator, Mono's finance team processes the delivery |
| API-only integration | Yes | Yes | Yes |
| Mono-hosted checkout | In development | Yes | No |
| The product also does | Ledger, cards, spending controls, payouts | ACH / Transfiya / Turbo transfers, cards | Outgoing Bre-B transfers, payment-key directory resolution |
What each one is for
Core Payins
Use it when your product holds balances for end users and money needs to arrive into them. It is the collection half of Core: every payment is validated against rules you defined ahead of time, credited to a subaccount on the double-entry ledger, charged its fees, and delivered to your bank account in settlement batches. Wallets, marketplace seller balances, and any product where "who does this money belong to?" has an answer inside your ledger.
What it gives you that the others do not: the four-entity model — templates that define the rules once, intents that pre-identify a specific expected payment, payins with their full lifecycle, and settlement batches — plus per-payment fee overrides and a payer allowlist.
Banking collection links
Use it when you want a customer to pay you from their bank account over PSE, and the money can land in your organization's Banking account. You create a link, share it, and the payer completes the payment on Mono's hosted form or on a frontend you build yourself. The classic e-commerce checkout case in Colombia.
Bre-B Participant collections
Use it when your product plugs into Bre-B directly as a participant tenant at Mono, and you also need the other half of the network: dispatching outgoing transfers and resolving payment keys through the central directory. Collections credit tenant accounts, and you manage the keys and QR codes yourself.
Choose by scenario
| Your case | Product |
|---|---|
| End users top up a wallet balance you keep for them. | Core Payins |
| Marketplace where each seller has a balance you later pay out. | Core Payins (with Core payouts) |
| E-commerce checkout paid from a Colombian bank account over PSE. | Banking collection links |
| You send and receive on Bre-B as a participant, and manage keys and the directory. | Bre-B Participant |
| You need each payment pre-identified before the money arrives. | Core Payins intents, or a per-payment link or QR on the other two |
Using more than one
They compose. A consumer wallet, for example, can keep balances on the Core ledger while collecting over more than one rail — see the use-case mapping for the combinations Mono customers run today. What you should not do is split the same balance across two products: pick where the money lands first, and the rest follows.
Next steps
- Payins concepts — the model behind this product.
- Templates — start here if Payins is your fit.
- Payin flows — end-to-end use cases.