What's Your Business Model?

Choosing the right payment scheme for your activity

The payment flow (or “scheme”) you implement depends on how your platform operates: who pays, who receives funds, and whether money is split, held, pooled, or repaid across multiple beneficiaries.

In the sandbox environment, we recommend testing the scheme that best matches your activity so your integration behaves like production. Your production environment is then configured based on the validated activity and the applicable scheme(s).

We have a comprehensive interactive matrix that we provide on our FAQs page. If you want to find out more, see the Schemes We Support page here.

How to choose a scheme (quick guide)

---

Marketplace (B2B, B2C, C2C)

A marketplace is an eCommerce model where multiple third-party sellers sell products or services through a single platform. The platform typically orchestrates the payment experience and then distributes funds to sellers.

Real-world examples (by model)

• Physical goods: Etsy, Back Market, ManoMano
• Services: Malt, Upwork, Fiverr
• Mobility & delivery (similar settlement patterns): Uber, Deliveroo

👍

In practice

• Who pays? Buyers/end-users
• Who receives first? Typically a platform technical account, then sellers
• Who is the final beneficiary? The seller (merchant), after distribution and payout
• Why a technical account is common: allocation, reconciliation, dispute handling, and controlled release

Typical flow

• Buyer pays in → funds are received on a technical/central account
• Funds are dispatched (P2P) → seller payment accounts (net of fees/commission rules)
• Sellers withdraw → seller bank accounts

---

Donors and Money Pots

A money collection (“money pot”) platform lets a person or group create a pot and collect contributions from multiple donors, then pay out to a beneficiary (or use funds for a defined purpose).

Real-world examples (by use case)

• Group gifts & events: shared birthday/wedding pots, school trips, club fees
• Personal causes: emergency support, community collections
• Charitable collections: fundraising campaigns (depending on your regulatory model)

👍

In practice

• Who pays? Donors
• Who receives? A pot/beneficiary structure (often with donor traceability)
• Why donor-level tracking is important: refunds, audit trail, contributor visibility, compliance expectations
• Common edge cases: partial refunds, chargebacks (card), cancellation of a pot, beneficiary change

Typical flow

• Donor pays in → donor payment account
• Contribution is moved (P2P) → pot payment account
• Pot is paid out → beneficiary bank account

---

Crowdlending / CrowdInvesting

Crowdlending (peer-to-peer lending) matches investors/lenders with borrowers (people or companies). Platforms usually support both the investment flow and, when applicable, the repayment flow.

Real-world examples (by model)

• SME lending: Funding Circle (model reference)
• Investor marketplaces/loan investing: Mintos (model reference)
• EU lending platforms: October (model reference)

📘

Note

Depending on your model, 3D Secure may be enabled by default in Enterprise production environments for card payments used in donation/reward crowdfunding-based activities.

👍

In practice (investment)

• Who pays? Investors/lenders
• Who receives? Borrower/project (after allocation/conditions are met)
• Why platforms may hold funds briefly: funding rounds, thresholds, verification milestones, scheduled release
• Common edge cases: funding failure, investor refunds, partial allocations, delayed release

Typical investment flow

• Investor pays in → investor payment account
• Investment is moved (P2P) → borrower/project payment account
• Borrower withdraws → borrower bank account

👍

In practice (repayment)

• How repayments are funded: bank transfer and/or SEPA Direct Debit are common
• How repayments are distributed: proportional allocation per investor, then optional withdrawals

Typical repayment flow

• Borrower credits → borrower/project payment account
• Repayment is distributed (P2P) → investor payment account(s)
• Investor withdraws → investor bank account

---

Crowdfactoring / Invoice Trading

Crowdfactoring (invoice trading) allows investors to fund invoices/receivables so a business can receive cash earlier. Later, when the debtor pays the invoice, repayments are allocated and distributed.

Real-world examples (by use case)

• SME cash-flow financing: businesses selling invoices to accelerate working capital
• Supply-chain finance patterns: structured invoice repayment allocation to investors

👍

In practice (funding)

• Who pays? Investors
• Who receives? Creditor (business that sold the invoice), net of fees
• Why a technical account is common: debtor repayments must be identified and allocated using an invoice reference/identifier
• Common edge cases: partial repayments, late payments, repayment reconciliation, invoice disputes

Typical funding flow

• Investor pays in → investor payment account
• Funds are moved (P2P) → creditor payment account
• Creditor withdraws → creditor bank account

👍

In practice (debtor repayment allocation)

• Debtors typically repay by bank transfer
• A structured reference/comment is used to link repayments to the correct invoice and investor(s)

Typical repayment allocation flow

• Debtor pays by bank transfer → factoring technical account (with the expected reference/comment, e.g. "ENVIRONMENTNAME-FACTORING COMMENT")
• Repayment is allocated (P2P) → relevant investor payment account(s)
• Investor withdraws → investor bank account

Association and Foundation