Skip to content
In the marketplace today

PSP providers

A regulated payment institution, connected to your workspace.

For fund flows that need more than a card checkout: segregated client-money wallets, mandates, payouts and disputes — each tenant on its own licensed provider account.

Image slot — asset to come

Screenshot: a PSP provider settings page, keys masked.

4
Provider modules
0
Shared or house accounts
Never
Raw card data stored

Your licence, your keys

Each provider is its own installable module. The tenant holds the provider contract and enters its own API keys — the platform supplies the software only.

  • Sandbox and production environments with separate keys
  • Keys encrypted at rest and write-only — never shown back, never logged
  • A test-connection button that proves saved credentials work
  • Webhook secrets stored per key, with rotation support
  • A master switch plus per-capability toggles

Image slot — asset to come

Screenshot: provider settings with environment toggle, keys masked.

Regulated money flows

These institutions are licensed for platform money: per-user wallets with segregated funds, escrow-style flows and compliant payouts — what fundraising legally needs and a plain card processor cannot provide.

  • Per-user wallets with segregated client money
  • Pay-ins by iDEAL, SEPA, cards and more, per provider
  • SEPA direct-debit mandates
  • Withdrawals and settlements to verified bank accounts
  • Provider-side compliance onboarding of wallet holders

Image slot — asset to come

Screenshot: a transactions list with statuses, amounts anonymised.

A full back office in the panel

Operators manage every provider object from the admin panel — never a database client or an API tool.

  • Paged list and detail screens for every provider resource
  • A browsable log of every outbound API call
  • An inbound webhook log with signature verification
  • IBANs masked everywhere; separate view and manage permissions per resource group

Image slot — asset to come

Screenshot: the operator back office on a merchant detail, anonymised.

A wallet page for end users

The same integration powers a self-service wallet for the tenant's end users — every wallet they hold, across providers, on one page.

  • Balance and history — own wallet only, enforced on the server
  • Deposit, withdraw and connect a bank account
  • Verification status with a deep link to finish it
  • Multiple providers side by side on one page

Image slot — asset to come

Screenshot: the wallet page with balance and actions, anonymised.

Other modules plug in, never around

A PSP module is the only code that talks to its provider; everything else goes through its published contract and events.

  • Stable events for every state change — payments, mandates, payouts, disputes
  • Request events so a consumer module can ask for a pay-in or payout
  • Installing one provider never couples you to another

Worth knowing: OPP is the fully built provider module today; Mangopay, Lemonway and Adyen follow on the same contract. There is never a shared or house account — no configured provider means the flow stops with a clear message.

What every module inherits.

  • Installs from the marketplace with no redeploy — the menu and the permission list update immediately.
  • Creates its own tables, in its own schema, inside that customer's database.
  • Packages are cryptographically signed when they are built, and the signature is checked before the host unpacks one.
  • Uninstall switches a module off and keeps its data. Dropping the tables is a separate, deliberate choice.

Want to see PSP providers running?

Thirty minutes, a live workspace, and an honest answer about what each module does and doesn't do yet. Missing a module? A custom build is a fixed-scope project, from €25.000.

Book a call