Fees

A fee is what you charge your own subaccount for a payin: a fixed amount, a percentage, or both, deducted from the money credited when the payment arrives. It is your revenue on the collection, not a cost imposed on you. You set the numbers, Mono applies them on the ledger automatically and reports what was charged per payin in calculated_fees.

Set them once in your fee policies and they apply to every payin; override them per template or per intent when a campaign, a customer, or a single payment needs different numbers.

The fee type

Payins has one fee type, payin: it is charged for receiving the payment and applied when the payin is credited to the subaccount. Every calculated_fees you see contains only this type.

Where fees are configured

Your default fees are fee policies of type payin: pricing rules you manage through the API for every account of your users or customers, a program, an account holder or a single subaccount (a fixed amount and a percentage per currency and, when you need them, rules that price a method or a segment differently). If you use payins, Mono creates your base policy; from there you adjust and override it yourself. See Fee policies.

Overriding fees per template or intent

payin_data.fee_override lets a template, or an individual intent, replace your program default for its own payins:

{
  "payin_data": {
    "fee_override": [
      {
        "type": "payin",
        "fixed": { "amount": 50000, "currency": "COP" },
        "percentage": "0.01",
        "tx_description": "Collection fee: premium campaign"
      }
    ]
  }
}

Three rules govern overrides:

1. Every fixed amount must be denominated in the currency of the template's subaccount, and be >= 0.
2. The override replaces the default as a whole per fee type; there is no partial merge. An intent's override wins over its template's.
3. The values are frozen on each payin at creation: changing a template's override later does not alter the fees of payins already created.

Reading what was charged

Each payin reports what it charged in calculated_fees, keyed by fee type. That is the field to reconcile against: subaccount_amount is already net of it, so the end user sees the amount after your fee, and the difference is what you kept.

Next steps

• Fee policies: where the default fees are set, and for whom.
• Payins: where calculated_fees lives.
• Crediting the subaccount: the ledger movement fees ride on.