Before asking a client to change how they pay

When I think about a product for getting paid, I try to start with the person receiving the invoice. They have their bank, an approval process and other work to do. Our product takes up a very small part of their day.

On the building side, it is easy to get excited about a new route, network or integration. On the other side, there is a much simpler question: what do I need to do to pay this invoice and get back to work?

That feels like a useful place to start designing.

Changing how we get paid can give the client more work. Adding another beneficiary. Asking the finance team for approval. Figuring out a different currency. Checking whether the name on screen belongs to the company on the invoice. Each step needs a reason to exist.

Before adding a payment option, I would put the invoice and its instructions in front of someone who does not know the product. Ask them to point out what they would copy into their banking app. Avoid explaining anything during the exercise. The questions they ask are design work we still need to do.

There are five details I would want to make clear:

• Beneficiary: the exact name to use, taken from the verified instructions for that route. If it differs from the trading name, explain the relationship.
• Destination: the details required for the selected method, with labels the buyer recognises.
• Currency and amount: how much to send and in which currency. If conversion is involved, where it is confirmed.
• Reference: the text needed to identify the invoice, visibly separated from other numbers.
• Expected cost: which charges we know about, who bears them, and which costs only the buyer's bank or provider can confirm.

The name deserves particular care. The European Payments Council's Verification of Payee scheme provides for checking the IBAN together with the beneficiary name for SEPA transfers. That is a specific check within that scheme, rather than a description of every payment route. European Payments Council.

The reference deserves attention too. Stripe's documentation explains how a transfer reference can help its invoice system associate a payment with the relevant invoice. It is a useful example of why that field should make sense before someone sends the money. Stripe: invoices and bank transfers.

Then I would look at the options. A route can fit our architecture well and fit the buyer's working day badly. If it requires another account, another approval or a new process, I want to be able to explain what that person gets in return. Sometimes the change will be worth it. Sometimes we will need to simplify it.

I would also include a recognisable contact for questions before payment. If the instructions change, the buyer needs a way to confirm the change through a channel they already know. A well-designed invoice does not settle that issue on its own.

I want to build products that respect the time of people on both sides. We can spend a long time discussing infrastructure, but improving the instructions on an invoice is product work too. If the client needs fewer explanations to do their job properly, that is worth working on.

In the end, what matters is building. And that includes thinking about the person who has no intention of learning how our system works.

If your company would like to learn about Bennu, which I co-founded, you can request an invitation. Access is subject to review and eligibility.