---
updatedAt: 2026-09-15T00:52:28.000Z
agentTools:
  projectIndex: https://docs.mollie.com/llms.txt
---

# Glossary

**A** [Abandon rate](#abandon-rate) · [Access token](#access-token) · [Actionable payments](#actionable-payments) · [Adjustment](#adjustment) · [Advanced access token](#advanced-access-token) · [Application fee](#application-fee) · [Attribution](#attribution) · [Authorization URL](#authorization-url) · [ATV](#atv-average-transaction-value)

**B** [Balance](#balance) · [Balance mutation](#balance-mutation) · [Balance transfer](#balance-transfer) · [Billing charge](#billing-charge) · [Buy rate](#buy-rate)

**C** [Cancel rate](#cancel-rate) · [Capability](#capability) · [Card spend](#card-spend) · [Chargeback](#chargeback) · [Client Link](#client-link) · [Commission](#commission) · [Connect Billing](#connect-billing) · [Connected account](#connected-account) · [Credit and debit](#credit-and-debit) · [Customer](#customer)

**D** [Delayed routing](#delayed-routing)

**E** [Event](#event) · [Expiry rate](#expiry-rate)

**F** [Fail rate](#fail-rate) · [Fee](#fee)

**G** [Gross revenue](#gross-revenue-partner) · [Gross settlement](#gross-settlement)

**H** [Holding balance](#holding-balance) · [Hosted checkout](#hosted-checkout)

**I** [Idempotency](#idempotency) · [In the money flow](#in-the-money-flow)

**K** [KYB](#kyb-know-your-business) · [KYC](#kyc-know-your-customer)

**M** [Margin](#margin) · [Marketplace](#marketplace) · [Merchant](#merchant) · [Mollie Business Account](#mollie-business-account) · [Monetization configuration](#monetization-configuration) · [Movement primitives](#movement-primitives)

**N** [Net revenue](#net-revenue-partner)

**O** [OAuth](#oauth) · [Onboarding](#onboarding) · [Onboarding model](#onboarding-model) · [Onboarding status](#onboarding-status) · [Organization](#organization)

**P** [Paid volume](#paid-volume) · [Partner (analytics)](#partner-analytics) · [Partner (Platform)](#partner-platform) · [Pay-in](#pay-in) · [Payment](#payment) · [Payment link](#payment-link) · [Payment method](#payment-method) · [Payment success rate](#payment-success-rate) · [Payout](#payout) · [Portfolio](#portfolio) · [Primary currency](#primary-currency) · [Processing fee](#processing-fee) · [Profile](#profile) · [PSD2](#psd2)

**R** [Rail](#rail-instrument) · [Recurring payment](#recurring-payment) · [Refresh token](#refresh-token) · [Refund](#refund) · [Refund rate](#refund-rate) · [Reliance onboarding](#reliance-onboarding) · [Resell margin](#resell-margin) · [Reversal](#reversal) · [Reverse routing](#reverse-routing) · [Route](#route)

**S** [SCA](#sca-strong-customer-authentication) · [Scope](#scope-permission) · [Segment](#segment) · [Service fee](#service-fee) · [Settlement](#settlement) · [Settlement reference](#settlement-reference) · [Shopper](#shopper-consumer) · [Sub-merchant](#sub-merchant)

**T** [Top-up](#top-up)

**U** [Unmatched credit transfer](#unmatched-credit-transfer)

**V** [Virtual IBAN](#virtual-iban-viban) · [Volume fees](#volume-fees)

**W** [Webhook](#webhook) · [Withdrawal](#withdrawal)

***

## Entities and accounts

### Organization

The top-level Mollie account that represents a single legal business entity. Every [profile](#profile), [balance](#balance), and [capability](#capability) belongs to an organization. In Connect, both your platform and each connected merchant are organizations.

### Partner (Platform)

The business that builds on Connect to onboard and serve merchants. The platform's own organization holds its OAuth app, its fee and route revenue and platform-level settings.

### Merchant

A business that a platform onboards onto Mollie to accept payments. This is the default term for the onboarded business which Mollie verifies through [KYB](#kyb-know-your-business).

### Connected account

A merchant [organization](#organization) that is connected to a [platform](#partner-platform) through [OAuth](#oauth) or [Client Link](#client-link), allowing the platform to act on its behalf (within the granted [scopes)](#scope-permission).

### Customer

A merchant's own buyer, managed through the [Customers API](https://docs.mollie.com/reference/customers-api) (`cst_`) for repeated billing. Different from "customers" - that word is reserved for the merchant's buyers.

### Shopper (consumer)

The end payer who completes a [payment](#payment) at checkout. This is distinct from a [customer](#customer), which is the merchant's stored buyer record.

### Profile

A merchant's configuration container, holding a trading name, branding, website and a set of [payment methods](#payment-method) (along with settings associated with it). A merchant can hold several profiles for different storefronts or markets.

### Mollie Business Account

An EMI-based bank-account equivalent for a merchant, used to store balances, issue cards and make [withdrawals](#withdrawal) or [payouts](#payout). (Beta)

### Marketplace

A Connect configuration where the platform is the payment owner and distributes a single [payment](#payment) across multiple sellers using [routes](#route), keeping a commission and the chargeback liability.

## Authentication and connection

### OAuth

The open authorization standard that lets a platform act on a merchant's behalf (using [tokens](https://docs.mollie.com/reference/oauth-generate-tokens)), without the merchant having to share their credentials. Translates into "authenticate and act on behalf of."

### Authorization URL

The OAuth URL (`client_id`, `redirect_uri`, `response_type`, `scope`, `state`) that sends a merchant to the Mollie consent screen. You can construct it by hand or use a [Client Link](#client-link), which pre-fills the merchant's details and supports co-branded onboarding (*recommended*).

### Client Link

API-driven way to onboard and connect merchants using the [Client Links API](https://docs.mollie.com/reference/client-links-api). It creates a new [organization](#organization) for the merchant, pre-fills their business data and supports co-branded onboarding, without hand-building an [authorization URL](#authorization-url).

### Scope (permission)

A granular grant (e.g., `payments.write`, `balances.read` etc) that defines what a platform may do on behalf of a [connected account](#connected-account). Adding scopes later requires the merchant to reconnect.

### Access token

A short-lived credential (60 minutes) used to call the API on a connected account's behalf, obtained by exchanging an authorization code or a [refresh token](#refresh-token).

### Refresh token

A persistent credential used to mint new [access tokens](#access-token). Store it encrypted; <br />`invalid_grant` on refresh signals the merchant disconnected.

### Advanced access token

An advanced token with configurable permissions that can access organization-level resources and optionally a specific [profile](#profile). Used for server-to-server actions such as [balance transfers](#balance-transfer) and MCP access. Created under **Developers&#x20;**&#x74;ab > **API keys**.

### Idempotency

Sending a unique key with `write` requests so that retries do not create duplicates. It is essential for de-duplicating payments, [Client Links](#client-link) and merchant or profile creation.

## Onboarding and verification

### Onboarding

The end-to-end process of getting a merchant verified and able to transact, covering business and identity data, document checks and Mollie's review.

### Onboarding model

How the [KYB](#kyb-know-your-business) experience is delivered: **Direct** (in Mollie), **Hosted** (a Mollie-hosted link inside your flow), **Embedded** (a Mollie component in your UI) or **Reliance** (your licensed process shares verified data with Mollie).

### KYB (Know Your Business)

The verification of a business's identity, ownership and activity that Mollie performs before a merchant can process payments or initiate settlements.&#x20;

### KYC (Know Your Customer)

Identity verification of an individual. Relevant if Mollie extends onboarding beyond businesses.

### Reliance onboarding

A model where a licensed partner performs [KYB](#kyb-know-your-business) or [KYC](#kyc-know-your-customer) and passes verified data to Mollie through the API.

### Capability

What actions an [organization](#organization) is allowed to do, read through the [Capabilities API](https://docs.mollie.com/reference/list-capabilities) (beta). <br />Connect exposes the `payments` and `settlements` capabilities. Each has a `status` of `unrequested`, `enabled`, `disabled`, or `pending` and a `requirements` list (for example `needs-data` or `process-first-payment`) describing what must be done to enable it. The `payments` capability is enabled if at least one of the organization's [profiles](#profile) can accept payments.

### Onboarding status

How far a merchant is in the verification process. Expressed through each [capability](#capability)'s `status` and `requirements`, not a single value.

## Funds movement

### Balance mutation

Any single change to a [balance](#balance), recorded as a [credit](#credit-and-debit) or a [debit](#credit-and-debit). Every money event is one mutation with a specific type; the `primitive` describes the mechanism and the `type` describes the purpose.

### Credit and debit

The two directions of a [balance mutation](#balance-mutation). Credit increases a balance (e.g., [payments)](#payment); debit decreases it (e.g., [payouts,](#payout) [fees)](#fee).

### Movement primitives

A [*pay-in*](#pay-in) is a credit from outside coming into Mollie, an *internal transfer* moves funds between two Mollie balances (see [balance transfer](#balance-transfer) and [route](#route)) and a [*payout*](#payout) is a debit from Mollie to outside.

### Rail (instrument)

How a [pay-in](#pay-in) or [payout](#payout) is executed: card, direct debit, bank transfer (SEPA credit transfer), wallet, internal ledger or card scheme. The rail is a separate axis from the movement, which is why a "bank transfer" is a rail and not a [balance transfer](#balance-transfer).

## Money in (pay-ins)

### Pay-in

Money moving into the Mollie ecosystem, recorded as a [credit](#credit-and-debit). It is the umbrella primitive for collections and its named types include [payment](#payment), [recurring payment](#recurring-payment) and [top-up](#top-up).

### Payment

A single [pay-in](#pay-in) where a [shopper](#shopper-consumer) pays a merchant online or in person, via the [Payments API](https://docs.mollie.com/reference/payments-api). It is the most common inbound event that can carry an optional [application fee](#application-fee) or [route](#route) instructions.

### Recurring payment

A [pay-in](#pay-in) collected automatically on a schedule against a stored mandate. This is the movement of funds, while subscription or mandate is the parent construct that schedules it.

### Top-up

A [pay-in](#pay-in) where an account holder adds their own funds to their Mollie [balance](#balance) or [Mollie Business Account](#mollie-business-account), for example to pre-fund [payouts](#payout). "Top-up" is the canonical term and "deposit" is an alias.

## Money held and internal movement (transfers)

### Balance

The funds an [organization](#organization) holds at Mollie, including pending and available amounts. It can be read in a bank-feed format through the [Balances API](https://docs.mollie.com/reference/balances-api) for reconciliation.

### Holding balance

In marketplaces, the compliant balance where a [payment](#payment) sits before being distributed through [routes](#route), which enables collect-then-route (delayed) flows.

### Balance transfer

Moving funds between two Mollie [organizations](#organization) (e.g., platform and merchant), where both parties already own those balances. It stays inside Mollie and is used for fees, royalties and corrections, with documented consent. Requires an [advanced access token](#advanced-access-token).

### Route

(Marketplaces) A [balance transfer](#balance-transfer) linked to a specific [payment](#payment) that distributes one shopper payment across multiple sellers, plus the platform's commission.

### Delayed routing

Providing [route](#route) instructions *after* a payment is paid, allowing funds to be held until certain conditions are met. Recommended approach (Alternatively, *upfront routing* (legacy), fixes the split at checkout).

### Gross settlement

A model used along with delayed routing where marketplaces can route the full payment amount, while Mollie calculates and invoices transaction and routing fees separately (usually monthly).

## Money out (payouts)

### Payout

Sending funds to a third party's bank, mirroring [payment](#payment) on the inbound side. The own-bank variants get their own names, [settlement](#settlement) and [withdrawal](#withdrawal). Its alias is "disbursement".

### Settlement

The scheduled, automatic [payout](#payout) of an [organization](#organization)'s [balance](#balance) to its own external bank account, reported through the [Settlements API](https://docs.mollie.com/reference/settlements-api).

### Withdrawal

An on-demand movement of an account's own funds to its own bank account, typically from a [Mollie Business Account](#mollie-business-account).&#x20;

### Card spend

A [payout](#payout) (debit) where a cardholder spends funds stored on a [Mollie Business Account](#mollie-business-account) balance using a virtual card.&#x20;

## Fees, monetization and billing

### Fee

Money that Mollie or a platform deducts from a [balance](#balance) as the cost of a service, recorded as a [debit](#credit-and-debit). It has a distinct type, such as [processing fee](#processing-fee), [application fee](#application-fee), [service fee](#service-fee), or [resell margin](#resell-margin).

### Processing fee

Mollie's own per-transaction [fee](#fee), deducted from a [balance](#balance) or invoiced. It is the basis of the platform's [margin](#margin) under resell or wholesale pricing.

### Application fee

A platform-set [fee](#fee) added to a [payment](#payment) and moved to the platform's [balance](#balance) when the payment succeeds. The connected account remains liable for refunds and fees.&#x20;

### Resell margin

The difference between Mollie's [buy rate](#buy-rate) and the rate a platform charges its merchants, earned by the platform on each payment and reported in the transaction margin report.

### Service fee

A Mollie [fee](#fee) for a specific service event, such as a refund fee or a chargeback fee, deducted from the relevant [balance](#balance).

### Billing charge

A monthly [fee](#fee) invoice raised to a merchant, usually through [Connect Billing.](#connect-billing) Includes country-sepcific merchant VAT settings and branding.

### Buy rate

The wholesale price Mollie charges a platform for a [payment method](#payment-method). The platform's [margin](#margin) is the difference between the buy rate and the price it charges merchants. The same buy rate is the cost subtracted when computing partner [net revenue](#net-revenue-partner).

### Margin

The platform's revenue on a payment, calculated as the difference between the [buy rate](#buy-rate) and the charged rate, reported for reconciliation.

### Monetization configuration

The commercial model a platform uses: *Revenue Share* (Mollie sets the price and invoices after), *Managed Pricing* (Mollie sets the price and a platform adds [application fees](#application-fee)) or *Wholesale* (platform marks up [buy rates](#buy-rate)).

### Connect Billing

When Mollie automatically invoicing merchants for processing fees on the platform's behalf using itemized invoices.

### Segment

A distinct group of merchants, for example grouped by size, region or agreement, used to apply distinct [resell margin](#resell-margin) rates in bulk. Segments are hidden from merchants and are managed by platform.

## Payment methods

### Payment method

The way a [shopper](#shopper-consumer) can pay, such as using iDEAL, cards, Bancontact, PayPal etc. Methods are offered at the platform level and are enabled per [profile.](#profile)

### Hosted checkout

Mollie's prebuilt, conversion-optimized payment page that a shopper is redirected to, returning to your `redirectUrl` once the [payment](#payment) reaches its final state.

### Payment link

A shareable URL or QR code that opens a branded checkout, allowing merchants to get paid without adding any code, across any channel.

## Reversals and adjustments

### Refund

Returning funds to the [shopper](#shopper-consumer), fully or partially, via the [Refunds API](https://docs.mollie.com/reference/refunds-api). In marketplaces this can trigger [reverse routing](#reverse-routing) to reclaim amounts already distributed to sellers.

### Chargeback

A forced reversal initiated by a shopper's bank. Liability sits with the connected account in the platform model, or with the marketplace in the marketplace model. Handling differs by configuration.

### Reverse routing

Reclaiming routed funds from seller balances when a routed payment is refunded, using `reverseRouting` for a full refund or `routingReversals` for a partial one (via <Anchor target="_blank" href="https://docs.mollie.com/reference/refunds-api">Refunds API)</Anchor>.

### Reversal

Undoing a [balance transfer](#balance-transfer) or [route](#route) so that funds return to the originating [balance](#balance). It is the internal counterpart to a [refund](#refund), which returns funds outbound to a shopper.

### Adjustment

A manual [credit](#credit-and-debit) or [debit](#credit-and-debit) correction applied to a [balance](#balance) by Mollie or a platform, used for fixes, penalties or reconciliation discrepancies.

## Risk and compliance

### SCA (Strong Customer Authentication)

A PSD2 requirement for multi-factor verification of certain payments, often through 3-D Secure. Platforms need to understand where SCA responsibility sits within their flows.

### PSD2

The EU payments regulation governing authentication and who may handle funds. It determines whether a platform is "[in the money flow](#in-the-money-flow)" and what kind of licensing it needs.

### In the money flow

A compliance state where a platform receives or controls third-party funds, which generally requires its own licensing. Connect is designed (through [OAuth](#oauth), [routes](#route), and [balance transfers](#balance-transfer)) to keep platforms out of it.

## Partner reporting and analytics

The Insights Metrics page holds the canonical formulas and field names for these metrics. We mirror them here for shared understanding and link out for the source of truth, rather than redefining them.

### Partner (analytics)

A merchant carrying a partner flag. How the partner is integrated (signup link, user-agent, or [OAuth](#oauth)) determines which payments belong to their [portfolio](#portfolio).

### Sub-merchant

A merchant whose payments are attributed to a partner. It is the same entity as a [connected account](#connected-account), seen from the partner's reporting view.

### Portfolio

The full set of [sub-merchants](#sub-merchant) attributed to a partner, and the default level at which partner analytics aggregate.

### Attribution

How a payment is linked to a partner, using three signals: signup link, user-agent, and OAuth. A payment can match up to three partner IDs, and matches are de-duplicated.

### Primary currency

The partner's reporting currency. All amount fields are converted to it at the daily exchange rate before partner-level metrics are shown.

### Paid volume

The sum of successfully paid payment amounts across a partner's [sub-merchants](#sub-merchant), in the original currency. It is sub-merchant revenue and a volume signal, not partner revenue.

### Actionable payments

Payments that reached a terminal paid or failed state. They are the denominator for [payment success rate](#payment-success-rate).

### Gross revenue (partner)

A partner's earnings before Mollie's costs, made up of [application fees](#application-fee) plus [commissions](#commission). It is often shown as a split between those two components.

### Net revenue (partner)

Gross revenue after Mollie's costs, calculated as [gross revenue](#gross-revenue-partner) minus [buy rate](#buy-rate) and [volume fees](#volume-fees). This is the figure that maps to partner payouts.

### Commission

Partner revenue earned per transaction, typically a kickback under a revenue-share or commission-type partnership. It is a component of partner [gross revenue](#gross-revenue-partner).

### Volume fees

Additional volume-based fees Mollie charges the partner per transaction. They are deducted when calculating [net revenue](#net-revenue-partner).

### ATV (average transaction value)

[Paid volume](#paid-volume) divided by payments paid, showing the typical payment size across the portfolio.

### Payment success rate

Payments paid divided by [actionable payments](#actionable-payments), showing the share of real attempts that completed.

### Fail rate

Payments failed divided by payments created, a signal for integration or payment-method issues.

### Cancel rate

Payments canceled by shoppers divided by payments created, indicating checkout friction.

### Expiry rate

Payments that expired divided by payments created, indicating shoppers who started but never completed.

### Abandon rate

Canceled plus expired payments divided by payments created, the broadest measure of checkout drop-off.

### Refund rate

Refunds divided by payments paid, a signal for returns or disputes across the portfolio.

## Reconciliation and events

### Virtual IBAN (vIBAN)

A dedicated IBAN assigned to a merchant's [profile](#profile) for receiving bank transfers into their Mollie [balance](#balance), which improves matching and is compliant with Verification of Payee.

### Unmatched credit transfer

A bank transfer that Mollie could not automatically match to an open payment. Through the API or a webhook you can match it to one or more payments, or return it to the sender.

### Settlement reference

The identifier that links transactions to a specific [settlement](#settlement), used as a join key when reconciling Mollie data against bank statements and ERP entries.

### Event

A notification of a change such as a payment, route, transfer, or onboarding update, delivered to your endpoint through Mollie's [webhooks](#webhook). Newer events use the next-generation webhooks framework and carry an `event_` id.

### Webhook

The HTTPS endpoint that receives [events](#event). Configure it per payment or globally, and use it instead of polling to track status changes and reconciliation triggers.