Bring your own MIDs

One API across your acquirers and Africa's local rails.

M-Pesa, Paystack, card — one integration with automatic failover and a reconciled ledger. No custody: your money flows through your MIDs, not ours.

Create a sandbox account Talk to the founder
No custody — your MIDs Hosted provider checkout 3DS via your providers Failover + reconciled ledger
Start accepting payments Talk to sales

One API across the providers you already run

Paystack Paydock Paystack Paydock

The problem

Three rails. Three dashboards. Zero failover.

African platforms and vertical SaaS typically run Paystack for local payments, a card acquirer for card volume, and M-Pesa on the side. Each rail has its own API, its own dashboard, and its own failure modes — and nothing catches a transaction when one of them goes down.

No single API

Every rail is its own integration

Each provider has its own SDK, callback format, and quirks — and your team maintains all of them.

No failover

One outage stops checkout

When a provider is down, payments on that rail simply fail. Recovering means a manual switch and a redeploy.

No one ledger

Reconciliation by spreadsheet

Totals live in separate dashboards. Getting one view of what actually cleared is a manual, error-prone job.

The fix

One integration. Your rails. One reconciled view.

EuPPay sits between your checkout and the provider accounts you already own. Initialize a payment through one API, send the customer to the provider's hosted page, and get every result back into one ledger — with a backup provider ready when one fails.

One REST API, every provider

Initialize, status, refund — the same JSON shape across CyberSource, MPGS, Paystack, Paydock, and Paychtec adapters. No re-platforming when you add a rail.

Hosted provider checkout

Card data is captured on your payment provider's hosted page, not our servers. The customer is redirected, pays, and returns — which reduces your PCI burden.

Automatic failover

When a provider fails for technical reasons, the platform retries on a backup provider you've connected — no manual switch, no redeploy. Failover covers outages, not declines.

Reconciled transaction ledger

Every attempt, capture, and refund across all your rails in one ledger, with per-rail totals — instead of one dashboard per provider.

3DS via your providers

Issuer authentication runs on the provider's hosted flow where the issuer requires it — no 3DS plumbing in your own checkout.

Processing limits & velocity controls

Per-merchant limits and velocity rules enforced before a transaction ever reaches a provider.

How onboarding works

Sandbox is fast. Card go-live is a scheduled project.

  1. 01

    Connect & test

    Create an account, get sandbox access, and integrate the initialize → redirect → status flow against test providers.

  2. 02

    Bring your MIDs

    We connect your existing provider accounts — card acquirer, Paystack, M-Pesa. Card rails are gated: your acquirer approves the gateway connection, a concierge process measured in weeks, and we run it with you.

  3. 03

    Go live on your rails

    Enable a provider from the dashboard when it's approved. Your money keeps flowing through your MIDs — never through ours.

curl • initialize-payment.sh 
# 1. Initialize a payment — same call across every provider
curl -X POST https://euppay.com/api/v1/payments/initialize \
  -H "X-Api-Key: $API_KEY" \
  -H "X-Api-Secret: $API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "order_id": "ORD-42f7",
    "amount": 49.99,
    "currency": "KES",
    "customer_email": "ada@startup.io",
    "billing_address": "123 Biashara St, Nairobi, KE",
    "return_url": "https://your-site.com/payment/success",
    "cancel_url": "https://your-site.com/payment/cancel"
  }'

# 2. Redirect the customer to the provider's hosted checkout
{ "success": true, "action": "redirect", "redirect_url": "https://…", "transaction_reference": "550e8400-…" }

# 3. Confirm server-side before you fulfil
GET https://euppay.com/api/v1/payments/{reference}/status
{ "success": true, "data": { "order_id": "ORD-42f7", "status": "completed" } }

Side by side

What changes when your rails share one API.

Per-rail integrations
EuPPay
Integration surface
One SDK per rail, maintained forever
One API across every connected rail
Failover when a provider goes down
Manual switch + redeploy
Automatic retry on a backup provider
View across rails
One dashboard per provider
One ledger with per-rail totals
Adding a rail
A new integration project
Connect the account, keep the same API
Card data handling
Your problem per provider
Captured on the provider's hosted page

Pick your lane

Flat prepaid plans. Your volume is never billed.

Design Partner

$1,500/mo prepaid

A capped early cohort. Setup fee waived in exchange for a case study.

  • Up to $250,000 monthly volume defines the tier
  • 2 connected rails on your own MIDs
  • Pay in USD by card, or KES via M-Pesa
  • Founder-led, best-effort support
Apply for a design-partner slot

Core & Scale / White-label

From $5,000/mo prepaid

For platforms running multiple rails in production, up to white-label.

  • Core: $5,000/mo + $5,000 one-time onboarding
  • Scale / White-label: from $9,000/mo + $15,000 onboarding
  • Same-business-day support on Core
  • Non-payment degrades the dashboard only — routing is never switched off
Book a 30-min founder call

Compare full pricing on the pricing page or read the API documentation.

FAQ

The questions every CTO asks before switching.

Yes — that is the model. You bring your own MIDs and provider accounts (card acquirer, Paystack, M-Pesa); we give you one API, failover, and a reconciled ledger across them. EuPPay never touches your funds — settlement stays between your providers and your bank accounts.
Card data is captured on your payment provider's hosted page, not our servers. Your customer is redirected to the provider's checkout, completes payment — including 3DS where the issuer requires it — and returns to your site. That keeps raw card data off both your systems and ours and reduces your PCI burden.
Sandbox access is quick — you can integrate and test the API early. Going live on card rails is a gated, concierge project measured in weeks, because your acquirer has to approve the gateway connection on your MID. We run that process with you rather than pretending it happens in days.
When a provider fails for technical reasons, the platform can automatically fail over to a backup provider you have connected. Failover covers technical failures, not declines — and we don't publish lift numbers we can't back with real traffic.
Flat prepaid subscriptions collected via Pesapal — USD by card, or KES via M-Pesa for Kenyan subscribers. Capacity bands define your tier and are never billed; crossing a band prompts an upgrade, never a back-bill. Non-payment degrades the dashboard only — live payment routing is never switched off over a billing state.
Refunds, status checks, and callbacks use the same JSON shapes regardless of the underlying provider, and every transaction lands in one ledger with per-rail totals.

One API. Your MIDs. No custody.

Create an account to explore the sandbox, or talk to the founder about a design-partner slot. You'll get a straight answer on whether the platform fits your stack.

Create a sandbox account Talk to the founder
Start free Talk to sales