PayPal Link: removing the “did I pay the right person?” fear from P2P payments
How PayPal turned peer-to-peer payments into a shareable link — and how I built the measurement system designed to evaluate its launch.
A summer inside PayPal's P2P team
In summer 2025, I was a Technical Product Manager intern on the P2P (peer-to-peer) Payments team in PayPal's Consumer Group — the team behind sending and requesting money between people. I spent the summer on the run-up to PayPal Link, which launched that September.
P2P doesn't make money — it makes PayPal alive
The team's north-star metric is P2P Total Payment Volume (TPV). P2P carries very low markup — friends-and-family transfers are free, and much of goods-and-services volume carries no fee either — so the team isn't a direct revenue line. Its job is different:
P2P is PayPal's engagement engine. Paying a friend back for dinner is the most frequent, most habitual reason to open the app — it drives daily active users and transaction frequency, which in turn power retention and keep the whole ecosystem warm.
~60% of users quit on one single page
Funnel data showed that approximately 60% of users who entered the P2P flow dropped off at the same step: choosing who to send money to, or request it from. User research surfaced two reasons:
“I can't find them.”
The other person doesn't use PayPal, so search returns no match — a dead end before money can even move.
“Is this really them?”
Plenty of people never set a name or photo on their account — so the match comes back as little more than a phone number. Users can't confirm it's the right person, and they're afraid of paying the wrong one, so they abandon rather than risk it.
1
2
PayPal Link: skip the lookup, share a link
Instead of finding the other person inside PayPal, PayPal Link turns a payment into a shareable link — delivered through the channel where you already know exactly who you're talking to: iMessage, WhatsApp, Messenger, any share sheet.
“I can't find them” → no lookup needed
The link works even for non-PayPal users — they open it on the web and pay or claim the money, expanding P2P beyond the existing user base.
“Is this really them?” → identity by context
You share the link in an existing chat thread with the person — there's no ambiguous match to second-guess.
Two paths, one shared surface
The experience splits into Request (I ask you for money) and Send (I push money to you). Both start from the same entry point and amount screen; the key difference is when the money moves: Send charges the sender at link creation, Request charges the payer when the link is opened and paid.
Screenshots below are from the shipped iOS app (contact details masked for privacy). Screens on the receiving side that couldn't be captured are clearly marked as reconstructed.
Request flow
I request → they pay
Send flow
I send → they claim
Making the launch measurable
A launch without measurement is just a hope. My job was to make sure that on day one, the team could answer: “Is PayPal Link actually working?”
Concretely, I owned the data-readiness workstream for launch:
Define what to measure
Translate product goals into data requirements — the metrics, events, and funnels that prove (or disprove) the product hypothesis.
Build the observation layer
Design and build the post-launch dashboard and prepare the experiment plan used to evaluate whether the launch met expectations.
What I shipped
Three deliverables, in the order they had to happen — each one is the precondition for the next:
Deliverable 1 · Mapping every path a transaction can take
Before any dashboard could be trusted, every possible state of a link had to be enumerated — including the unhappy paths. I mapped the full transaction lifecycle — both flows, every click, and all seven terminal states — so that no money movement could fall outside our tracking:
Each terminal state maps to a tracked event, so the funnel is exhaustive: every created link ends up in exactly one bucket.
Deliverable 2 · The launch metric system: four layers, four questions
Working with data science, I turned “did the launch work?” into a four-layer metric system. Each layer answers exactly one question, in the order a stakeholder would ask them:
Did the feature move the business?
Is the experience healthy — and where does it leak?
What does it contribute beyond P2P?
Did it break or cannibalize anything?
Outcome metrics
Did the feature move the business it was built to move?
| Metric | What it tells us | Formula |
|---|---|---|
| P2P TPV | Total dollar volume of completed P2P transactions — the team's north star. If PayPal Link works, this is where it ultimately shows. | Σ completed P2P transaction amounts, per week / month |
| P2P transaction conversion rate | Of everyone who enters the send/request flow, the share who complete a transaction — the direct counter-metric to the ~60% contact-selection drop-off, the one number this product was built to move. | users completing ≥1 transaction ÷ users entering the send/request flow |
Funnel metrics
Is the experience healthy, is anything hurting it, and is it improving over time? Ordered along the user journey:
| Metric | What it tells us | Formula |
|---|---|---|
| Link penetration | Whether users discover and choose the link path at all — adoption of the feature inside P2P. | link-initiated flows ÷ all P2P flow initiations |
| Creation success rate | Of users who start a link (enter an amount), how many end with a created link — catches both UX friction and technical failures at the review/create step. | links created ÷ link creations started |
| Open rate | Of created links, how many the counterpart actually opens — the step where the journey leaves PayPal's surface and lives in a chat thread. | links opened by counterpart ÷ links created |
| Completion rate | Of created links, how many end paid (Request) or claimed (Send) within the 10-day validity — the single most important funnel number. | links paid or claimed ÷ links created |
| Incomplete % by reason | The complement of completion, split by terminal state — expired · cancelled · disputed · reported. Splitting by reason turns “it didn't complete” into a fixable diagnosis. | links ending in state X ÷ links created |
| Feature retention | Whether creators come back — repeat usage separates real utility from novelty. | creators making a 2nd link within 30 days ÷ first-time creators |
Ecosystem metrics
What does the feature contribute to P2P — and to PayPal as a whole?
| Metric | What it tells us | Formula |
|---|---|---|
| New users activated via link | Non-PayPal counterparts who sign up to pay or claim a link — a growth loop the old contact-based flow could never start. | new accounts whose first PayPal session starts on a link landing page |
| Downstream TPV of link-acquired users | What those new users go on to transact after activation — the compounding, long-term payoff of each cohort. | cumulative TPV of link-acquired cohort, by months since signup |
| Cross-product adoption | Whether link-acquired users become full PayPal users (checkout, balance, card) rather than one-time claimants. | cohort users active in ≥1 non-P2P product within 90 days ÷ cohort size |
Guardrail metrics
A new feature must not damage what already works — or open new risk.
| Metric | What it tells us | Formula |
|---|---|---|
| Platform total TPV | Link volume must be incremental, not cannibalized from existing flows — platform TPV should stay flat-or-up while link TPV grows. | platform-wide TPV vs. pre-launch baseline, alongside classic contact-flow TPV |
| Platform DAU / MAU | Overall engagement shouldn't degrade — the link path should add sessions, not replace richer in-app ones. | DAU, MAU & DAU/MAU stickiness vs. baseline |
| Platform LTV | Long-run user value stays healthy — an early check that link traffic isn't structurally lower-value. | projected lifetime value per user, monitored by acquisition source |
| Dispute / report / fraud rate | A shareable money link is also a new scam surface — risk must stay at classic-P2P levels for the feature to be scalable. | (disputed + reported) link transactions ÷ completed link transactions, vs. classic P2P baseline |
Deliverable 3 · The launch experiment: an A/A/B/B readout
Beyond monitoring, launch success needed a causal answer: did the link entry actually cause the lift? A user-level experiment on one variable — whether the link entry point is shown. Duplicating each arm (A/A/B/B) lets us validate within-group variance before trusting any between-group delta.
| Cell | Experience | Traffic | Duration | Metrics observed |
|---|---|---|---|---|
| A1 | ✓ Link entry point shown | 10% | Not fixed up front — data science sized the traffic needed to detect the minimum significant change. | Identical across all four cells:
P2P TPV Transaction completion rate Completed transaction count |
| A2 | ✓ Link entry point shown | 10% | ||
| B1 | ✕ No link entry point | 10% | ||
| B2 | ✕ No link entry point | 10% |
Each cohort read requires 7 days of exposure + the 10-day link-validity window (17 days) for outcomes to mature; data science separately sized the traffic needed for the experiment. Randomization was stratified separately within Android, web, and iOS.
Rollout
Once the experiment reads positive, the entry point widens in steps — 25% → 50% → 75% → 100%, holding 7 days of observation at each step before going wider.
What I brought to the team
Beyond the launch deliverables, three pieces of work changed how the team measures the product:
One trusted table for a fragmented funnel
The messThe link entry lives on many surfaces — mobile P2P home, search, web home, promo — each logging to a different table for historical reasons. Answering “exposure → click, by source” meant parsing every table and flag: easy to get wrong, easier to miss one.
What I didEnumerated every entry surface with product, engineering and data, and drove a PayPal Link intermediate table with a source field — one starting point tying exposure → click → create → complete. New surfaces get appended as they're found, so coverage only converges.
Why it stuckThe more teams queried it, the more it became the canonical, trusted source — insulated from fragmented upstream data.
Making link-driven signups count
The gapPayPal Link reaches people outside PayPal, so it inevitably drives new activations, signups and KYC. But activation pages belong to the onboarding team — and their attribution only recognized marketing channels (paid, organic). The link's contribution was invisible.
What I didWorked with the onboarding team to add link-source attribution to activation reporting.
Why it matteredThe project's ecosystem contribution became visible and creditable instead of anecdotal — and its influence extended across team boundaries.
Counting the value that outlives the link
The insightThe first link payment creates a relationship — the counterpart then lands in your contact list, and future transfers between you no longer go through a link. Direct link volume structurally undercounts the win.
What I proposedMeasure compound TPV generated by PayPal Link — all subsequent transfer volume between pairs whose relationship started with a link, even after the link itself stops being used.
link-originated relationships → Σ their downstream transfer TPV = compound TPV
What I learned
Data infrastructure is product infrastructure
For a financial product, everything downstream depends on reliably joining users and transactions across scenarios, devices and surfaces. Three levels of identity make every later question answerable:
Get this governance right early, and measurement is a query; get it wrong, and every metric is an archaeology project.
Quantify the compounding value, not just the direct lift
The default lens for a platform project is direct GMV/TPV lift — necessary, but incomplete.
The fuller story is the new users and new relationships a project creates, and the long-run revenue they compound into. That value doesn't show up unless someone deliberately chooses to measure it — and measuring it is how a project earns influence beyond its own quarter.
Screenshots are from the shipped PayPal iOS app, with contact details masked; reconstructed screens are marked. Metrics are approximate and shown for illustration — a personal portfolio, not an official PayPal disclosure.