PayPal World: one writer, one network, every audience

How I became the only documentation owner for a brand-new cross-border payments network, and what I built for its developers, admins, operations teams and partners.

Context

PayPal World is a cross-border interoperability network for digital wallets. It connects participants such as NPCI (the organisation behind UPI), PayPal, M-Pesa in Kenya, Mercado Pago in Latin America and WeChat Pay in China. Customers of one wallet can pay and send money through another.

That makes it unusual to document. Every participant is a large, regulated payments company with its own systems, compliance needs and expectations. The documentation isn’t a nice-to-have. It’s how participants learn to connect to the network at all.

The challenge

When I joined, the product was new, and so was the domain for me. I had to get up to speed on three things at once:

1. Finance: how cross-border settlement, FX and disputes work between wallets.
2. Regulation: what Legal, Compliance and Risk need the docs to say, and not say.
3. Technology: the APIs, authentication flows and portals participants use.

On top of that, the audience isn’t one reader. It’s at least four:

• Developers at participant companies integrating the APIs
• Admins configuring their organisation in the Participant Portal
• Internal ops teams handling disputes, settlements and monitoring
• Partner business teams who need clear, legally reviewed communications

What I did

1. Ramped up fast, then became the owner

I learned the financial, regulatory and technical basics quickly enough to become the product’s sole documentation owner soon after joining. My method was simple: read everything, draw the flows myself, and bring engineers specific questions instead of “Can you explain X?”

2. Documented the developer surface end to end

• About 25 API endpoints, each with descriptions, parameters and working examples. I tested every one in Postman before writing it up, then validated it with the engineers who built it and the QA team who tested it.
• OAuth 2.0 and API key management. Security flows are where vague docs become incidents, so these got extra review.
• Close to 20 integration guides, one for each participant use case, so a wallet only reads the path that applies to it.

3. Documented the admin and operations surfaces

• User guides for the Admin Portal and the Participant Portal
• Configuration management guides that participants must complete to onboard onto the network
• Dispute guidelines and dispute documentation
• SOPs for internal business operations teams covering disputes, settlements, transaction monitoring and fraud monitoring

4. Helped shape the rules, not just describe them

I worked with the network rules team to help frame the rules governing the PayPal World network, the obligations every participant agrees to. Writing rules that are legally precise and readable is a special kind of fun.

5. Wrote to partners

I wrote around 30 partner-facing emails from scratch, working with Design, Legal, Compliance and external partner implementation teams. When your reader is a payments company on another continent, every sentence gets a legal review, so each one has to be worth it.

6. Scaled myself

A team of one can’t review every line engineers write. So I:

• Created and own the documentation style guide every PayPal World developer follows (see an excerpt)
• Built custom Cursor rules so developers produce consistent, well-structured docs when documenting a new endpoint (see an example)
• Use Claude Code and Codex to speed up drafting, review and publishing (how I use AI)

How the work flows

Spec or feature ─▶ Test in Postman ─▶ Draft in VS Code/Cursor ─▶ PR review (Eng + QA)
                                                                      │
          Stoplight portal (participant-only) ◀── Merge ◀─────────────┘
          Bugs and portal issues ─▶ Jira, tracked with engineering

I work independently, with support from the Director of Product Management for PayPal World. I collaborate daily with eight product managers and engineers of every seniority level in San Jose, Chicago, Singapore and India. A short weekly intake call with each PM tells me what’s upcoming, in development, in testing and releasing, so every doc is reviewed and published with its release. (How I run it →)

Outcome

• The documentation supported PayPal World’s public launch and directly enabled participant integration.
• One consistent style across API references, guides, SOPs and partner communications, enforced by a style guide and tooling rather than heroics.
• A docs-as-code pipeline that takes changes from draft to published quickly.

What I learned

In payments, a single ambiguous sentence can become a support ticket, a failed settlement or a compliance finding. Precision isn’t a style preference. It’s the product.

I also learned that a sole writer’s best lever is systems, not hours: a style guide, rules in developers’ editors, and a review loop with QA mean quality scales past what one person could check by hand.

© 2026 Akaash Amalraj · Built with Astro, written by a human, reviewed by a style guide. · llms.txt