MPGS Acquirer Integration Programme: Hosted Session, 3DS2, Tokenisation and the Recurring Stack

Designed and shipped the full MPGS surface for a regional acquirer-processor, moving from a single Hosted Checkout integration into Hosted Session (for branded checkouts), Direct API (for recurring and merchant-of-record flows), EMV 3DS2 step-up tuning, scheme tokenisation, recurring billing, dispute ingestion and merchant-facing settlement reconciliation. Migrated 1,200+ merchants in three primary markets across an 18-month rollout with no 24-hour outage and a +3.4-point portfolio-wide authorisation-rate uplift.

The acquirer had launched on MPGS via the standard Hosted Checkout flow and stayed there. The integration was stable, but the platform was locked out of every flow that mattered for premium merchants: branded checkouts, recurring billing, scheme tokenisation, merchant-of-record marketplaces, MIT/CIT differentiation, and structured 3DS2 exemption logic. Authorisation rates lagged the regional benchmark by 3–4 points. Disputes were handled by ops staff opening the scheme portal merchant-by-merchant. Settlement reconciliation was a daily fire drill. The next-quarter scheme mandate on network tokenisation made the gap untenable.

• Hosted Session integration: kept MPGS PCI scope while letting merchants brand the checkout (own CSS, own form, own redirect-free experience)
• Direct API integration for recurring (RECURRING / INITIAL CIT / SUBSEQUENT MIT) and marketplace flows that needed payer-not-present orchestration
• EMV 3DS2 step-up logic with explicit handling of all five PSD2 exemptions (TRA, low-value, recurring, trusted beneficiary, MIT) and per-issuer step-up scoring
• Network tokenisation via MDES (Mastercard) and VTS (Visa), replacing PAN-on-file with scheme tokens for 92% of card-on-file merchants
• Recurring billing engine: token-backed subscriptions, retry ladder driven by decline-reason taxonomy, dunning sequences per market
• Dispute ingestion: scheme webhook + Notification Service consumer into the internal case-management system; evidence-upload portal for merchants
• Settlement reconciliation: MPGS settlement file + scheme report + bank statement triple-match with per-merchant break detection
• Per-merchant migration tooling: feature-flag rollout, dry-run mode for new flows, instant rollback to Hosted Checkout if a merchant tripped a guard-rail

• MPGS integration sits behind a stable internal Acquirer API; Hosted Checkout vs Hosted Session vs Direct API is an internal routing decision per merchant, not a per-merchant SDK
• 3DS2 step-up logic runs as a pre-auth service: scores the transaction, picks the exemption, calls MPGS with the exemption flag, falls back to step-up only when the score demands it
• Tokenisation is a one-way migration per merchant: PAN is detokenised inside a hardened service the merchant never sees; merchant-facing APIs only ever reference scheme tokens
• Recurring engine is event-sourced: every retry decision is a recorded event with the decline reason and the next-attempt rule that fired
• Settlement reconciliation runs T+1 morning; breaks are routed to per-merchant queues with named ops owners and SLA timers
• Dispute case manager is the system of record; the scheme portal is a downstream view kept in sync via the MPGS Notification Service

• Weekly auth-rate review: per network, per BIN, per merchant tier, with decline-reason drilldown and the next experiment queued
• Weekly 3DS2 health review: frictionless rate, step-up rate, abandonment, issuer-level outliers
• Monthly tokenisation rollout review: merchants migrated, post-migration auth-rate delta, PCI-scope evidence captured
• Daily settlement-break standup with finance: prior-day breaks, root cause, remediation, evidence
• Quarterly MPGS / scheme certification window: SAQ refresh, scheme attestation, EMVCo recertification on any new flows

Owned the MPGS programme end-to-end as Product & Program lead, integration architecture, merchant-rollout sequencing, scheme-certification path, auth-rate optimisation programme, tokenisation rollout, dispute-product surface, settlement-reconciliation product, and the per-merchant migration governance. Direct accountability for portfolio auth rate, dispute cycle time, settlement break rate and scheme-certification posture.

• Lifted portfolio-wide authorisation rate by +3.4 points across the 18-month programme, driven by 3DS2 exemption tuning, BIN-routing optimisation, and tokenisation lift
• Migrated 1,200+ merchants from Hosted Checkout to the appropriate MPGS integration mode without a single 24-hour outage
• Reached 92% network-tokenisation coverage on card-on-file merchants ahead of the regional scheme deadline
• Compressed median dispute cycle time from 21 days to 12 days through ingestion + merchant evidence-upload portal
• Held settlement break rate below 0.04% throughout the rollout, including across the tokenisation migration window
• Established the auth-rate optimisation programme as a permanent operating cadence rather than a one-time project

• Chose Hosted Session over a pure-Direct API rollout for premium merchants, accepted slightly less UI freedom in exchange for keeping PCI scope inside MPGS
• Built a per-merchant migration tool rather than a portfolio-wide cutover, added programme complexity but removed the single-event blast radius that a portfolio cutover would have carried
• Ran scheme tokenisation as a one-way migration with no rollback path post-cutover per merchant, required earlier merchant comms and a higher reference-merchant bar, in exchange for clean PCI scope reduction
• Standardised on internal MPGS APIs rather than letting each squad call MPGS directly, slowed initial features by ~6 weeks; saved ~6 quarters of rework when MPGS shipped breaking changes

• MPGS Hosted Checkout is the right starting integration; staying on it past $200M TPV is a strategic mistake, not a stability win
• Auth-rate optimisation is a permanent programme, not a project. The first 2 points come from 3DS2; the next 1–2 points come from BIN routing and tokenisation; the last 0.5 point comes from per-issuer experiments
• Network tokenisation is the highest-leverage migration on the MPGS surface. The PCI-scope reduction, the auth-rate lift, and the lifecycle automation each justify it on their own; together they pay back the migration cost inside two quarters
• Dispute product matters at portfolio scale. Once the platform crosses ~10k disputes/year, ingesting the scheme portal into the internal case manager removes more ops cost than any other single move
• Migration governance is the actual product. A per-merchant flag, a dry-run mode, a rollback, and a named ops owner per merchant tier, these are the artefacts that decided whether the programme shipped clean or shipped incidents

Most acquirer-processors in MENA, South Asia, and emerging Asia run a subset of the MPGS surface. The teams that own the full surface, Hosted Session, Direct API, 3DS2 exemption tuning, scheme tokenisation, recurring, dispute ingestion, settlement reconciliation, outpace the rest of the market on auth rate, dispute cost, PCI scope and merchant retention. The teams that stay on Hosted Checkout become orchestration shells around someone else's platform. This is the playbook for moving from the first posture to the second without a 24-hour outage in the migration window.