Amazon
Designing Verify and Pay for Amazon Payments
- Amazon
- Company
- Senior UX Designer
- Role
- Verify and Pay
- Product
Overview
Challenge
PSD2 forced Amazon EU to add a high-friction 3DS bank verification step to checkout, putting more than $18B in annual sales at risk. The default 3DS experience pushed customers into unfamiliar bank-controlled flows that felt suspicious, confusing, and easy to abandon.
Strategy
To meet the challenge, we had to go beyond a bolted-on technical MVP. Payment authentication needed to feel as if online payments had been designed around it from day one.
Impact
Recovered $3B+ in annual salesby redesigning Amazon EU's high-friction 3DS bank verification step. Designed and implemented a trust-based authentication experience that increased 3DS challenge success from 55% to 74%.
Starting Point
In 2019, Amazon faced a major compliance deadline: EU banking regulations mandated that online retailers introduce additional payment authentication across their payment experiences. This affected 42 businesses and subsidiaries across Amazon, and in Retail Checkout, the highest-stakes purchase flow, it put more than $18B in annual sales behind a new 3DS bank verification step.
Amazon’s payments infrastructure spanned subscriptions, pre-authorizations, free trials that rolled into paid plans, and charge-at-shipment orders. PSD2 introduced new rules—such as amount consistency and single-charge requirements—that conflicted with these models, forcing authentication into scenarios where customers did not expect it.
I was responsible for design for Retail Checkout payment authentication—the largest EU business and the de facto standardfor how authentication would be implemented across Amazon.
The Retail Checkout team moved quickly to assemble a technical MVP, bolting authentication onto existing flows with full-page redirects into the card issuer’s 3D Secure (3DS) experience.
But in usability testing, customers were confused and disoriented by the redirection. Some believed they had been redirected off Amazon to a malicious site. A measure intended to increase security was instead being interpreted as a threat at the moment of payment. The approach wasn’t working, but there was no clear direction for how to move forward.
| Scenario | Customer risk | Business risk | Design response |
|---|---|---|---|
| Retail Checkout MFA challenge | Additional steps and bank redirects could make checkout feel broken or unsafe. | Checkout abandonment and payment failures | Verify and Pay pattern plus a Retail Checkout reference implementation |
| Subscription free-trial preauthorization | Customers could interpret preauthorization as an unexpected charge. | Reduced conversion on free trial signups | Clear explanation of verification versus charging |
| Bundled subscriptions | Multiple subscriptions could trigger repeated challenges during signup. | Reduced conversion on bundled subscriptions | A consistent, reusable challenge model across related purchase flows |
| Cancellations and charge-at-fulfillment flows | Customers cancelling, changing, or fulfilling later could be challenged at unexpected moments. | Higher failures when charge timing or amount changed | Standardized expectations and recovery patterns for delayed or changed authorization |
| Trusted beneficiary and exemption paths | Even lower-friction paths such as trusted beneficiary could feel unfamiliar or suspicious without a shared model. | Fragmented exemptions and inconsistent trust signals | Reuse the same Verify and Pay language and structure across variants |
Design Strategy
I stepped in at this moment, when the team was stuck and the current direction had already failed with customers. My key insight was that authentication was being misinterpreted as a threat. PSD2 had introduced a security requirement that, when implemented naively, made customers feel less secure.
That gave me a clear thesis for the work: this was a trust problem at the moment of payment. The job was not to add a compliance step. The job was to redesign the payment model so that authentication felt expected, explained, and intentional.
Authentication was being misread as a threat
The default implementation added a security step that made customers feel exposed rather than protected. My goal was to help them interpret authentication as a security enhancement.
Checkout needed an integrated authentication model
I asked what the payment experience would look like if authentication had been part of checkout from day one, rather than something bolted on after the fact.
The issuer handoff had to feel expected and intentional
Once 3DS begins, control shifts from Amazon into a bank-controlled flow. Amazon had to prepare that transition clearly and recover gracefully when customers returned.
The deliverable had to scale across Amazon
Risk-based authentication appears inconsistently across purchase contexts, so the organization needed a reusable system that could absorb those variations without fragmenting the experience.
I framed the design question this way: what if checkout had been designed with authentication from day one? That changed the work materially. Instead of bolting a bank challenge onto the end of the purchase flow, I integrated authentication into the payment model itself, with clear preparation before the issuer handoff, explicit explanation of what was being verified, and a structure that accounted for the fact that control moves out of Amazon during the 3DS challenge.
I used Retail Checkout as the proving ground because it was the highest-stakes purchase context and the place where the failure was most costly. But I designed the work from the beginning as a reusable cross-Amazon system that other teams could adopt.
Solution
The outcome was Verify and Pay, a reusable pattern that integrated authentication into the purchase experience instead of treating it as an external interruption.
At its core, the pattern gave Amazon a consistent way to explain why authentication was happening, what amount was being authorized, when customers would interact with their bank, and what would happen after they returned from the issuer's flow. It turned a risky redirect into an intentional handoff.
The first implementation launched in Retail Checkout, where the pattern established the baseline interaction model for payment authentication. From there, the work scaled into a broader Amazon reference point for subscription, device, and media purchase scenarios that shared the same underlying trust problem.
The final deliverable was a durable product pattern that made a new regulatory burden feel more coherent to customers and more repeatable for teams.
Results
Recovered $3B+ in annual salesby redesigning Amazon EU's high-friction 3DS bank verification step. Designed and implemented a trust-based authentication experience that increased 3DS challenge success from 55% to 74%.
Just as importantly, the work gave Amazon a common design model for payment authentication. By turning Retail Checkout into a reusable reference implementation, I enabled adoption across 40+ teams spanning Prime, Kindle, Fire TV, and a much larger network of businesses and subsidiaries operating under the same regulatory pressure.
The long-term value of the project was a clearer, more scalable way to introduce sensitive security steps across new payment contexts without forcing each team to reinvent the customer experience.
55% → 74%
3DS challenge success in Retail Checkout
$3B+
Annual sales recovered by redesigning the 3DS flow
40+
Amazon teams enabled through the reference implementation
42
Businesses and subsidiaries covered by the authentication vision