All work
Purse · 2025 — 4 months

Payment link

A builder that lets support teams create and send a payment link themselves, without going through the API.

Purse — payment link builder
Role
Sole Product Designer: benchmark, research, UI, design strategy, handoff
Team
PM, frontend, head of support
Users
Support and customer service teams
Scope
Link builder, preview, hosted payment page, data table
In short

When a customer couldn’t pay on the site, support had nothing to offer, and the only workaround went through the API. The defined need was to generate a link. I pushed further: a preview before sending, which the PMs saw as unnecessary and which users now name as the feature that makes the difference.

  • −80%payment link tickets (25 to 30 a month before)
  • 55links created per month per client on average, no engineer needed
  • +10%revenue, from recovered payments
Context

No way to get paid off the website

Purse could only take a payment inside the merchant’s own checkout, in real time. Any other situation, whether a phone order, a failed card or an invoice settled two days later, had no path at all. Support teams were the ones absorbing it.

The problem

There was no way to generate a payment request and let a customer pay asynchronously, outside the website.

  • The only workaround was an API call, so support depended on a developer for each case.
  • Manual API use produced malformed links, which came straight back as tickets.
  • Revenue simply dropped when a customer couldn’t complete a payment at that moment.
How I worked

Designing for the person on the phone

  1. Benchmark

    Other providers offer links, but agents send them blind. None shows what the customer will receive.

  2. User interviews

    Sitting with support agents during live calls. Their fear wasn’t creating the link, it was sending the customer a mistake.

  3. Usability tests

    The builder tested on real cases, timing how long a link took to send. The preview reassured agents right before sending.

  4. Handoff

    States, edge cases and expiry rules delivered as design system components.

Trade-offs

The calls that shaped the product

Should agents see the link before sending it?

A preview before sending

I added a preview of the payment page exactly as the customer will see it: amount, reference, expiry. Agents check before sending, instead of finding the mistake in a ticket.

What settled it: the competitor analysis, where no one offered it, and the interviews, where the fear of a mistake came up in every session.

Not this: Generation only, as the initial need said: faster to ship, without the reassurance that makes people choose our tool over the API.

Who creates the link?

UI first, API second

Every field has a sensible default, so the shortest path is the amount, then send.

What settled it: the link has to go out during the call, sent by the person talking to the customer.

Not this: API only, with documentation: the cheapest option, and the one already causing the bugs and tickets we wanted gone.

What can an agent change?

A closed set of customisations

Agents change what relates to the payment: amount, reference, expiry, message. Branding stays locked to the merchant account.

What settled it: an off-brand payment page worries the customer at the worst moment, the moment of paying.

Not this: A free-form editor, which would have multiplied broken or off-brand payment pages.

Convince

Defending a feature seen as unnecessary

For the PMs, the preview was pointless: the defined need was to generate a link, not to show it. I answered with the market analysis and the interviews: no competitor offered it, and every agent dreaded sending a mistake.

Beyond the feature, I proposed a design strategy built on stickiness: make our UI more useful than an API call, so clients go through our product. It matched the company’s product and tech strategy, and that is what won the decision.

What users say

  • The preview is what makes the difference. I know exactly what my customer will receive.

    Support agent

  • With the preview, there’s no reason left to go through the API.

    Head of support

Outcome: the preview shipped, and users name it as the reason they use our product rather than the API.

Impact

Support sends links without engineers

Payment links went from a favour engineers did to a support action. Link tickets dropped from 25 to 30 a month to about 5. Each client creates 55 links a month on average, and part of the revenue that used to disappear after a failed payment is now collected a day or two later.

The revenue figure was reconstructed after launch, since the builder wasn’t instrumented from day one.

  • Payment link tickets−80%
  • Links created per month per client55
  • Revenue, from recovered payments+10%
What I took away

The cheapest support improvement was not a better help centre. It was handing the tool to the person already speaking to the customer.

What I would do differently: instrument the builder from day one. We measured the ticket drop, but we reconstructed the revenue side after the fact.