Case Study · 02
Led requirements, architecture documentation and retailer communication for a complex payment tokenisation integration — balancing security, UX continuity and partner onboarding complexity.
The platform needed to introduce payment tokenisation to reduce PCI-DSS scope and enable recurring payment capability across multiple telecoms retailers. Each retailer had a different payment infrastructure — some using TokenEx, others integrated with Braintree or ANZ Cybersource — meaning a one-size-fits-all implementation wasn't possible.
The challenge was threefold: define a tokenisation architecture that worked across all PSP combinations; produce documentation clear enough for both technical teams and non-technical retail partners; and sequence the rollout to avoid disrupting live payment flows during migration.
I began by mapping the current payment flow for each retailer — tracing where card data was touched, stored or transmitted and identifying the specific PCI scope reduction opportunity at each step. This produced a clear picture of three distinct integration patterns, which then formed the architecture options.
For each option I documented: the token flow, the PSP integration model (hosted fields vs iframe vs server-side), the retailer change surface, the UX impact on end customers, and the migration path from the current state.
A technical architecture document (internal) covering all three PSP models with sequence diagrams, data flow maps, and failure mode analysis. A retailer-facing explainer (two pages, non-technical) summarising the change, what retailers needed to do, and a timeline. An executive summary for leadership covering risk, cost and scope. And a set of acceptance criteria used to verify each integration during QA.
The hardest part was not the technology — it was aligning multiple retailers with different priorities, timelines and technical capacity to a shared rollout schedule. One partner wanted to delay indefinitely; I worked with the commercial team to frame the tokenisation upgrade as a prerequisite for a new feature they'd already requested, which resolved the impasse.
There was also tension between the ideal UX (fully hosted, invisible tokenisation) and what the platform's checkout architecture could support at the time. I documented the ideal state clearly in the architecture document but scoped the immediate work to what was deliverable within the quarter — preserving the future path without blocking current delivery.
Complex multi-party integrations live or die by documentation quality. The time I invested in producing separate documents for technical teams vs retailer partners vs leadership was repaid many times over in fewer escalations, faster sign-off, and smoother onboarding calls.