Google Pay & Samsung Pay — Wallet Provisioning at Scale
Own product backlog and B2B integration specifications for the edge applications connecting a major US card network to Google Pay and Samsung Pay — validating that a live card portfolio migration stays invisible to wallet users, while expanding the underlying specification to support international issuers.
The takeaway: First international issuer live on push provisioning in 2025, with zero cardholder-facing disruption through an ongoing, large-scale card portfolio migration.
Role
Product Owner (Proxy PO → PO) — backlog ownership across two squads, B2B integration spec ownership, card migration validation, international issuer onboarding
Timeline
Mid 2022 – present
Stack
Legacy On-Prem Applications · Dual-DC Hosting (US) · B2B Integration Specs
Status
Active — ongoing, expanding internationally
Specifications run in one of two directions: built to a partner's spec, or owned by the network with partners building to it. This sits on the network-driven side — Google and Samsung each integrate against their own B2B specification, both of which my team defines and maintains.
Problem
Two live fault lines at once
The edge applications connecting the network to Google Pay and Samsung Pay sit on two live fault lines at once. A large-scale card portfolio migration means the underlying card programme itself is changing — and a digital wallet token has to survive that change without the cardholder noticing.
At the same time, specifications and validation rules originally written around a single primary issuer's conventions have to generalize as international franchise issuers come on board, without losing the rigor that keeps bad data out.
Scope
My scope: two squads, one backlog owner
Backlog Ownership
Two Squads, Two Boards
- Epics, user stories, and acceptance criteria across two squads' separate backlogs (Google Pay and Samsung Pay component teams).
- Cross-cutting initiatives — like the card migration validation — synchronized across both teams' boards through shared epics, not a merged backlog.
B2B Integration Specs
The Contract Partners Build Against
- Define and maintain the B2B integration specifications partner organisations build against.
- Own the specification changes needed to generalize validation rules for international issuers, without loosening them enough to let bad data through.
Card Migration Validation
Quality & Continuity
- Lead wallet provisioning validation across Google Pay and Samsung Pay for a large-scale card migration programme.
- Validate functional behaviour in pre-production for every migration wave before it reaches cardholders.
Out of Scope
Clear Boundaries
- Samsung Wallet push provisioning — code-complete, not yet toggled on in production.
- The original Google Pay Transit enablement work — predates this scope.
- Apple Pay — owned by a different team.
Initiatives
Selected initiatives
Validating that a card migration is invisible to the wallet
When a large card portfolio moves to a new underlying issuer, the physical card changes, but a digital wallet token shouldn't care. My teams validate the functional behavior of provisioned Google Pay and Samsung Pay tokens through every migration wave in pre-production: confirming that once the new card is live, the wallet token quietly picks up the new payment profile with zero cardholder friction (no re-enrollment, no re-adding the card, nothing for the cardholder to notice). The plastic changes; the wallet just keeps working.
Token cleanup on a live repersonalization
A live Google Wallet token repersonalization campaign left a long tail — cardholders who hadn't reopened their wallet or had inactive devices never picked up their new payment profile. The process ran in two staged batches: the network sent 'tickle' notifications for every token still on the old SDK, then Google processed those and pushed repersonalization calls back, both ramping up over several days. I planned our batch schedule, worked with L1 support to run it, and tracked completion against both stages over two to three months to identify who was actually stuck — couldn't be tickled after several retries, or tickled but never repersonalized by a set date. About 30 days after Google's ramp-up hit 100%, I aligned with Google that the rest weren't coming back; the network then initiated the unlinks and kept Google and the issuer informed as the cleanup progressed, with Google and me closely coordinating throughout — closing the tail without touching cardholders who'd already migrated.
Internationalizing a single-issuer spec
Our B2B integration specification for Google Wallet push provisioning was written with one primary issuer in mind, including validation rules built around a single country's cardholder name and address formats. Bringing international franchise issuers onto the same capability meant relaxing that validation without loosening it so far it stopped catching bad data. The first international issuer onto this integration went live in 2025; a second is currently onboarding, validated end-to-end in production ahead of general availability.
Making a legacy, partner-published spec audit-ready
Network-driven specs come with real controls. Ours is legacy, published to partners as PDFs only once or twice a year, so whenever my work needs a spec change, I document it in Jira under the relevant epic with the updated draft attached, and log it in a tracker that ties every change back to its Jira ID. When a recent audit asked us to produce evidence for every change made, that tracker answered it directly: nothing to reconstruct after the fact.
Outcomes
The impact
2025
first international issuer onto this integration, live on push provisioning
- Directs two squads' separate backlogs (Google Pay and Samsung Pay component teams) as independent Jira boards, synchronizing cross-cutting initiatives — like the card migration validation — through shared epics rather than merging them.
- Digital wallet tokens continue to work for cardholders through a live, large-scale card portfolio migration — validated in pre-production ahead of each production wave, so the migration stays invisible to the wallet experience.
- Closed out the legacy tail of a live token repersonalization campaign, coordinating directly with Google over several months to clean up tokens that never migrated.
- Proved a specification built for a single issuer could generalize internationally — first market onto this integration live in 2025, a second validated end-to-end in production ahead of general availability.
- Passed a recent audit on full spec-change traceability — every change traced from tracker entry to Jira ticket, with nothing needing reconstruction after the fact.
Next
More case studies
Chrome Virtual Card Autofill
Owned the technical delivery for the retrieval flow of a major Virtual Card integration with Google Chrome, translating Google's API architecture into an enterprise delivery programme that processed 275,000+ requests in its first 60 days.
OpenCAM Framework
Engineered a dual-agent LLM pipeline with deterministic policy gating, targeting a cut in CAM drafting time from a business day to 15–30 minutes.
AI Job Search Automation
Extended an open-source job-search framework with Gmail recommendation-lead detection, repost-dedup hardening, a live application dashboard, and a shared posting-fetch cache — automation layered on a forked base, not authored from scratch.