PayPal Developer Platform
One integration path — from signup to a first successful call.
Overview
The developer platform in one minute
Monthly U.S. developer-portal visits, quarter after launch
Developer adoption vs. the pre-launch baseline
Usage across key developer tools, quarter over quarter
Developers stalled mid-integration because the portal, the documentation and the tooling each described the same task differently, and there was no single path from signup to a first successful call.
- Role
- Senior Product Designer · design lead for the developer portal and documentation experience
- Team
- No direct reports. Two product designers, one content designer, one user researcher, plus product and engineering partners.
- Decision authority
- I decided design direction and recommended IA strategy. Roadmap decisions were made with product; analytics were owned by the platform team.
- Primary users
- Solo integrators through enterprise platform developers, and the SMB merchants they build for.
- Constraints
- A live public surface, an existing merchant base, and a documentation estate that could not be paused during the redesign.
- Duration
- 21 months across research, redesign and rollout
developer.paypal.com is a public surface, but the visuals here are reconstructions and internal analytics and risk detail remain confidential. Reconstruction does not verify the outcomes shown.
Problem and stakes
Developers trusted the brand and distrusted the portal.
PayPal's developer portal was the front door for integrators, but discovery, onboarding and tool adoption were fragmented. Developers churned during integration.
The portal used an outdated design system and fragmented information architecture. Five of eight developers repeatedly left their integration flow to search documentation and described difficulty finding the next required piece of information. The audit also identified significant accessibility and performance problems.
How I learned it
Two journeys, mapped onto one system.
Conducted 30+ longitudinal research sessions over three months with eight developers, in partnership with a user researcher and product manager. The team observed real integration work and conducted follow-up interviews, alongside a competitive teardown of Adyen, Square and Stripe.
Mapped a single SMB × Developer journey to find the seven moments that earn or lose trust: choosing a provider, finding the right doc, generating sandbox keys, the first successful call, wiring webhooks, switching to live, and diagnosing a 500.
Consequential decisions
What I decided, and what it cost.
- 01
Treat integration delay as an information-architecture problem.
Recommended framing the delay as IA rather than a third-party tooling problem, and product redirected the roadmap accordingly.
- 02
Replace documentation-breadth entry with a solution-led entry point.
Pick what you are building, get the right SDK, sandbox and guide on one screen.
Rejected a 'docs-first' homepage proposal — research showed developers wanted recent transactions and error logs at the door, not marketing copy. Defended this against marketing leadership.
- 03
Force a single design system across sandbox and live modes.
Eliminated the 'two dashboards' problem that had been a top-5 developer complaint for two years.
- 01
Redesigned the connected developer experience across onboarding, apps and credentials, testing tools, event logs, webhooks, sandbox/live modes and payment-solution integration guidance.
- 02
Ran open design critiques through the redesign and shared journey-mapping practice with the wider DevX design group.
Shipped experience
One dashboard, one mental model, sandbox to live.
Showreel — walkthrough of the redesigned developer portal.
All screens are reconstructions — no production UI or merchant data. Every image expands.
Outcomes and provenance
What changed on the portal surface.
Monthly U.S. developer-portal visits, quarter after launch
Developer adoption vs. the pre-launch baseline
Usage across key developer tools, quarter over quarter
Webhook usage after the redesign
Webhook-related errors vs. pre-redesign baseline
WCAG 2.1 AA verified by the internal accessibility team across portal surfaces
- 01
In the U.S. market, monthly developer-portal visits increased from a 45K pre-launch baseline to 160K during the quarter after launch.
- 02
Developer adoption approximately doubled from the pre-launch baseline to the quarter after launch, reflected in increased sign-ups and broader use of PayPal's developer-tool ecosystem.
- 03
Usage across key developer tools — including webhooks and error-log surfaces — increased 30%, quarter before vs. quarter after launch. The redesigned webhook experience recorded a separate 37% increase, and webhook-related errors decreased 62% against the pre-redesign baseline.
Portal analytics were owned and reported by the platform team. Figures are rounded, measured on the U.S. portal surface, and are separate from the authorization workstream's results.
Reflection
What I would do differently.
The redesign earned its numbers by treating documentation and dashboard as one product rather than two teams. The part I would sequence differently is accessibility: the audit surfaced problems late enough that remediation competed with launch scope instead of being designed in from the first component.
Splitting the authorization work out was the right call in the room and it is the right call on this page — it has its own users, its own risk surface and its own evidence.
The other PayPal initiative
ML-assisted authorization & decline handling
A separate workstream for U.K. and EU merchants: explaining why a payment declined and what safeguard to apply.
Read that case study