Provider sprawl in the merchant portal
Each new PSP means another onboarding form, API, status model, and support queue — operators cannot see one merchant journey.
01 · OrchestratorOne portal,
One portal,
every provider.
Route invoices and pay-links across FawryPay, Paymob, PayTabs, Kashier, and MPGS-backed card rails from one merchant portal — policy decides the channel, not a one-off integration.
Built forPSPs, marketplaces, and merchant platforms that already contract multiple regional providers and need one operator console
Channels named
FawryPay · Paymob · PayTabs · Kashier · MPGS
Control plane
One merchant portal across contracted channels
Control model
Policy routing + maker-checker on sensitive changes
What buyers are solving
Framed for PSPs, marketplaces, and merchant platforms that already contract multiple regional providers and need one operator console — not generic payment pain.
Routing buried in application code
Failover and channel preference live in services that product and risk cannot change without a release.
Global orchestrators miss MENA rails
Primer / Spreedly-class tools excel at card PSPs; regional acceptors still need a first-class home.
How it works
- Onboard merchant
Capture KYC, contracts, and channel entitlements once.
- Configure channels
Enable PSPs and card rails the merchant is contracted for.
- Issue bill or link
Create invoices, pay-links, or hosted checkout sessions.
- Route by policy
Send each payment to the allowed channel with failover rules.
- Reconcile & report
Unified statuses and exports across channels.
merchant_portal · invoice #INV-91823
Routed by policy
AMOUNT REQUESTED
EGP 2,480.00
Enabled channels
FawryPay
Cash + e-wallet
Paymob
Online cards
PayTabs
MENA cards
Kashier
MENA cards
Card via bank
MPGS · scheme
Core capabilities
Each capability names a concrete mechanism — not a marketing adjective.
Merchant portal
Operators manage merchant profiles, channel entitlements, invoices, and pay-links in one console.
Multi-PSP channel registry
Contracted connectors for FawryPay, Paymob, PayTabs, Kashier, and MPGS-backed card acceptance, enabled per merchant rather than hard-wired in code.
Policy routing
Rules evaluate merchant, amount, currency, and channel health to choose the acceptor; failover lists are versioned configuration.
Invoice and pay-link issuance
Create billable instruments with channel constraints; customers pay on the allowed rail without a separate integration per PSP.
Structured KYC handoff
Commercial, legal, and know-your-merchant artifacts captured once and reused when enabling additional channels.
Unified payment status
Normalize provider callbacks into a shared lifecycle so ops and finance do not reconcile five status dictionaries.
Assisted routing suggestions
Optional AI-assisted suggestions flag underperforming channel combinations for human approval — never auto-promotes production policy without maker-checker.
Audit on configuration
Routing, fee, and entitlement changes write immutable audit entries with actor and reason codes.
Where this sits vs alternatives
You avoid owning N PSP SDKs, status normalizers, and merchant portal UX — Flagship maintains the connector surface while you keep commercial contracts.
Single-provider portals lock you to one acceptor. Orchestrator treats regional PSPs as swappable channels under one policy model.
Designed around MENA acceptors first, then card rails via MPGS — not a card-centric mesh with regional PSPs bolted on.
Architecture and deployment
Merchant and operator surfaces sit above an orchestration service that talks to channel adapters; durable records stay in ledger and export paths.
PeopleMerchant portal, pay-pages, operator consoles
OrchestrationInvoices, pay-links, policy routing, channel entitlements
Channel adaptersFawryPay · Paymob · PayTabs · Kashier · MPGS profiles
RecordsStatuses, fees, reconciliation exports
Deployment options
SaaS multi-tenant
Shared control plane with tenant isolation for merchant portfolios — hosted in MENA-ready regions (EG / KSA / UAE options).
Dedicated / private cloud
Isolated deployment for regulated buyers on major clouds (AWS / Azure) with programme-stated RTO/RPO.
Hybrid edge
Portal and APIs in Flagship cloud with channel credentials vaulted per tenant policy; on-prem connector agents available where required.
- Multi-AZ active-active control plane with programme-stated RTO/RPO in the runbook.
- Data residency options for EG / KSA / UAE markets; data classes that may leave the region are listed in the DPA.
- Card PAN is not intended to live in the orchestration domain when checkout stays on the certified gateway path.
Integration experience
Integrate once to Flagship APIs; channel-specific credentials stay in adapter configuration. Examples below use example.com hosts — replace with your environment.
Illustrative example — not a live endpoint
Request
POST https://api.flagship.example/v1/orchestration/invoices
Authorization: Bearer $FLAGSHIP_TOKEN
Content-Type: application/json { "merchant_id": "m_8KQH", "amount": { "value": "1250.00", "currency": "EGP" }, "channels": ["paymob", "fawrypay"]
}Response
{ "id": "inv_01HXYZ", "status": "open", "pay_link": "https://pay.flagship.example/i/inv_01HXYZ", "routing_policy": "pol_merchant_default"
}SDKs & client libraries
OpenAPI + REST; TypeScript / Node and language packs issued at onboardingREST + webhooks (illustrative)OpenAPI pack during onboarding
Integrations
FawryPayPaymobPayTabsKashierMPGS
Security and compliance
Controls you can operate — RBAC, dual control, and audit trails.
RBAC on portal actions
Role-based access for merchant and operator consoles; sensitive policy edits require elevated roles.
Maker-checker
Routing rules, fee profiles, and settlement calendars can require dual control before activation.
Audit trail
Configuration and routing changes retain actor, timestamp, and reason codes.
Pricing orientation
Commercial model is programme-based — platform access plus usage drivers. Numbers on request after scoping channels and merchant count.
Active merchants / tenants
How many merchant profiles and operator seats you run.
Channels enabled
Which PSP and card adapters are live in production.
Transaction volume
Monthly successful payments across orchestrated channels.
Deployment model
Shared SaaS vs dedicated / private deployment.
No public list prices on this page — book a walkthrough for a scoped estimate.
FAQ
Deal-killing objections, answered plainly.
Do merchants integrate with each PSP separately?
No. Merchants integrate with Flagship; Flagship talks to contracted channels on their behalf.
Can we force a specific channel per invoice?
Yes. Routing is policy-driven per merchant, amount, currency, and channel health — including hard pin to one acceptor when required.
How is this different from Primer or Spreedly?
Those platforms are strong for multi-PSP card orchestration globally. Flagship Orchestrator is built around regional MENA acceptors plus MPGS card rails.
Does AI change production routing automatically?
No. Assisted suggestions can recommend policy changes; promotion still goes through your maker-checker path.
What if a PSP we need is not listed?
New adapters are scoped as integration work with lead time based on provider API maturity. Talk to solutions with the provider name and API docs.
Related products
Map your channels in a working session
Bring your contracted PSPs and a pilot merchant. We will walk policy routing and sandbox — not a slide-only demo.