Crypto for New Account Types

Context

PayPal's Merchant Engineering group runs a set of initiatives aimed at extending crypto capabilities across more of the account ecosystem. I worked on the crypto side of that portfolio. The frontend goal was narrower than "build crypto trading" — PayPal's buy, sell, and transfer crypto flow already existed and worked. The job was to extend that same flow so a specific account type, previously excluded, could use it too, without forking the experience into a parallel implementation.

That distinction shaped everything downstream. The real risk was never in the crypto logic — it was in every place the existing flow quietly assumed the account types it already supported, surfaced across surfaces owned by multiple engineering teams. Integration gaps between those surfaces, not the code changes themselves, were what actually blocked adoption. I led the frontend enablement work and served as the primary technical point of contact for the cross-team investigations that came with it.

The systems involved are covered by confidentiality, so this case study describes the shape of the work rather than its internals — including which account type it was.

Decisions

Validate at the journey level, not the component level. The failure mode here was never inside a single component — it lived between surfaces, in the places the existing flow assumed an account type it had never been extended to. So instead of leaning on unit coverage, I built and validated the buy, sell, and transfer journeys end to end, as the newly-enabled account type specifically, through extensive end-to-end testing. The trade-off is real: E2E suites are slower to run and costlier to maintain. But unit tests cannot see an integration gap; only walking the complete journey — as the account type the flow wasn't built for — exposes where it breaks at a team boundary. The E2E runs became the instrument that found those breaks.

Write the gaps down. When testing surfaced an integration gap, the cheap move is to file a ticket and keep coding. I chose to author gap-analysis documentation instead — mapping what was broken, which team owned it, and what it blocked downstream. Documentation is time not spent writing code, and it decays. But in a multi-team initiative the constraint is not code throughput; it is shared visibility. That documentation improved visibility into cross-team deliverables and accelerated the rollout decision, which was the bottleneck that mattered.

One point of contact over broadcast coordination. Cross-team investigations funneled through me as the primary technical contact. The obvious risk is single-threading — one person becomes the queue. The gain is that platform dependencies got translated once, consistently, into actionable engineering scope, instead of each team re-deriving context from scratch. I kept the role about translation, not gatekeeping: the output was always scoped work another team could pick up without needing me in the room.

Impact

The frontend changes extended PayPal's existing crypto buy, sell, and transfer flow to the account type it had excluded until then — the initiative's core goal. The E2E-validated journeys gave the teams involved a shared, concrete definition of "working" for that account type, which is harder to get than it sounds when a flow crosses several ownership boundaries and was never built with this case in mind. Integration gaps identified through that testing — the places the flow still assumed the old account type — were fixed in coordination with multiple engineering teams rather than discovered later in rollout. And the gap-analysis documentation accelerated the rollout decision by giving the people making that call an accurate picture of what was done, what was blocked, and by whom.

There are no public numbers to attach here; the honest summary is qualitative — a previously-excluded account type unblocked, a decision made faster, fewer surprises at the boundaries.

Stack notes

The flow work is React and TypeScript against an existing crypto surface — deliberate, incremental changes to extend eligibility rather than a rewrite. End-to-end coverage runs on Cypress, treating the buy/sell/transfer journey as the unit under test, for the account type it hadn't been validated against before. A meaningful share of the output was prose, not code: gap analysis and technical documentation written to be read by other teams.

Separately, I evaluated and piloted AI development tools — Cursor and Claude Code — within the team, proposing workflow changes that improved developer productivity and delivery efficiency.