Turning Compliance Into Competitive Advantage
A white-labeled hosted checkout that shifted PCI scope off travel brands while keeping the experience short, trusted, and conversion-focused.
Problem
Travel sellers needed to accept online payments without maintaining their own PCI compliance programs — and no hosted solution existed in our product suite.
Role
UX Lead — owned the end-to-end shopper experience across desktop and mobile, the white-label theming model, and UX documentation for the development team.
Constraints
Cardholder data had to remain fully isolated from client systems. Clients required strong visual continuity to protect conversion. The checkout had to remain short regardless of configuration.
Outcome
Core flows, responsive designs, theming guardrails, and configuration logic complete. Engineering actively building against the defined experience at the time of my departure.
1. Context & problem
Processing card payments directly requires strict security controls, audits, and operational oversight. Travel sellers wanted online payment capability without cardholder data passing through their own systems — but our platform had no hosted solution that isolated card capture from the merchant environment while integrating cleanly into their checkout flows.
The solution also had to work across desktop and mobile, support white-labeled deployments for multiple brands, and fit inside existing checkout flows without appearing to be a third-party redirect. That last part was non-negotiable: shoppers who sensed they'd left the airline's or hotel's own site would abandon.
2. Constraints & scope
Two forces pulled in opposite directions throughout the project: PCI compliance required strict structural control over the page, while white-label branding required meaningful flexibility. The design had to satisfy both without expanding checkout length or cognitive load.
-
Full technical isolation of cardholder data from client systems
-
White-label customization — colors, typography, logos, form labels, error messaging, corner radius, and key control placements
-
Rules-based payment method availability and ordering, resolved before page load
-
Conditional logic for fraud checks, device-specific optimization, promotional pricing, and location-based rules
-
Consistent behavior across desktop and mobile
-
Multi-tenant deployment across a shared infrastructure
The full feature set was available in our desktop and mobile experiences. All configuration elements could be targeted based on platform, browser, customer location, and many more parameters.
3. Research & insights
Research was conducted by our UX research team alongside ongoing conversations with primary clients, exploring how travel sellers handled payment acceptance, their configuration needs, PCI concerns, and shopper expectations during high-value transactions.
Branding flexibility was a conversion requirement, not a cosmetic preference. Even subtle visual differences could create hesitation or abandonment. Clients needed the hosted page to feel native to their site.
Layout flexibility mattered. Clients had strong opinions about order summary placement and form element sequencing — tied to conversion data from their own A/B tests, not aesthetic preference.
The initial configuration plan was too limited. The original scope allowed clients to configure by channel, region, and device — but research confirmed that wasn't sufficient for clients to meet their actual business goals. The configuration scope was expanded as a result.
4. Leadership & influence
Two of my most consequential contributions on this project were definitional rather than executional.
The first was determining which elements of the payment page needed to be themeable — and to what degree. I worked through the full interface and established where client branding control was a conversion necessity versus where structural consistency had to be maintained for compliance. That line shaped how the theming model was architected.
The second was identifying that the initial configuration plan wasn't sufficient for how clients actually needed to operate. I brought research into the project to validate whether that assumption was correct before the team committed to a direction. It was — and the findings drove a meaningful expansion of the configuration scope.
I also produced UX documentation for the development team, covering interaction patterns, component behavior, and edge cases — giving engineers a clear reference point throughout the build.
Our clients needed to be able to make our checkout path look like an extension of their shopping paths, or else they risked losing business from customers who might be confused or worried about the difference in look and feel from the client site to our own.
The payments experience could be highly customized by our clients, including the activation of key features, and the ability to extensively theme all elements of our solution to match their own trade dress.
5. Key decisions & trade-offs
Expanded the configuration scope before committing to a direction
The original plan allowed clients to configure payment options by channel, region, and device type. Working alongside research, I identified that this wasn't granular enough for clients to achieve their business goals — a logged-in frequent flyer, an iPhone user on Safari, a high-fraud market each required independent control. Research confirmed the gap with client participants, and the scope was expanded before design work progressed further.
Elevated branding to a structural requirement
Theming was designed as a core part of the system architecture, not a layer applied at the end. Clients needed enough flexibility to make the page feel native to their brand, without any ability to move compliance-critical elements.
Kept conditional logic invisible to the shopper
The rules-based configuration engine ran server-side, resolving which payment methods to show and in what order before the page loaded. The shopper always saw a clean, pre-optimized checkout. Configuration complexity never surfaced in the UI.
Defined guardrails to protect compliance without blocking customization
The theming model drew a clear line between what could be customized — visual treatments, labels, certain control placements — and what could not be moved. Those boundaries were documented explicitly so clients and engineering both understood where flexibility ended and compliance began.
We can't stress enough...it's a constant push to refine, enhance the wording, adjust the layouts.
Every single thing we can do to make this look better makes us more money.
6. Outcomes & reflection
Design status at departure
Core flows, responsive designs, and theming guardrails complete. UX documentation delivered to the engineering team.
Engineering status at departure
Actively building against the defined experience. Initiative had moved from design into active development.
The central design challenge was making a technically isolated, multi-tenant system feel invisible. PCI compliance drew hard lines around what the page could do structurally. Within those lines, every theming decision was ultimately a conversion decision — and treating it that way kept the work grounded in what clients actually needed.