Product Designer
UX/ UI Product Design
2024
Making a payment gateway migration invisible to the customer
An Australian paint retailer needed to migrate their checkout from a legacy payment system to Windcave. Technically, this was an infrastructure change. From a UX perspective, it was a trust problem: how do you change the payment layer at the most anxiety-prone moment in a purchase flow without the customer noticing? This was a client project. The redesign was shipped and implemented according to spec. Post-launch conversion metrics are under client NDA. This case documents the problem framing, constraint analysis, three key design decisions, and their rationale.
AU
Australian market, payment norms specific to context
1
Critical moment: checkout is the highest drop-off point in any purchase flow
Shipped
Implemented by client according to spec and timeline
Product Designer
UX/ UI Product Design
2024
Making a payment gateway migration invisible to the customer
An Australian paint retailer needed to migrate their checkout from a legacy payment system to Windcave. Technically, this was an infrastructure change. From a UX perspective, it was a trust problem: how do you change the payment layer at the most anxiety-prone moment in a purchase flow without the customer noticing? This was a client project. The redesign was shipped and implemented according to spec. Post-launch conversion metrics are under client NDA. This case documents the problem framing, constraint analysis, three key design decisions, and their rationale.
AU
Australian market, payment norms specific to context
1
Critical moment: checkout is the highest drop-off point in any purchase flow
Shipped
Implemented by client according to spec and timeline
Why payment gateway migrations are a UX problem, not just an engineering problem
A payment gateway migration is typically scoped as a backend task. The business changes its payment processor, engineering integrates the new system, and someone gets handed the API docs. What tends to get underweighted is that the checkout interface is the moment of highest user anxiety in a purchase flow. Any visible change at that moment, even a well-intentioned one, triggers hesitation.
For this client, the legacy checkout had a known issue: the payment experience broke visual consistency with the rest of the site. The Windcave migration was the opportunity to fix that, but it came with its own risk. Windcave has a default integration pattern (a hosted payment page via redirect) that takes users out of the retailer's environment entirely. For a customer mid-purchase, a redirect to an unfamiliar page is a common abandonment trigger.
The brief was to integrate Windcave in a way that felt native to the site, maintained brand trust signals at the payment step, and preserved user control throughout.
The core tension
Windcave's default redirect pattern is secure and technically simple to implement. It's also the worst UX choice for a retailer that has built trust through consistent brand experience. Keeping the payment in-context meant more implementation work but significantly less abandonment risk at the most sensitive step.
What was actually broken
The existing checkout had three specific problems that the migration needed to address, not just inherit.
Visual discontinuity. The payment step looked different from the rest of the site. Different fonts, different button styles, different input field styling. Users who noticed this, and many did, interpreted it as a security warning rather than a design inconsistency. This is documented checkout abandonment behaviour: visual mismatch at payment correlates directly with trust drop-off.
No clear withdrawal mechanism. Once a user reached the payment step, the only way back was the browser back button. There was no explicit "cancel" or "return to cart" option. For users who wanted to change their order, this created a moment of panic that ended in abandonment.
AU market expectations not met. Australian online shoppers have specific familiarity with payment flows through platforms like Afterpay, PayPal, and the major bank gateways. They expect either a seamless in-page payment form or a clearly branded redirect. An anonymous-looking iframe pattern, which the legacy system used, reads as suspicious in this market context.
What shaped the design space
Windcave integration parameters: limited control over form fields within hosted payment page
AU payment compliance requirements
Brand consistency required: must match existing site design system
No checkout redesign: scope limited to the payment step, not the full funnel
Client timeline: fixed delivery date, no scope for new feature development
The most significant constraint was Windcave itself. Their hosted payment page allows for CSS customisation but limits what can be changed structurally. The design had to work within those limits while still achieving visual consistency with the site. The approach was to treat the payment interface as a modal overlay rather than a separate page, which gave full control over the surrounding chrome while working within Windcave's form constraints.
Three decisions that defined the implementation
Shared structural components, per-realm brand application
There were three integration options: full-page redirect (Windcave default), inline embedded form, and modal overlay. Full-page redirect removes the customer from the retailer's environment entirely, the highest abandonment risk. Inline embedding creates a complex iframe security context that doesn't reliably match the surrounding page visually. Modal overlay was the right call. It keeps the customer visually within the retailer's environment throughout the payment step. The site remains visible behind the modal, reinforcing context. Windcave's payment form sits inside the modal, where its styling constraints can be managed without fighting an iframe context.
What it prevents
The "where am I?" abandonment moment that redirect flows create when users land on an unfamiliar domain mid-purchase.
What it enables
Full visual consistency with the site design system in the modal chrome. Windcave handles the payment fields; the design controls everything around them.
Explicit close/cancel mechanism with clear labelling
Payment interfaces routinely omit a clear cancel mechanism because the assumption is that users who have reached checkout are committed. That assumption is wrong in practice. Users who want to change their order, check something in their cart, or simply reconsider need a clear, safe exit path. Without one, they abandon.
The modal included a clearly labelled close button (not an X icon, a text label: "Return to cart") positioned consistently with AU user expectations for modal dismissal. This is not a concession to indecision. It is a trust signal. A payment interface that lets you leave easily is one that users feel comfortable entering.
Full design system alignment for the modal chrome
Every element surrounding the Windcave payment form, the modal header, the order summary display, the button styling, the typographic hierarchy, was specified against the existing site design system. This required mapping the site's design tokens to Windcave's customisation options and identifying where gaps existed.
Where Windcave couldn't be customised to match exactly, the design prioritised consistency in the highest-visibility elements: button styles and typography. Lower- visibility elements like input borders were accepted as close-enough rather than creating a workaround that would require ongoing maintenance.
What I specifically did
Analysed the Windcave integration documentation to map what was customisable vs. fixed, establishing the design constraints before any screens were produced
Proposed the modal overlay approach (vs. redirect or inline) and documented the rationale for client sign-off, specifically addressing the AU market abandonment risk associated with redirects
Mapped the existing site design system tokens to Windcave's customisation parameters, identifying where full alignment was achievable and where pragmatic compromises were needed
Designed the full modal chrome: header, order summary display, close mechanism, and button hierarchy, all aligned to the site design system
Specified the payment interaction states (loading, processing, error, success) with exact UI behaviour for each, reducing implementation ambiguity in the handoff
Delivered the design spec and developer handoff documentation to the client's engineering team within the fixed timeline
What this project taught me about integration UX
Payment gateway migrations are a common type of project that rarely gets treated as a design problem. The brief almost always comes in as "make it look the same" rather than "fix what was broken." The best outcome in this case was identifying that the legacy system had problems worth solving and scoping them into the migration, not just porting the existing design to the new gateway.
The constraint I'd have pushed harder on is conversion instrumentation. The modal approach was a defensible design decision, but without a proper A/B test against the redirect alternative, the improvement is argued, not demonstrated. For any future project of this type, instrumenting the checkout before the migration, not after, is the single most valuable thing a designer can do.
What this resolved
The modal overlay approach eliminated the redirect abandonment risk documented in AU market research, while Windcave's iframe security constraints made inline embedding non-viable. This wasn't a default choice: it was a constrained decision with a documented rationale that the client signed off on before implementation began.
The design system token mapping identified exactly where full alignment was achievable and where pragmatic compromises were necessary, preventing scope creep and reducing implementation ambiguity. The engineering team had a complete spec covering all interaction states (loading, processing, error, success) before writing a line of code.
The explicit "Return to cart" mechanism, a text label and not an icon, was added after the competitive analysis revealed that cancellation ambiguity was a documented drop-off cause in AU checkout flows. This wasn't in the original brief. It was identified through research and scoped into the implementation.
What was actually broken
The existing checkout had three specific problems that the migration needed to address, not just inherit.
Visual discontinuity. The payment step looked different from the rest of the site. Different fonts, different button styles, different input field styling. Users who noticed this, and many did, interpreted it as a security warning rather than a design inconsistency. This is documented checkout abandonment behaviour: visual mismatch at payment correlates directly with trust drop-off.
No clear withdrawal mechanism. Once a user reached the payment step, the only way back was the browser back button. There was no explicit "cancel" or "return to cart" option. For users who wanted to change their order, this created a moment of panic that ended in abandonment.
AU market expectations not met. Australian online shoppers have specific familiarity with payment flows through platforms like Afterpay, PayPal, and the major bank gateways. They expect either a seamless in-page payment form or a clearly branded redirect. An anonymous-looking iframe pattern, which the legacy system used, reads as suspicious in this market context.
What shaped the design space
Windcave integration parameters: limited control over form fields within hosted payment page
AU payment compliance requirements
Brand consistency required: must match existing site design system
No checkout redesign: scope limited to the payment step, not the full funnel
Client timeline: fixed delivery date, no scope for new feature development
The most significant constraint was Windcave itself. Their hosted payment page allows for CSS customisation but limits what can be changed structurally. The design had to work within those limits while still achieving visual consistency with the site. The approach was to treat the payment interface as a modal overlay rather than a separate page, which gave full control over the surrounding chrome while working within Windcave's form constraints.
Three decisions that defined the implementation
Shared structural components, per-realm brand application
There were three integration options: full-page redirect (Windcave default), inline embedded form, and modal overlay. Full-page redirect removes the customer from the retailer's environment entirely, the highest abandonment risk. Inline embedding creates a complex iframe security context that doesn't reliably match the surrounding page visually. Modal overlay was the right call. It keeps the customer visually within the retailer's environment throughout the payment step. The site remains visible behind the modal, reinforcing context. Windcave's payment form sits inside the modal, where its styling constraints can be managed without fighting an iframe context.
What it prevents
The "where am I?" abandonment moment that redirect flows create when users land on an unfamiliar domain mid-purchase.
What it enables
Full visual consistency with the site design system in the modal chrome. Windcave handles the payment fields; the design controls everything around them.
Explicit close/cancel mechanism with clear labelling
Payment interfaces routinely omit a clear cancel mechanism because the assumption is that users who have reached checkout are committed. That assumption is wrong in practice. Users who want to change their order, check something in their cart, or simply reconsider need a clear, safe exit path. Without one, they abandon.
The modal included a clearly labelled close button (not an X icon, a text label: "Return to cart") positioned consistently with AU user expectations for modal dismissal. This is not a concession to indecision. It is a trust signal. A payment interface that lets you leave easily is one that users feel comfortable entering.
Full design system alignment for the modal chrome
Every element surrounding the Windcave payment form, the modal header, the order summary display, the button styling, the typographic hierarchy, was specified against the existing site design system. This required mapping the site's design tokens to Windcave's customisation options and identifying where gaps existed.
Where Windcave couldn't be customised to match exactly, the design prioritised consistency in the highest-visibility elements: button styles and typography. Lower- visibility elements like input borders were accepted as close-enough rather than creating a workaround that would require ongoing maintenance.
What I specifically did
Analysed the Windcave integration documentation to map what was customisable vs. fixed, establishing the design constraints before any screens were produced
Proposed the modal overlay approach (vs. redirect or inline) and documented the rationale for client sign-off, specifically addressing the AU market abandonment risk associated with redirects
Mapped the existing site design system tokens to Windcave's customisation parameters, identifying where full alignment was achievable and where pragmatic compromises were needed
Designed the full modal chrome: header, order summary display, close mechanism, and button hierarchy, all aligned to the site design system
Specified the payment interaction states (loading, processing, error, success) with exact UI behaviour for each, reducing implementation ambiguity in the handoff
Delivered the design spec and developer handoff documentation to the client's engineering team within the fixed timeline
What this project taught me about integration UX
Payment gateway migrations are a common type of project that rarely gets treated as a design problem. The brief almost always comes in as "make it look the same" rather than "fix what was broken." The best outcome in this case was identifying that the legacy system had problems worth solving and scoping them into the migration, not just porting the existing design to the new gateway.
The constraint I'd have pushed harder on is conversion instrumentation. The modal approach was a defensible design decision, but without a proper A/B test against the redirect alternative, the improvement is argued, not demonstrated. For any future project of this type, instrumenting the checkout before the migration, not after, is the single most valuable thing a designer can do.
What this resolved
The modal overlay approach eliminated the redirect abandonment risk documented in AU market research, while Windcave's iframe security constraints made inline embedding non-viable. This wasn't a default choice: it was a constrained decision with a documented rationale that the client signed off on before implementation began.
The design system token mapping identified exactly where full alignment was achievable and where pragmatic compromises were necessary, preventing scope creep and reducing implementation ambiguity. The engineering team had a complete spec covering all interaction states (loading, processing, error, success) before writing a line of code.
The explicit "Return to cart" mechanism, a text label and not an icon, was added after the competitive analysis revealed that cancellation ambiguity was a documented drop-off cause in AU checkout flows. This wasn't in the original brief. It was identified through research and scoped into the implementation.