Card numbers were showing up in email

I led research and design for virtual cards in One AP, American Express’s accounts payable platform for small and mid-sized businesses. What we found changed how every card is made, sent, and used.

Role: Senior product designer
Timeline: 2022–2024
Team: New Product Development

On this page

Before: an email from a company’s CFO to a supplier, with a virtual card’s number, expiry date, and security code typed into the body. — How a card reached the person being paid, before and after.

How a card reached the person being paid, before and after.

A small feature people kept using

One AP automates accounts payable for small and mid-sized businesses. It captures invoices, routes them for approval, and pays suppliers.

We knew our volume, but not how people actually used the product. I helped set up product analytics to find out, and one thing stood out. Virtual cards, a minor feature, were getting far more use than we expected. We didn’t know why.

What people were really doing

I led interviews with the admins using them. They were paying suppliers with virtual cards, and the feature couldn’t keep up. They wanted cards they could use once, use until the balance ran out, or reload, with start and end dates, and a way to give a card to a person or a team.

Four video-call stills from customer interviews, each stamped with a date in May 2023. — Customer interviews, May 2023. Shared with their permission.

We also found a trust gap. The people receiving a card had nowhere to check its details or balance, so admins typed card numbers into emails by hand. That put card data at risk, and it looked unprofessional to the suppliers being paid.

Giving every card an owner

The change that unlocked the rest was letting a card belong to a person. Once a card had an owner, we could send it to them securely, give them a place to see it, and show who used it. Admins also got controls on every card: single-use, multi-use, or reloadable, and the dates it’s valid.

Before: the Create a Virtual Card dialog asks only for a card title, a pay-from account, and an amount. — Creating a card, before and after. Each card now has an owner, a type, and the dates it can be used.

Creating a card, before and after. Each card now has an owner, a type, and the dates it can be used.

When we brought the design to compliance, they were glad to see it. The new controls closed gaps in the product’s permissions, where a card could be misused in ways that were hard to trace.

Designing for the person being paid

Card owners were a new kind of user in One AP. I designed their onboarding, their sign-in and phone verification, and the screens where they see and manage their cards. Then I tested each piece with admins and recipients over several rounds.

Much of the work was in the edge cases: a card that’s frozen, cancelled, or expired, a phone number the recipient doesn’t recognize, and roles that decide who on a team can do what.

A collage of One AP screens: a recipient’s My Cards page with a card carousel, card details, and recent transactions; the card type step with a walkthrough of each type; the admin Users table with roles and statuses; a card summary; and the phone verification screen a recipient sees before their cards. — The recipient’s side of One AP, and the admin screens that support it.

The recipient’s side of One AP, and the admin screens that support it.

What it became

All of it shipped. It grew into One AP’s program for issuing cards on demand, which became the core of the product. I led the research and design end to end, and I worked closely with our PM and engineers to ship it.

What I’d do differently

I’d bring compliance in at the start. We went to them once the design was far along, and they knew exactly where the product could be misused. That would have shaped the work sooner.

When people build their own workaround, like typing a card number into an email, the product is telling you what it’s missing.

I’m happy to walk you through this project in more detail. Email me.