Skip to main content
Flagship Fintech

Platform/Gateway

02 · Gateway

MPGS-integrated
card acceptance.

Run card-not-present acceptance on Mastercard Payment Gateway Services (MPGS) with multi-acquirer mapping, hosted or embedded checkout, 3DS2, and webhooks your ops stack can reconcile.

Built forBanks, PSPs, and enterprises that need enterprise card acceptance with acquirer agility — not a consumer wallet UI

Book a technical walkthroughRequest sandbox
Card rail
Mastercard Payment Gateway Services (MPGS)
Checkout modes
Hosted · embedded · API-driven
SCA
3-D Secure 2 flows configurable per programme
02 · Problem

What buyers are solving

Framed for Banks, PSPs, and enterprises that need enterprise card acceptance with acquirer agility — not a consumer wallet UI — not generic payment pain.

Acquirer lock-in in the checkout layer

Hard-wiring one acquirer into storefront code makes BIN routing and failover a rebuild project.

Webhook chaos for finance

Capture, void, and refund events arrive as vendor-specific payloads that recon teams cannot trust.

SCA as an afterthought

3DS2 bolted on late creates drop-off and dispute friction without programme-level controls.

03 · Flow

How it works

  1. Register order

    Create an order with amount, currency, and line items.

  2. Checkout session

    Spin up an MPGS-backed session with the right profile.

  3. Present checkout

    Hosted page or embedded fields — your choice.

  4. Customer pays

    SCA and scheme rules applied per configuration.

  5. Finalize

    Webhooks and capture rules drive settlement handoff.

gateway · checkout flow · merchant_8KQH
1Register orderamount · currency · items
2Checkout sessionMPGS · 3DS2
3Present checkouthosted · embedded
4Webhooksfinalize · capture
MPGS profile · merchant_8KQHapproved · 284ms
04 · Capabilities

Core capabilities

Each capability names a concrete mechanism — not a marketing adjective.

MPGS order lifecycle

Register order → create checkout session → present checkout → receive webhooks → finalize capture or void under documented states.

Multi-acquirer mapping

Route by merchant, scheme, or BIN to the contracted acquirer with configurable failover — without re-platforming the storefront.

Hosted checkout

Redirect or hosted page option that keeps card entry off your origin when you choose the hosted path.

Embedded fields

Embed checkout components in your flow while still using MPGS session semantics for authorization.

3DS2 / SCA controls

Configure challenge and exemption posture per merchant programme — not a single global toggle.

Webhook contract

Signed event deliveries for auth, capture, refund, and failure states with retry semantics your ops can monitor.

Fee profiles

Flexible fee configuration per merchant or portfolio, resolved into settlement eligibility rules.

Tokenisation hooks

Network tokens and vault patterns where supported by the MPGS / acquirer configuration and your vault partner.

Positioning

Where this sits vs alternatives

Build in-house on raw MPGS

You still need merchant onboarding, acquirer maps, webhook normalization, and operator tooling — Gateway packages that control plane around MPGS.

Local incumbent gateway

Incumbents often fix you to one acquirer stack. Multi-acquirer mapping is a first-class configuration surface here.

Adyen-for-platforms class

Global platforms optimize for their acquiring network. Flagship Gateway is built to sit with your bank/PSP relationships via MPGS profiles you control.

05 · Architecture

Architecture and deployment

Checkout surfaces and merchant APIs sit above an MPGS integration layer; tokens and PAN handling follow the certified path you configure.

Deployment options

SaaS

Multi-tenant gateway control plane hosted in MENA-ready regions.

Dedicated tenant

Isolated keys and profiles for enterprise programmes on dedicated or private-cloud tenancy.

PCI posture options

Hosted fields / hosted checkout to reduce merchant PCI scope; SAQ guidance provided with your integration pack.

  • HA/DR for gateway APIs and webhook workers with multi-AZ failover and stated RTO/RPO per programme.
  • Order metadata residency is programme-configurable; card data stays on the certified MPGS / vault path.
  • PAN handling stays aligned to MPGS / vault boundaries configured at onboarding.
06 · Integration

Integration experience

Typical path: create order, open session, present checkout, consume webhooks. Hosts below are illustrative.

Illustrative example — not a live endpoint

Request
POST https://api.flagship.example/v1/checkout/sessions
Authorization: Bearer $FLAGSHIP_TOKEN
Content-Type: application/json { "merchant_id": "m_8KQH", "amount": { "value": "199.00", "currency": "EGP" }, "capture": "auto", "return_url": "https://merchant.example/orders/199/done"
}
Response
{ "session_id": "cs_01HABC", "checkout_url": "https://checkout.flagship.example/cs_01HABC", "status": "open", "3ds": { "required": "programme_default" }
}

SDKs & client libraries

JavaScript / TypeScript checkout SDK; native mobile packs on requestREST + webhooksServer libraries for Node, Java, and .NET during onboarding

Sandbox

Sandbox MPGS profiles and test BINs are issued with your tenant — request via contact intent=sandbox. Test-card tables ship with the sandbox pack.

Typical integration timeline

  • Days 1–5Keys, sandbox merchant, and sample checkout in the first few days
  • Week 2–43DS programme config, webhook consumers, refund paths
  • Go-liveAcquirer mapping sign-off, production MIDs, and certification steps from your integration pack

Integrations

Mastercard MPGSVisa3DS2
07 · Security

Security and compliance

Reduce card-data scope where hosted checkout paths apply.

Hosted checkout scope

Hosted checkout / fields patterns keep PAN off merchant origins when configured that way.

API key hygiene

Least-privilege keys per environment (sandbox vs production) with rotation procedures agreed at onboarding.

Webhook authenticity

Signed deliveries (HMAC) so finance and risk consumers can reject forged events — algorithm docs in the webhook guide.

3DS2 / SCA controls

3DS2 flows follow programme configuration for challenge and exemption posture.

08 · Commercial

Pricing orientation

Gateway pricing typically combines platform access, transaction volume, and optional dedicated tenancy. Numbers on request.

Monthly auth volume

Successful and attempted authorizations in scope.

Merchant / MID count

How many merchant profiles and acquirer mappings you run.

Checkout surfaces

Hosted vs embedded vs API-only programmes.

Support & SLA tier

Operating hours and response commitments defined in your support schedule.

No public rate card — request commercial discussion after technical fit.

09 · FAQ

FAQ

Deal-killing objections, answered plainly.

Is this only for e-commerce CNP?

Card-not-present is the primary fit. Pair with Payment Switch for in-store ISO 8583 / POS rails.

Can we use our own MPGS merchant IDs?

Yes. Profiles and acquirer mappings are configured per tenant or portfolio.

How do refunds and voids work?

They follow the same order model with auditable operator or API actions and webhook outcomes.

Will you store our PAN?

Design intent is to keep PAN in the certified MPGS / vault path you configure — a deal-specific data-flow diagram is produced during security review.

How does this compare to Adyen acquiring?

Adyen optimizes around its acquiring network. Flagship Gateway is built to orchestrate checkout on MPGS while you keep bank/acquirer relationships.

What about network tokens?

Supported where the MPGS and acquirer configuration allows — enablement is part of onboarding, not a silent default.

Fraud

Rules-first. Explainable by design.

Switch

ISO 8583 switching for POS estates.

Walk an order from session to webhook

Bring a sample MID and preferred checkout mode. We will map 3DS posture and sandbox next steps.

Book a technical walkthroughRequest sandbox