How we name things: the words behind our statuses, buttons and errors

Most payment software speaks the same dialect. Orders are "pending", then "processing", then "completed". Buttons say "Submit" and "Continue". Errors say "Something went wrong". The words are safe, familiar and almost entirely uninformative.

When we rebuilt this site, we rewrote nearly every label. Not to be clever, but for one reason. A status should answer the only question a worried customer has: who is holding the next move? This note walks through the names we chose and the reasoning behind them.

The problem with "pending"

"Pending" tells you that something has not finished. It does not tell you whether you need to act, whether we need to act, or whether everyone is waiting for a blockchain. A customer staring at "pending" for an hour has no idea whether to wait, pay again or write to support.

So our first rule was simple: every status should make it obvious who acts next.

Order statuses

An order on our site moves through a small set of states. Their names are:

• Waiting on payment: the next move is yours; the order exists, and we are waiting for your transfer or checkout.
• On the desk: the payment is in, and a person on our team is checking it.
• Paid · card being made: the check passed, and the card is being issued.
• Second look needed: something did not match, such as an amount or a network, and we are looking again before deciding.
• Card issued: the card exists and is yours.
• Not approved: we turned the order down, with a reason you can read.
• Lapsed: an online checkout that was never paid or was abandoned.

Each one names a situation in plain words, and most of them say who holds it. The process page shows the steps behind them.

Card statuses

Cards needed fewer words. A card is Live, Frozen or Closed. We avoided "active" and "inactive" because "inactive" could mean unused, expired or blocked. "Frozen" says the card exists but cannot spend for now, which invites the right question: why, and what happens next? The help center answers it.

Refunds and tickets

Refunds are Being reviewed, Paid out or Not approved. Tickets are With the desk, Replied or Solved. "With the desk" took a few attempts. "Open" was ambiguous, and "Awaiting response" did not say whose response. The desk is where our team sits; if your ticket is with the desk, we owe you an answer.

Buttons that say what they do

A button is a promise about what happens when you press it. We try to name the outcome, not the mechanism:

• Open my account instead of "Submit" on the sign-up form;
• Send a fresh link instead of "Resend" when a confirmation email went missing;
• Ask the provider again on a hosted-checkout order that still shows as waiting, which tells you exactly what the button does.

Where a step cannot be undone, we try to say so before you press anything.

Error pages

Error pages are written for someone who has just been stopped. We gave each one a short headline and a sentence that says what happened and what to do next. A page not found reads "This page went to press without us." A form that expired reads "This page sat out too long." followed by "Go back, refresh, and send it again." A server error says it is already in our logs, and asks you to write if it keeps happening.

The tone is light, but every page ends with a concrete next step. A joke without a next step would just be a second problem.

Words we avoid

Some words never appear in our interface because we cannot stand behind them:

• instant, because a person checks every order;
• guaranteed, because merchants decide whether to accept a card;
• safe as a bare promise, because security is a practice, not a property;
• pending, for the reasons above.

We wrote about why absolute words deserve suspicion in what an honest fee page looks like, and the same logic applies to labels.

Naming as design

Naming turned out to be one of the most effective design decisions we made. A clear status saves a support message. A precise button prevents a mistaken payment. A useful error page turns a dead end into a detour. None of it needs a new feature; it only needs someone to ask, for each word, what a customer will understand by it.

Our earlier note, why there are no star ratings, comes from the same place: say only what can be checked.

Emails speak the same language

The emails we send use the same words as the screens. When an order is turned down, the subject line says the order could not go ahead, and the message gives the reason in a line that begins "The reason:". When a card is issued, the email calls it issued, just as the order page does. A customer moving between the inbox and the app should never have to wonder whether two different words describe the same event.

Numbers with a name

On cards and in the account timeline, numbers are introduced with the sign Nº, the old abbreviation for "number" used in indexes and magazines. It is a small typographic choice with a practical side: it marks a figure as a reference to one specific thing, an order or a card, rather than an amount of money. In a payments app, keeping references and amounts visually distinct is one more way to prevent a misreading.

When a name fails

Some names will turn out to be wrong. The signal is simple: the same question keeps arriving in support tickets. If several people ask what a status means, the status is not doing its job, and the fix belongs in the interface rather than in a longer answer. We would rather change one word on a screen than explain it a hundred times in replies. Names are cheap to change and expensive to leave confusing.

Questions people ask

Why not use the standard words everyone knows?

Because they are familiar without being informative. A status should tell you what is happening and who acts next.

What should I do if my order says "Second look needed"?

Nothing at first; we are checking. If we need anything from you, we will ask by email and in the app.

Why does a refund say "Being reviewed" rather than "Pending"?

Because a person is reviewing it. The label says what is actually happening.