Pay anyone

We designed a way for our members to send money to people outside of Current

Role

Lead designer
Interaction designer
UX research
Visual designer
Prototyping

Platform

Desktop web
Mobile web
iOS
Android

Timeline

Q2 2025
Two Sprints

Why we built this

Current’s users could only send money to other Current members. We realized this created real friction for users whose contacts weren’t on the platform. We knew many of our users, for example, paid their rent with similar tools p2p payments. I was tasked with designing an experience that allowed Current members to pay anyone outside the platform using their phone number.

Old experience

Working with a technical constraint

A key technical constraint was that we couldn’t send money directly to a non Current user. At least not for MVP. Instead, the sender would generate a payment link that the recipient had to claim. The funds would be held in a pending state to ensure the sender wouldn’t spend the money until it was claimed.

This created a mental model problem. Most people think of sending money as a single action – you send, they receive. Our flow required two parties to complete two separate actions, with the sender responsible for delivering the link themselves.

First test failed (but we learned quickly)

What worked

I designed a custom handoff screen that included a clear payment link, plain language about the pending state, and one CTA to confirm the link had been shared. I also scrapped the share sheet.

I tested again and it worked! All participants completed the flow and the majority marked the task a 5 out of 5 in ease (very easy).

What worked

I designed a custom handoff screen that included a clear payment link, plain language about the pending state, and one CTA to confirm the link had been shared. I also scrapped the share sheet.

I tested again and it worked! All participants completed the flow and the majority marked the task a 5 out of 5 in ease (very easy).

What worked

I designed a custom handoff screen that included a clear payment link, plain language about the pending state, and one CTA to confirm the link had been shared. I also scrapped the share sheet.

I tested again and it worked! All participants completed the flow and the majority marked the task a 5 out of 5 in ease (very easy).

Designing the recipient flow

After designing the sender experience I moved on to the recipient flow. I designed the full claim flow on web, accessible on both mobile and desktop, so recipients could receive money without having to download the app or creating an account.

After launch…

I built a UX metrics dashboard in Amplitude to understand if there were any friction points across any of the steps. I focused on high stake areas like the contact search and the review screen. I was surprised to see it was taking users an average of 13 seconds to find and select a contact. The industry benchmark for a step like this was 4 to 6 seconds in apps like Cash App and Venmo.


Separately I was aware of a backend bug that had been flagged. We weren't showing users an exact match and instead of getting one result they would see a list. I knew this was part of the issue but I audited the UX and UI anyway and saw some areas I could improve on.


The horizontal carousel with the vertical list was generating unnecessary cognitive load. Also Recent contacts was a legitimately useful section and it was hidden inside a carousel. We had recently began exploring card treatments for some of our buttons but in this case it was taking up way too much real estate.


With some minimal UI tweaks in the contact search screen I took the contact search and selection time down from 13s to 6s.

After launch…

I built a UX metrics dashboard in Amplitude to understand if there were any friction points across any of the steps. I focused on high stake areas like the contact search and the review screen. I was surprised to see it was taking users an average of 13 seconds to find and select a contact. The industry benchmark for a step like this was 4 to 6 seconds in apps like Cash App and Venmo.


Separately I was aware of a backend bug that had been flagged. We weren't showing users an exact match and instead of getting one result they would see a list. I knew this was part of the issue but I audited the UX and UI anyway and saw some areas I could improve on.


The horizontal carousel with the vertical list was generating unnecessary cognitive load. Also Recent contacts was a legitimately useful section and it was hidden inside a carousel. We had recently began exploring card treatments for some of our buttons but in this case it was taking up way too much real estate.


With some minimal UI tweaks in the contact search screen I took the contact search and selection time down from 13s to 6s.

What I learned

Pay anyone made me hold two different mental models simultaneously, a Current user sending money from the app, and a stranger receiving a link they might not have been expecting.


In addition, I also had the opportunity to solve an interesting design challenge created by a technical constraint. We had to brainstorm, test, iterate, and do it quickly to move find a solution that made it clear for the sender that this was a slightly mental model than what they were used to with other p2p.


We "failed" but learnt quickly and created something that really worked.