Click to Pay (VCTP + MCTP) Programme: Scheme-Led Checkout, Recognised Cardholders, and 7.2pt Conversion Lift

Designed and shipped the Click to Pay programme, VCTP (Visa Click to Pay) + MCTP (Mastercard Click to Pay), on a regional acquirer's top-tier merchant cohort. Integrated the scheme-led wallet flow into hosted-checkout, hosted-session and direct-API merchant integrations; built recognised-cardholder enrolment into the platform's checkout surface; rolled out across 47 merchants in the first three quarters. Delivered +7.2 points checkout conversion on routed Click to Pay traffic, +1.4 points auth-rate on the same cohort, and ~210k+ enrolled cards with 44% cross-merchant reuse, proving the scheme-led wallet thesis on a regional portfolio for the first time.

The acquirer's top-tier merchants ran their own one-merchant card vaults, each merchant individually owned the cardholder identity and re-asked for PAN on the first transaction in every session. CNP checkout conversion lagged the regional benchmark by 5–8 points on the mobile cohort. Apple Pay and Google Pay were patchily adopted (Apple wallet penetration ~40% of iOS users; Google Pay closer to 20% on Android). The scheme account managers had been pushing Click to Pay for two years; the platform had repeatedly deferred because the integration looked complex and the merchant case study evidence was thin. The next-quarter scheme push (with explicit MDR pressure tied to VCTP / MCTP enrolment) made the deferral untenable.

• VCTP integration: Visa Click to Pay implemented behind the platform's unified checkout API, both EMVCo SRC (Secure Remote Commerce) and Visa-specific extensions
• MCTP integration: Mastercard Click to Pay implemented on the same surface, single internal checkout API, scheme-specific routing underneath
• Recognised-cardholder enrolment: in-checkout prompt at the moment the cardholder enters PAN; explicit opt-in; cards added to the scheme wallet under cardholder consent
• Cross-merchant recognition: cardholders who enrol at merchant A see the recognised-card prompt at merchant B without re-entering PAN
• Multi-card wallet UI: cardholders managing 2+ cards in the wallet can pick at checkout; default card per cardholder per merchant
• Federated checkout-state management: the wallet state persists across browsers, devices, and sessions via scheme cookies + cardholder identity
• Merchant onboarding tooling: per-merchant enrolment flow, configuration of the Click to Pay button placement, A/B testing harness for placement variants
• Fallback experience: when Click to Pay is unavailable (issuer mismatch, scheme outage, cardholder declines), the merchant's existing PAN-entry flow remains as primary

• Single internal checkout API fronts VCTP, MCTP and the merchant's local PAN-entry flow, scheme choice is per-cardholder, per-merchant config decision
• Click to Pay flow runs as an embedded iframe (EMVCo SRC standard) with the scheme-hosted iframe handling cardholder identification, card presentation, and 3DS2 authentication invocation
• Cardholder recognition runs at PAN-entry time via scheme APIs, checks whether the cardholder is enrolled before showing the manual PAN-entry surface
• Network token issuance via MDES + VTS happens at enrolment; the merchant receives a token, not the PAN, after Click to Pay completes
• Per-merchant config: button placement, default card selection, fallback policy, A/B testing variants
• Telemetry: every Click to Pay event (prompt-shown, prompt-accepted, card-selected, 3DS2-invoked, authorisation-result, abandonment) instrumented; merchant-facing dashboard surfaces the funnel

• Weekly Click to Pay funnel review: prompt-show rate, recognition rate, conversion rate, decline rate, by merchant, by issuer, by device class
• Monthly merchant rollout review: merchants live, in flight, paused, abandoned, with placement variant data and conversion delta
• Quarterly scheme alignment: VCTP + MCTP roadmap, scheme-specified enrolment growth targets, MDR programme participation
• Real-time alerting on Click to Pay availability (scheme outages); auto-fallback to merchant PAN-entry with no merchant-visible impact
• Annual scheme attestation: integration evidence, cardholder consent records, fraud-rate posture

Owned the Click to Pay programme end-to-end as Product & Program lead, VCTP + MCTP integration architecture, in-checkout enrolment design, merchant-rollout sequencing, A/B testing programme for button placement, scheme-relationship management, and the conversion-funnel telemetry. Direct accountability for merchant adoption cadence, enrolment rate, conversion-lift delivery, and scheme posture.

• Rolled out across 47 top-tier merchants in three quarters
• Delivered +7.2 points checkout conversion lift on routed Click to Pay traffic, largest single CNP conversion programme in the platform's history
• +1.4 points authorisation-rate uplift on Click to Pay vs. manual PAN-entry traffic (driven by network-token presentation + cleaner 3DS2 hand-off)
• Enrolled 210k+ cards in the scheme wallet in the first 90 days
• Achieved 44% cross-merchant card reuse, cardholders enrolled at merchant A using their wallet at merchant B without re-entering PAN
• Mobile checkout conversion lifted from 32% to 39%+ on routed merchants
• Closed the scheme account managers' two-year-running ask; secured MDR programme participation for the merchants

• Chose iframe (EMVCo SRC) over white-label SDK, accepted less merchant brand control on the Click to Pay surface; saved 6+ months of engineering and delivered the scheme-recognised cardholder experience
• Built A/B harness for button placement on every merchant rollout, added 2-3 weeks per merchant; produced the placement playbook that turned a 4-point lift into a 7.2-point one
• Required cardholder explicit opt-in for enrolment (no auto-enrol), slower enrolment growth than scheme-pushed auto-enrol would have delivered; lower complaint rate; cleaner regulator posture on consent
• Rolled out to the top-tier merchant cohort first, left mid-tier on the legacy flow for two quarters longer; concentrated the conversion-lift evidence in the strongest cohort and avoided diluted A/B data

• Click to Pay is a federated identity programme dressed as a checkout feature. The conversion lift comes from cross-merchant recognition, not from the Click to Pay button itself.
• Button placement is the single highest-leverage merchant-side decision. A/B placement variants per merchant produced 2-3 points of delta on otherwise-identical Click to Pay flows.
• Cardholder opt-in (no auto-enrol) is the right posture even when schemes push for the opposite. The complaint rate, the consent audit, and the regulator conversation are all easier with explicit opt-in.
• Network-token presentation through Click to Pay is what produces the auth-rate lift. The conversion lift is the headline; the auth-rate lift is the substance.
• Cross-merchant reuse rate is the leading indicator of programme success. 44% reuse on a regional cohort proved the scheme-led wallet thesis; below ~25% reuse and the programme is just an alternative checkout button.

The scheme-led wallet has been a story without proof for five years. Click to Pay has been live in the schemes since 2019; conversion-lift evidence on regional cohorts was thin until programmes like this one delivered the funnel data. The platforms that ship Click to Pay cleanly, VCTP + MCTP on a unified internal API, in-checkout enrolment, cross-merchant recognition, network-token presentation, get the conversion lift, the auth-rate lift, the MDR participation, and the scheme posture as one bundle. The ones that defer continue to lose CNP conversion to Apple Pay / Google Pay penetration where it exists, and to nothing where it does not. This is the playbook for shipping the scheme wallet in MENA, with the funnel evidence that justifies it.