Demo
Portal
See exactly how the payment gateways work — then take the code and build it.
A best-practices demo store that closed the gap between “here’s an API and a reference doc” and “my checkout works” — for a deliberately wide audience of developers and non-technical small-business owners at once. The portal already existed; I owned the design and the enhancement work.
Two audiences, one enormous gap to close.
A reference doc tells you the API exists. It doesn’t show you your checkout working. The portal had to bridge that — for developers who want real code and API detail, and for non-technical small-business owners assembling DIY sites, who need to see it before they trust it.
Want the real code, the API detail, the exact snippet.
Want to see the experience work before they commit to building it.
Anchor everything in a real, browseable store.
The central decision: don’t explain the gateways — demonstrate them. I anchored everything in working demo storefronts (apparel, beauty, a big-box retailer), each with a full home → category → product → cart → shipping → place-order flow, across multiple locales and desktop/mobile views.
Every screen is a real, clickable example — and every one has a way to take the code that makes it work.
Merchant view or developer view — you choose.
A single toggle in the header switched between a Merchant View and a Developer View, with a Static/Sandbox switch and a Customize Demo panel — country, language, integration, product capabilities — so anyone could shape the demo to their own situation before diving in.
Every example, with the exact snippet behind it.
A Get Code action on the live examples handed over the precise integration snippet — REST samples with links straight to the relevant docs. An all-products page organized the integrations into partner and merchant flows, each with documentation, code samples, and a live “See example.”
The right way to build it, tied to the actual UI.
Inline “best practice” callouts sat right on the specific UI they described — on the payments screen, for instance: don’t pre-select a default payment method, keep PayPal as its own separate option, and hide the credit-card fields until a card is chosen. Guidance where the decision is made, not buried in a doc.
The decision that made it concrete also made it extensible.
Because everything was anchored in a demo-store model, PayPal could stand up different demo stores for different needs and gateways on the same underlying approach. The thing that made the gateways learnable also made the portal reusable — one model, many demos.
More engagement, more downloads — and ideas that outlasted me.
The two KPIs were straightforward: increase site visits, and increase downloads of the documentation and integration materials. The redesign increased engagement and resource downloads against both — and the core ideas were still live in the shipped product years later.
Honest caveat: the outcome is confirmed qualitatively — more engagement, more resource downloads — rather than in hard traffic or download figures, which weren’t captured.