Jonathan Simcoe

Software designer in Portland, OR

Aug 3, 2022
Mercury

Payment Requests

On August 3, 2022, we launched Payment Requests, a simple way for Mercury customers to request money from anyone. A customer enters an amount and shares a payment link, either directly or by email. The payer does not need a Mercury account.

I led the design end-to-end, shaping the product and the decisions that let us ship without Stripe or additional ACH rails. That narrow first release gave us room to learn broadly before expanding the idea into products like SAFEs by Mercury.

Payment Requests intro: the request link, payer-facing payment page, and request timeline

The constraint

To work with nearly any bank, the public payment page had to show the recipient's account and routing numbers. On paper, that reads like a bug: the exact information a customer would hesitate to put on a shareable page.

Instead of fighting it, we embraced it. Secure auto-routing accounts under the hood keep funds routed and protected, while the public link maximizes ease of access. The constraint became the feature: anyone can pay you, from anywhere, with nothing to install and no account to create.

The public-facing Payment Request URL, from "Magical constraints (or How to turn bugs into features)"

Start with the simple premise

Our design principle was simple: start with the request for money, not with a full invoicing system. Research showed that customers were eager for things like full invoicing, credit card and ACH payment rails, and more — but we also knew the feature needed to maintain open-ended flexibility.

So we shipped the smallest version that could work: an amount, a payment link, and an optional email. Nothing more.

What customers did with it

By starting simple, we watched the feature get pulled in directions we never planned. Founders used payment links to collect funds from SAFE investors. Others sent invoice requests. Some companies even requested — and sent — money to themselves.

Those unexpected uses became the real roadmap. The SAFE behavior, in particular, helped inform the product that later shipped as SAFEs by Mercury.

Impact

Payment Requests proved that a narrow payment primitive could unlock uses we had not planned. Shipping without a full invoicing system or additional payment rails let us learn from real behavior, and founders' use of payment links to collect SAFE investments helped lead to SAFEs by Mercury.

This case study draws on my launch notes and my essay Magical constraints (or How to turn bugs into features) — on embracing constraints until they become the product.