Turning a cost into revenue
Replacing a third-party credit card provider with an in-house product, so Circula could win deals it was losing, end the two-app shuffle for customers, and turn cards into a revenue stream.
By mid of 2026 we processed 1.2M+ credit card expenses.
Start-to-end ownership
Three problems, one root cause
Circula offered credit cards through Pliant, a third-party provider with its own app. The integration worked, but as we moved upmarket the setup created three compounding problems:
Losing deals. Mid-market companies with existing card workflows didn't want to adopt a separate tool.
Two apps, one task. Employees managed cards in Pliant but submitted expenses in Circula.
Ambiguous ownership. When something went wrong, customers didn't know who to contact.
Switching providers would have solved none of this — the third party itself was the problem. Building in-house meant one experience across cards and expenses, clear support ownership, and a new revenue line: Circula earning on cards issued and on transactions processed.
What MVP success meant for us
Replace the third-party setup with an in-house product that customers would actually migrate to — proving Circula could own the credit card experience end to end, and turn it into a new revenue stream.
Making decisions that shaped the product...
Picking the boring, but full coverage
Before users could see card details, we needed a second factor of authentication. The options were SMS, email, and biometric. The engineering team had a strong preference for biometric — it's fast and feels premium. I raised concerns about going straight to biometric, and we worked through the trade-offs together. The question came down to which method would actually work for every user on day one.
Biometric. Fast and secure, but only if you have a recent personal phone.
Email. Works for everyone, but needs an internet connection.
SMS. The least exciting option, but accessible to all users.
We landed on SMS for the MVP. My concern was that auth has to work for the worst-equipped, worst-connected user in our base — not the best-case one. A 2FA flow that fails for a slice of users isn't a security feature, it's a support ticket. Biometric stayed on the roadmap as a future addition, layered on top of SMS rather than replacing it.
Separate fields per digit. Simpler dev option is one combined input, but a 4 or 6-digit code look the same in a single field. Separate fields make the expected length obvious.
OS autofill enabled. Closes most of the gap between SMS and biometric on perceived speed.
A 1-second green success state on the fields. Without it users hesitated after the last digit, unsure if it had worked. The success state removed that hesitation.
Designing for mobile experience
On the web app, card details (number, expiry, CVV) were displayed as an overlay on top of the credit card image. When we got to mobile, the expectation from PM and engineering was to mirror the web pattern — same component, smaller screen. I raised a concern about whether it would hold up at that size.
The pattern works on web because there's room. The card sits big on a wide screen, and the details have space to breathe on top of it. On mobile, the same composition forces the text small enough that it becomes hard to read — and reading and copying these details is the entire reason users are on this screen. Getting it slightly wrong means a failed transaction.
Mirror the web pattern. Lowest dev effort, design consistency across platforms. Trades off the thing the screen actually exists to do.
Show details on a separate screen. Plenty of room, but adds a navigation step and feels heavier than the action warrants.
Show details in a bottom sheet after 2FA. Big type, room for explicit copy actions, and dismissible with a swipe. Stays in the same context — card view behind it.
We went with the bottom sheet. Once users passed 2FA, the sheet slid up with each detail at a readable size and a copy action beside it. The card stayed visible in the background, so context wasn't lost. The pattern intentionally broke consistency with web — because matching web here would have meant a screen that didn't do its job, and harm to user experience.
When simplicity is the wrong call
Most of the cardholder flows were designed around simplicity — fewer steps, less friction, get out of the user's way. Terminate card was the exception. It's a final-call action: once a card is terminated, it can't be undone. Getting it slightly wrong means the user loses access to a card they didn't mean to lose, and a company has to issue a replacement.
Terminate immediately after the reason selection. The simplest flow — user picks a reason, card is terminated. Matches the rest of the cardholder patterns, no extra screens.
Snack message with an Undo action. Quick to action, recoverable within a few seconds. A real option, but a bigger investment than the moment justified.
A confirmation screen after the reason selection. One extra step. The user sees the specific card they're about to terminate and a clear final CTA before the action goes through.
We went with the confirmation screen, and I tested both versions to be sure. The flow without confirmation felt too abrupt to testers for the level of risk — selecting a reason and having the card terminated in the same breath created visible discomfort. With the confirmation screen, testers slowed down, checked the card, and acted with more certainty. They weren't moving faster, but they were moving with less anxiety.
Business impact
The MVP launched in end of 2023, and the product has been growing steadily since. A few numbers from the dashboard as of mid of 2026: