Amazon Payment Experience (APX)

The system I found

In 2011, Amazon was at a crossroads between the scrappy independent culture that had built it and the global behemoth it was becoming. The company consisted of hundreds of independent teams with full control of their experience and technology stack. Amazon Payments was a collection of backend services that clients called directly; each team built its own customer experience with no top-down mandate for consistency, brand, tone, or feature parity. Because those clients coupled directly to backend services, often in very creative ways and with no mechanism to audit their use, changing the underlying systems had become impossible without breaking live experiences.

If a new payments feature needed to land everywhere (say, for regulatory reasons), the work had to be coordinated across hundreds of individual workstreams with duplicate design, development, and testing. Meanwhile the company was growing exponentially, domestically and into new international regions, each with its own cultural expectations, regulatory variation, and payment methods.

Collectively, Amazon Payments was on the verge of a crisis. A solution was broadly considered impossible to orchestrate without major cost and reductions in speed, growth, and experiential control. Payments had historically employed designers only for internal products like gift cards; the broader payment experience belonged to whichever team built it, and Amazon had no mechanism at all for cross-team experiences.

Mapping it

Discovery ran in two dimensions. The experience: the full payment lifecycle from purchase initiation through checkout, order and shipping behavior, returns, and post-order care, plus payment method and order management. And the clients: how those experiences actually manifested across hundreds of existing payment pipelines, and how those pipelines interacted.

Documenting the experience

There was no existing documentation of the Amazon payment experience, so I started from scratch with a sitewide audit: a test account, test payment methods, and the lifecycle of a purchase documented end to end (checkout, account management, order details, returns, error states). One basic credit card and one product first, then more products to expose variations, then additional payment methods. The output became comprehensive design documents the development team used to catalog features and build a plan, and eventually a detailed global pattern catalog to inform federated design.

The org chart is part of the system

I needed to understand variations in non-retail experiences, the landscape those clients faced, and the political structure the project would live inside. My approach was a social one, identify a team, research its lead designer (or, failing that, its lead PM) and reach out with an invitation for coffee or an informational interview. Each conversation mapped another region of the system and, as a byproduct, built the familiarity and strategic relationships the product would later depend on.

Three client cohorts emerged: small long-tail clients; medium non-retail clients like Kindle and Prime, and the megalith of Retail Core Shopping with its affiliates. The audit also exposed pervasive co-mingling of general payment features with client-specific ones, coupling that would have to be untangled before anything could be shared.

Two months of discovery compiled into a requirements list that seemed impossible: incorporate every unique client feature; add nothing that bottlenecks anyone; work for clients with no payments expertise; match any parent page's styling seamlessly; run on web, mobile, tablet, Kindle, and set-top, including legacy stacks that could never be modernized; grow for decades without re-integration; support infinite payment methods and workflow variation; function end to end without JavaScript; meet every accessibility standard; survive the politics of teams for whom a shared system was an existential threat; recreate a Retail feature set that took decades to build; achieve zero metric loss against hyper-optimized incumbents; and win adoption purely on merit, because no mandate existed or would ever exist.

The design

After deep analysis the solution became clear, though not easy. Create an abstraction layer between pipelines and the backend services; on top of it, build a widget suite to replace all payments-related experience in every pipeline, accommodating every existing feature in every region on every surface; onboard every pipeline voluntarily; and move to a universal styling architecture with object abstraction so the whole thing could grow consistently for the long term. Every pipeline would then gain the entire breadth of Amazon payment features, and every future feature, with no additional development. Backend services would finally be free to change.

Tenets before pixels

Core tenets ease difficult decisions later and unify the product vision; once established, disagreements can be externalized by matching the issue to the tenet. APX ran on seven: consistent across businesses so payments always feel familiar and safe; encapsulated from the client experience and internally, feature from feature; focused, keeping interaction at the point of attention rather than linking away; extensible across widths, instruments, and features without restructuring; concise, with active prejudice toward simplicity; clear and transparent, so users understand the relationship between their choices and the site's behavior; and stylable but consistent, respectful of each brand without breaking the shared patterns.

APX 101: the widget principles

In addition to the design tenets, I created a simple set of widget principles to help onboard clients, developers, and other designers. Though very simple, I found most confusion was rooted in misunderstanding one of these principles. Starting here provided great value.

Baseline design in the Retail context

I first designed the full spectrum of payment widgets inside Retail Shopping's single-page checkout on desktop as a baseline, then adapted those patterns to the more widely used classic multi-page checkout so a single widget base could serve both pipelines. All clients used a multi-page approach on mobile, which let me consolidate those experiences, and I redesigned the shared payments-management page to use APX widgets throughout. The styling architecture was built in partnership with the new Amazon User Interface (AUI) team: a generic DOM, stylable per client but abstracted so the system could evolve over time. I made that a requirement of the product.

Adoption

The strategy: partner with a medium-sized digital client and solve their specific needs; prove return on investment quickly; use that proof to bring in the other medium digital clients; lay foundations that let small, low-requirement clients onboard immediately; and let concrete ROI fund acceleration and team growth.

Kindle came first, a single purchase pipeline that needed all the basic payment features but was easy to encapsulate. That foundation carried Amazon Video, Music, Audible, Photos, and the Appstore; small clients began seeking us out as the cheaper alternative to custom development; new businesses launched on APX rather than building their own; internal payment products and external subsidiaries like Twitch migrated in. Each new client made the product more capable, and each existing client gained those capabilities without spending anything.

Proving parity

Adoption claims were earned through Amazon's standard experiment dial-up. Each client launch started at roughly 1% of traffic and held there for about six weeks, then stepped up in stages, validating metrics against the incumbent experience at each step. The process ran per client, so stringency varied with each client's risk tolerance. Retail checkout set the hardest bar of the set, zero metric loss against a decades-optimized experience, and APX cleared it.

Widgetizing standalone features

Many payment features with their own standalone teams were integrated directly into Retail Core Shopping with tight coupling. I worked with those teams to encapsulate their features as APX components shared across the ecosystem, multiplying each team's ROI. The Amazon Currency Converter (TFX), originally smeared throughout the Core Shopping payment summary, became a standalone module shared cleanly across desktop and mobile.

Leaning into federation

No matter how large the internal team grew, we would always be either a bottleneck or an obstacle to client roadmaps. Instead of fighting for control, we leaned into the demand, building external development rails that let any team enhance ecosystem functionality with their own resources, or build custom components where they needed full control. I held office hours to review external designs, unify patterns, and keep the long-term vision coherent. The format became a force multiplier.

Those office hours grew into the Payments Experience Bar Raiser program (PXBR), an official program with specific authority over payments design. Once APX reached critical mass, running PXBR became my primary role: reviewing proposed experiences across a very large client base, evangelizing payment patterns, and preventing the proliferation of one-off complexity that chokes federated systems.

The team, eventually

For the first five years I was the sole designer for APX and for every new payment method and feature, domestic and global, juggling 25–30 concurrent projects. After our fifth VP-level reorg, a design organization was funded. Under a new director I helped hire a UX manager and six additional designers, and remained the IC dedicated to APX, running PXBR and providing oversight to the new team while our new designers tackled our new international payment methods and internal projects.

Outcomes

• 99%+of global Amazon payments traffic voluntarily adopted APX, including full adoption by Retail Core Shopping
• 0metric loss against highly optimized incumbent experiences, the adoption bar reluctant clients set
• 1 → ∞every client gained every payment feature, and every future feature, with no additional development
• 4+1 → teamspayments experience grew from 4 developers and 1 designer to multiple large teams with global ownership

What I'd tell you about it now