They open the link
No account, no signup, no wallet connection, no extension. A page with your name on it, the invoice reference and the exact amount expected.
Universal payment account
The payment page
Routing & normalisation
Routing & execution
Local currency settlement
Reconciliation & records
Platform & embedded accounts
Solutions
One link. Your client pays in a minute.
You send one line. Your client opens a page, taps what they hold, and gets a single destination — one address, one network, the exact amount and an expiry. They never type an account reference into a wallet, and they are never handed a menu of everything we can accept.
Try it. Tap what you hold.
This is the sheet your client’s browser raises over the page they are already on — on our origin, in a frame the merchant’s own code cannot read. They tap what they hold and get one destination — one address, one network, the exact amount — not a list of everything we can take. Tap “Something else” to see what a refusal looks like. Leave it alone and it plays through what happens when the money arrives.
See a state you would not normally catch:
Illustrative throughout. The addresses are shaped like real ones but encode nothing, and the code is a placeholder.
What you send
One line, and it never changes.
Put it in the invoice, the email, the contract, the statement of work. It works for every client and every invoice you will ever raise.
In your invoice
Please pay invoice INV‑1034 to Nomapay account NP‑847291
Or send the link directly: pay.nomapay.co/NP‑847291/INV‑103401
02
They tap what they hold
The page asks, rather than presenting a menu. One tap produces one destination, with the network named in full at the point of copying.
03
They send, and watch
The page reports what is actually happening — detected, screened, matched to your invoice, settled — rather than going quiet after the send.
Why it cannot go wrong the usual way
One address. One network. Nothing else.
A payer’s wallet has to know an address and a network — no design hides that, and anyone claiming otherwise is describing something that does not work. Everything else is concealable, and that is the part that matters.
What the payer sees
One destination
The address, the network it sits on, the exact amount and the expiry. Enough to pay you, and nothing more.
What stays concealed
Everything after the money lands
The full set of assets and networks we accept, which partner issued the address, which route the funds take afterwards, and who converts them at what cost. A payer reading an address learns none of it, and neither does anyone watching a block explorer.
If your client holds something we cannot take, the page says what it needs and stops — this invoice can be paid in USDC or USDT, please contact them to arrange another method. That reveals a boundary, not a capability list. The failure mode of a payment arriving somewhere unusable is still removed, because an address for that network was never issued and never shown.
The other side of the payment
Getting paid is easier when paying you is easy.
Paying a business in another country is not only awkward for you. It is awkward for the person paying — and when their finance team baulks, you are the one who loses the payment. Most of what this page does is aimed at them.
A raw address in an email looks like a fraud attempt
To a compliance officer, a 42-character string pasted into a thread is exactly what they are trained to stop. A page with your name on it, an invoice reference and a stated amount is something they can approve.
A transaction hash is not a record
Their books need more than a block explorer link. They get a remittance advice: who paid, what for, how much, on what date, against which invoice — in a form an auditor will accept.
Nothing to install, no account to open
No wallet connection, no extension, no signup. If paying you requires your client to create an account somewhere, some of them simply will not.
The next time, it is the same line
Your account reference does not change, so the second payment is the first one again. Anything that would speed it up further is offered afterwards and is entirely optional.
We will never put a wall in front of a payment. Your client does not have to verify anything, register anything or agree to anything before they can pay you. If we ever offer them something that makes future payments quicker, it will come after a payment has already gone through, and declining it will cost them nothing. A business should not lose an invoice because its customer hit a form.
When the amount is not exact
Four things that actually happen, and what we do.
Real payments are messy. None of these become a silent settlement or a silent hold — each one becomes a decision that belongs to you.
It lands short
Matched to the invoice and flagged with the variance. You accept it or query it with your client. We will not quietly settle a payment that does not match what you expected.
It lands over
Matched, with the excess flagged and held as a question for you rather than absorbed.
It arrives in parts
Two or more payments against one invoice are aggregated. We settle when the invoice is satisfied, and show you the partial position until then.
It arrives twice
A second full payment against an invoice already matched is flagged immediately. It is never settled twice on the assumption that it was meant.
The reference
Small details that stop large problems.
An account reference is going to be typed by hand, read over a phone, and pasted into an email by somebody who is not concentrating. It is designed for that.
It carries a check digit
A mistyped reference fails loudly on the payment page rather than quietly resolving to somebody else’s account.
It is never reused
A closed account’s reference is retired permanently. It will not be handed to a later customer.
It is not sequential
You cannot infer another business’s reference from your own, or count how many customers we have.
Case does not matter
Typed in lower case it still resolves. It is shown back in one canonical form.
The boundary
We know which address belongs to you. We cannot move anything from it.
The addresses behind your account are issued and controlled by a licensed or authorised custody partner under their own permissions. Nomapay observes, screens, attributes, instructs and records. It never holds a key, not even for the moment a transfer takes.
How addresses are allocated behind the account is our own engineering and we do not publish it. What we will state plainly is the part that affects you: Nomapay holds no customer assets, on-chain or in fiat, and does not operate a bridge.
Would you send this to a client?
That is the question the whole product turns on. Tell us what would stop you — the wording, the rails, the amount of crypto a client still has to understand.