Door two · Partners & developers

The engine room.

What sits behind the customer promise: a non-custodial orchestration layer across card acquirers, bank and Open Banking rails and supported digital-asset rails, with verification, routing, settlement and reconciliation handled in one place.

Status key:Live (staging)In buildPlannedOnly implemented or clearly planned capability is published. Statuses to be confirmed by MTRX before launch.
Integration options →Talk to us about partnering
Architecture

Orchestration, not processing.

MTRX Pay doesn't move money itself. It decides, for each payment, which connected partner should, then records the outcome as one event the merchant can reconcile.

Merchant surfaces
Merchant dashboard In buildOnboarding & KYB/KYC flow Live (staging)Payment links Live (staging)Hosted checkout In buildMerchant API In build
Orchestration core
Routing engine PlannedTransaction ledger In buildWallet per transaction Live (staging)Webhooks & events PlannedReconciliation Planned
Compliance
Identity & business verification (via Sumsub) Live (staging)Ongoing monitoring PlannedRisk scoring Planned
Partner rails
Card acquiring partners PlannedBank transfer / Open Banking PlannedStablecoin settlement rails PlannedOn/off-ramp partners Planned
Infrastructure
Akamai Connected Cloud Live (staging)Supabase (data & auth) Live (staging)PCI DSS v4.0.1 alignment Planned

Non-custodial means merchant funds sit with regulated partners, not with MTRX Pay. Named partners, supported markets and certifications will be listed only once contracted and verified.

Integrations

Three ways in, one account.

From a no-code payment link to a full API integration. Merchants can start simple and grow into the API without changing accounts.

Payment links

Live (staging)

Create a request for a fixed or open amount, share it by any channel, and let the customer pay by the methods enabled on the merchant profile. A dedicated wallet is created per transaction on verification acceptance, giving a clean audit trail per payment.

POST /v1/payment-links

Hosted checkout

In build

A branded, MTRX-hosted payment page the merchant redirects to or embeds. Handles method selection, currency presentation and the result page, so the merchant never touches card data.

GET /checkout/{session_id}

Merchant API

In build

REST API with API-key authentication for creating payment sessions, querying transactions and managing settlement preferences. Idempotency keys on all writes.

Authorization: Bearer mtrx_live_…

Webhooks

Planned

Signed event notifications for every lifecycle transition, with retries and a replay endpoint. Until then, transaction state is available by polling the API.

payment.settled · payment.failed · payout.sent

Example: create a payment link

Illustrative request and response shape. Field names are subject to change until the API reference is published.

# Request
POST /v1/payment-links
{
  "amount": 124000,
  "currency": "GBP",
  "reference": "INV-0412",
  "customer": { "email": "ops@orbittravel.example" },
  "idempotency_key": "c1f8…"
}

# Response
{
  "id": "pl_01HZX…",
  "url": "https://pay.mtrxpay.com/l/01HZX…",
  "status": "open",
  "wallet_id": "wal_01HZY…",
  "fee_preview": { "merchant_fee": "shown before payment" }
}
Transaction lifecycle

One payment, one record, six states.

Whichever route a payment takes, the merchant sees a single transaction moving through a fixed set of states. Routing decisions and partner references are attached to that record, not scattered across providers.

createdLink or session issued; wallet allocated
authorisedCustomer completed payment at partner
routedPartner and rail recorded against the record
settledFunds confirmed in merchant's MTRX balance
paid outWithdrawn to bank or wallet per schedule
failed / refundedTerminal states with reason codes

State names illustrative pending the published reference. Every transition carries a timestamp, actor and partner reference for reconciliation.

Compliance

Verification first, every time.

Nothing transacts before the business and the people behind it are verified. This is what lets us serve sectors others avoid.

KYB Live (staging)

Business verification through Sumsub: registration, ownership structure, directors and ultimate beneficial owners. Separate individual and business applicant paths.

KYC Live (staging)

Identity and liveness checks on owners and authorised users. Wallet creation is gated on verification acceptance.

AML & sanctions screening Planned

Sanctions, PEP and adverse-media screening at onboarding and on an ongoing basis, through the verification partner and connected rails.

Transaction monitoring Planned

Rule- and risk-based monitoring with case management, feeding routing decisions and merchant risk tiers.

Data & card security Planned

Infrastructure assessed against PCI DSS v4.0.1; card data handled by partners and hosted pages, never by merchant systems. Certification status will be published when attained.

Settlement & reconciliation

Funds you can trace, records you can close.

Per-transaction wallets

Each payment lands in its own wallet, so balances, fees and partner references can be reconciled at the transaction level, not just the batch.

Fee and net on every record

The merchant fee and net amount are computed and stored at settlement, so statements match the ledger line for line.

Multi-rail settlement Planned

Settlement across bank transfer and supported stablecoin rails, with the rail recorded against each record and withdrawal to the merchant's bank or wallet on a visible schedule.

Exports and reporting Planned

Ledger exports and reconciliation reports by period, partner and rail; API access to the same data.

# Ledger line (illustrative)
txn_id      txn_01J2K…
reference   INV-0412
gross       1240.00 GBP
merchant_fee -TBC
net         TBC
rail        partner_ref · rail_type
settled_at  2026-…T…Z
wallet_id   wal_01HZY…
Partnerships

Who we want to build with.

The platform is only as good as the rails and services connected to it. We're actively talking to the following kinds of partner.

Acquirers & PSPs

Card acquiring and alternative payment methods across the markets our merchants sell into. Geographic diversity is a design goal, not a fallback.

Banks & EMIs

Settlement accounts, Open Banking collection and payout rails for merchants that pass our due diligence.

Digital-asset partners

Regulated on/off-ramp and stablecoin settlement providers, on terms that reward quality of flow over raw volume.

Platforms & developers

Marketplaces, SaaS and vertical platforms that want to offer payments to the businesses the mainstream turns away.

Current partner names are not listed until agreements are signed and verified. If you'd like to be one of them, the conversation starts below.