--- updatedAt: 2026-08-03T13:09:52.000Z --- Fetch the complete documentation index at: https://docs.mollie.com/llms.txt. Use this file to discover all available pages before exploring further. # Glossary A shared vocabulary for Mollie Connect. Each term has its own heading and a short, consistent definition, so any term can be linked to directly. Linked terms have their own entry. Terms here are used across the Connect guides. For the account model, money flows, and the API map, see [Core concepts](concepts.md). ## A to Z **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) · [Connect with Mollie](#connect-with-mollie) · [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. Every [profile](#profile), [balance](#balance), and [capability](#capability) belongs to an organization. In Connect, both your platform and each 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 its platform-level settings. ### Merchant A business that a platform onboards onto Mollie to accept payments. This is the default term for the onboarded business. Mollie verifies merchants through [KYB](#kyb-know-your-business). Reserve [customer](#customer) for the merchant's own buyer. ### Connected account A merchant [organization](#organization) that has connected to a [platform](#partner-platform) organization 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 repeat billing. Never call merchants "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 the [payment methods](#payment-method) and settings assigned to 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) and [payouts](#payout). (Pilot product.) ### 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, without the merchant sharing credentials. It sits beneath the idea of "authenticate and act on behalf of." ### Connect with Mollie The button and flow that start the [OAuth](#oauth) authorization, sending a merchant to grant a platform the requested [scopes](#scope-permission) before returning an authorization code. ### 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 for a quick start, but for production prefer [Client Link](#client-link), which pre-fills the merchant's details and supports co-branded onboarding. ### Client Link The recommended, API-driven way to onboard and connect merchants, via the [Client Links API](https://docs.mollie.com/reference/client-links-api). It creates a new [organization](#organization) for the merchant, pre-fills business data, and supports co-branded onboarding, without hand-building an [authorization URL](#authorization-url). ### Scope (permission) A granular grant such as `payments.write` or `balances.read` that defines what a platform may do on 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; `invalid_grant` on refresh signals the merchant disconnected. ### Advanced access token A longer-lived 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, API access tokens. ### Idempotency Sending a unique key with write requests so that retries do not create duplicates. It is essential for de-duplicating payments, [Client Link](#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. It is the journey, not the result. ### Onboarding model How the [KYB](#kyb-know-your-business) experience is delivered: **Direct** (on Mollie), **Hosted** (a Mollie-hosted link inside your flow), **Embedded** (a Mollie component in your UI), or **Reliance** (your licensed process shares verified data to Mollie). ### KYB (Know Your Business) The verification of a business's identity, ownership, and activity that Mollie performs before a merchant can receive payments or settlements. It is Mollie's current onboarding basis. ### KYC (Know Your Customer) Identity verification of an individual. It becomes 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. Mollie may still review the data and continues to run transaction monitoring. ### Capability What an [organization](#organization) is allowed to do, read through the [Capabilities API](https://docs.mollie.com/reference/list-capabilities) (currently beta). 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 through verification. In the current model this is expressed through each [capability](#capability)'s `status` and `requirements`, not a single value. The older Onboarding API returned one status of `needs-data`, `in-review`, or `completed`; it is deprecated, so prefer the Capabilities API. (See the note for product teams: a stable, human-facing onboarding status is still to be defined.) ## How money moves (the model) ### 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 type; the primitive describes the mechanism and the type describes the purpose. ### Credit and debit The two directions of a [balance mutation](#balance-mutation). A credit increases a balance, for example a [payment](#payment); a debit decreases it, for example a [payout](#payout) or a [fee](#fee). ### Movement primitives The three movements every money event reduces to. A [pay-in](#pay-in) is a credit from outside into Mollie, an internal transfer moves value 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, such as 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 and 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; the subscription or mandate is the parent construct that schedules it, and a subscription is not itself money moving. ### 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), for example 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 A [balance transfer](#balance-transfer) linked to a specific [payment](#payment) that distributes one shopper payment across multiple sellers, plus the platform's commission. It is the marketplace money-movement primitive. ### Delayed routing Providing [route](#route) instructions after a payment is paid, which allows funds to be held until conditions are met. This is the recommended approach. The alternative, upfront routing (legacy), fixes the split at checkout. ### Gross settlement A model used with delayed routing where the marketplace can route the full payment amount, while Mollie calculates and invoices transaction and routing fees separately, usually monthly. ## Money out (payouts) ### Payout Both the outbound family and its base case: 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". Note that Stripe's "payout" means to your own bank, which is Mollie's [settlement](#settlement). ### 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). Money leaves Mollie to the account owner's bank. ### 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). Money leaves Mollie to the owner's bank. (Pilot, Business Account.) ### Card spend A [payout](#payout) (debit) where a cardholder spends from a [Mollie Business Account](#mollie-business-account) balance using a virtual card. Reserve this for card spend; "card transaction" and "expense" are aliases, and it is distinct from inbound card [payments](#payment). (Pilot, Business Account.) ## Fees, monetization and billing ### Fee Money that Mollie or the platform deducts from a [balance](#balance) as the cost of a service, recorded as a [debit](#credit-and-debit). It is named by 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. It is an industry-standard term. ### 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), with country and merchant VAT settings and platform-branded, itemized invoices. ### 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, being the difference between the [buy rate](#buy-rate) and the resold or charged rate, reported for reconciliation. ### Monetization configuration The commercial model a platform uses: Revenue Share (Mollie prices and invoices), Managed Pricing (Mollie prices and the platform adds [application fees](#application-fee)), or Wholesale (the platform marks up [buy rates](#buy-rate)). ### Connect Billing Mollie automatically invoicing merchants for processing fees on the platform's behalf, with country and merchant VAT settings and platform-branded, itemized invoices. ### Segment A named group of merchants, for example by size, region, or agreement, used to apply distinct [resell margin](#resell-margin) rates in bulk. Segments are hidden from merchants and managed by the platform. ## Payment methods ### Payment method A way a [shopper](#shopper-consumer) can pay, such as iDEAL, cards, Bancontact, or PayPal. Methods are offered at the platform level and enabled per [profile](#profile), and some methods need extra activation. ### Hosted checkout Mollie's prebuilt, conversion-optimized payment page that a shopper is redirected to, returning to your `redirectUrl` once the [payment](#payment) reaches a final state. ### Payment link A shareable URL or QR code that opens a branded checkout, letting merchants get paid with no code across any channel. ## Reversals and adjustments ### Refund Returning funds for a [payment](#payment) 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, and 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 on the [Refunds API](https://docs.mollie.com/reference/refunds-api). ### 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 in 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 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.