Payins
Collect money into your Core subaccounts — templates, intents, payins, and settlement.
Payins is how money gets into your Core subaccounts. It covers both top-ups (an end user loads their own wallet balance) and collections (your business charges a customer). You define the rules of what you expect to receive, Mono gives the payer something to pay to — today a Bre-B key or QR code — and every payment that arrives is validated, credited to the right subaccount, and delivered to your bank account, with a webhook at every step.
Mono has three products that receive money, for three different account models. Core Payins (this section) collects into Core subaccounts — use it when your product manages balances on the Core ledger. Collection links collect into Banking accounts through PSE payment links. Bre-B Participant collections receive Bre-B payments directly on tenant accounts. See Payins vs other Mono products for the full comparison.
The four entities
A payin never travels alone. Four entities, each with its own lifecycle and webhooks, take a payment from "expected" to "money in your bank account":
| Entity | What it is |
|---|---|
| Template | A reusable configuration tied to a subaccount: accepted methods, amount limits, allowed payers, expiration. |
| Intent | A single expected payment, declared before the funds arrive. Optional — use it when each payment must be pre-identified. |
| Payin | The received payment itself: who paid, how much, and where the money is in its journey. |
| Settlement batch | The single money movement that delivers the funds of many payins to your funding account. |
Two supporting concepts complete the picture: payment tokens (what the payer actually pays to) and fees (what you charge your subaccounts per payin). And inside every payin live three sub-entities of its own — the instrument, the recipient data, and the transaction data — explained in Payins.
The four amounts
Every payin carries four amounts, one per leg of the money's journey. Each leg has its own currency, so the model supports collecting in one currency and accounting in another:
| Field | What it measures | Denominated in |
|---|---|---|
amount | What the payer paid, as settled by the payment method. | The method's currency |
merchant_amount | The merchant-facing value of the payment. | The template's currency |
subaccount_amount | What is credited to the subaccount. | The subaccount's currency |
funding_amount | What is delivered to your funding account. | The funding account's currency |
Where multi-currency is headed. Today the only live method is
Bre-B, which settles in COP, so the four
amounts normally coincide. The goal of the four-legged model is full multi-currency
collection: receive a payment in the method's currency while pricing it, crediting the
subaccount, and settling your funding account each in their own currency, with Mono handling
the conversions between legs — at a rate reserved in advance or at Mono's live rate — and the
conversion spreads surfacing as the payin_payer_spread and payin_subaccount_spread
fees, already declared in the contract. When
multi-currency collection arrives, it lands on these same four fields without breaking
changes.
Payment methods
Each payin is received through a payment method. Today one method is available:
| Method | Rail | Currency | Payer pays with |
|---|---|---|---|
co_breb | Bre-B, Colombia's instant-payment scheme | COP | A Bre-B key or QR code |
The structure grows by method: when a new method launches, it appears in Methods with its own page, and templates accept it in available_methods without any change to the entities above.
Explore
Payins vs other Mono products
How this compares with Banking collection links and Bre-B Participant collections.
Templates
The reusable configuration that defines how payments are collected.
Intents
A single expected payment, declared before the funds arrive.
Payins
The received payment: states, amounts, sub-entities, and rejection reasons.
Payment tokens
What the payer pays to — each method issues its own kind; today, Bre-B keys and QR codes.
Settlement
Two movements: when the subaccount is credited, and how Mono delivers the funds to you.
Fees
The three payin fee types and how to override them per template.
Methods
The payment methods you can collect with, side by side.
Flows
End-to-end use cases: top-ups, static-key collection, per-payment intents, settlement.
Webhooks
The 22 events across the payin lifecycle and when each one arrives.
Next steps
- Templates — start here: everything begins with a template.
- Flows — pick the flow that matches your business case.
- Payins API reference — every endpoint, request, and response.