HydrogenPay Invoice

Merchants on HydrogenPay were sending invoices through WhatsApp messages, screenshots of account numbers, and PDFs built in Word. Anything but the platform they already used to move money.

The pattern showed up in three places at once: a recurring line in merchant support tickets asking how to send an invoice from inside the dashboard, a repeated request in the sales team's feature log, and a set of interviews that kept saying the same thing.

Merchants weren't missing an invoicing tool. They had one, they just weren't using ours. Billing was happening in a separate workflow from payment collection, and every invoice sent outside HydrogenPay was a payment we never touched.

I interviewed 15 businesses: five enterprises, five SMEs and five freelancers, expecting requests for more invoice fields. Instead, the friction sat upstream of the invoice itself, and the market split the same way every competitor did: powerful but generic, or local but basic.

• Too complex. 80% called existing tools overkill for a two-minute task.
• More than one inbox. Enterprises needed a single invoice to reach a whole AP team.
• Nothing carried over. Payment terms and notes got re-typed on every invoice.
• Wanted on mobile. 30% asked, since invoicing happened between meetings.
• Needed reminders. Chasing overdue invoices manually had become its own job.

The challenge was building one flow that could carry a freelancer's two-minute invoice and an enterprise's AP-facing workflow, without making the basic task feel like enterprise software.

Nobody had built something simple, scalable and local at once. That changed the brief.

We'd seen the same trade-off everywhere we looked: powerful but complex, or simple but limited. So we kept the core flow short enough for a two-minute invoice, and let the advanced functionality show up only when a larger business reached for it, invisible the rest of the time.

Invoice creation became three steps, each one showing merchants only what mattered at that stage:

1. 1Invoice details: pick a customer, add line items, watch the total build in a live preview.
2. 2Payment details: set the due date and terms, or turn on recurring billing.
3. 3Review & send: address multiple recipients, then send, save as a draft, or fire off a test copy first.

Customers, products and templates became reusable data instead of fields retyped from scratch every time. The invoice should remember what the business already knows.

First run is a blank dashboard with one clear action, not an empty grid merchants have to figure out on their own. Once invoicing is live, the same table shifts toward management: quick actions, download, recall, sitting right in the row, because opening every invoice just to manage it added up fast.

Step one asks only for what's needed to build the line items: a customer, then a set of products or services. Pick a customer and the invoice starts assembling itself in a live preview alongside the form, so merchants watch the actual document take shape instead of trusting a form to translate correctly.

This is the direct answer to the re-typing problem. A returning customer or a repeat service is a search away, not a re-type. Creating a new one doesn't interrupt the invoice either. It opens inline and drops the merchant straight back into the flow.

Tax and discount apply right on the invoice details step, updating the live preview as merchants type. Step two sets the due date and payment terms. Recurring billing stays hidden until a merchant actually needs it: flip it on, and the form expands to frequency and an end condition, instead of showing every subscription option to a freelancer sending a one-off invoice.

This is where the enterprise finding lived directly: a single invoice needed to reach more than one inbox. Review and send lets a merchant address multiple recipients on one invoice, then choose to send, save as a draft, or fire off a test copy to themselves first.

A merchant gets a clear confirmation with a shareable payment link they can drop anywhere, not just an emailed PDF. Their customer lands on a branded page built to get paid, not to explain itself.

Billing created the context. HydrogenPay handled the payment.

Given how much of this happens between meetings, mobile wasn't a cut-down version of the desktop flow. It's the same three steps and the same reusable customer and product data, redesigned around a thumb instead of a cursor, down to the same optimized invoice list.

40% faster invoice creation than the workarounds it replaced

30% fewer invoice errors, from auto-fill and validation

42% of merchants adopted the new flow within four months

7,000+ invoices sent through the tool

₦820M+ in transaction volume processed

2x faster invoice-to-payment cycle than manual invoicing

What started as a pattern in support tickets became one of the more heavily used surfaces in the product, and another way merchants now route payments through HydrogenPay instead of around it.

• Watch for hesitation, not just errors. Every real improvement here came from noticing where a "finished" flow still made someone pause or forget a step, not from a second round of research.
• Reusable data beats a longer form. The customer and product memory did more for adoption than any field we added.
• Enterprise and freelancer needs aren't opposites. Multiple recipients and a two-minute mobile flow shipped from the same three steps, because we kept the core short and let the complexity stay optional.