Features
Everything here is built
What is not built is at the bottom of this page, named, rather than left for you to discover.
Taking payments
Two ways to be paid, one mechanism underneath
Payment links
Create an invoice with an amount, the token it is paid in and an expiry, and share the link. The checkout shows the exact amount, the token, the address, which network to send on, and a countdown. It updates itself when the payment lands.
Permanent customer addresses
One address per user of yours, keyed on whatever id you already use for them. It does not expire, so they can save it and top up whenever they like. Ask for the same reference twice and you get the same address back — for as long as the network’s contracts stay the same; a contract upgrade issues new addresses, and old ones keep paying you.
Free to issue
An address is computed rather than created. Nothing is deployed on-chain until there is money to move, so handing one to every user who signs up costs nothing, and one that is never paid costs nothing forever.
Paid from anywhere
Any wallet, as an ordinary transfer to an ordinary-looking address — nothing to install, connect or approve. It must be the invoice’s token on the invoice’s network. Exchange withdrawals often arrive short by the exchange’s own fee; set an underpayment tolerance on the invoice if you expect them.
Getting your money
Straight to your wallet, without asking
No withdrawal step
There is nothing to request and no queue to wait in. Funds are collected into the wallet you registered, automatically. Vorixpay cannot send them anywhere else; when they are collected depends on a few rules — small balances are batched within 24 hours, a part-paid invoice waits until it resolves — and the dashboard shows why any balance is waiting.
Gas is ours
Collecting funds costs a transaction, and we pay for it. Transactions are batched so many small balances can be collected economically, and collection waits out a fee spike rather than spending more to move money than it is worth.
You can see where every payment is
Money that has reached your wallet, money that is yours but not yet collected, and money that is on-chain but not yet deep enough to rely on are three different numbers, and the dashboard shows them as three different numbers.
Changing your payout wallet
Signed by the wallet currently registered and submitted only through Vorixpay, then a 24-hour delay you can cancel within. Every change emails you and sends a webhook — which is what makes the delay useful rather than merely slow. While it is pending you keep taking payments and creating invoices; only collection waits, and when the 24 hours are up Vorixpay applies the change and collects everything to the new wallet.
Building on it
Enough to build against without guessing
Webhooks that arrive
A completed invoice and its event are recorded in the same database transaction, so one cannot exist without the other. Every event is signed with HMAC-SHA256 using your webhook secret, carries a sequence number, and is retried on a backoff — up to twelve attempts over about sixteen hours.
Events that say who paid
Payments into a permanent address carry your own reference for the customer, plus any metadata you attached to it. Invoice events carry the invoice’s id and txRef. You never have to keep an address-to-user table on your side.
Honest payment states
Partial payment, overpayment, and money arriving after an invoice expired are each reported distinctly — underpaid and overpaid events, and a completed event marked paidLate — rather than being rounded to "paid" or "not paid". You can also accept a part payment as settled.
REST API and keys
Create invoices, issue addresses, read balances and payment history. Test keys work on test networks; live keys will work once mainnet is up.
Knowing it works
Built to notice when something is wrong
Reconciliation
Checks run every five minutes: a sweep that moved less than expected, a payment credited against an unconfirmed collection, an invoice marked paid without the money, funds nobody can collect. A guarantee nobody verifies is a belief.
Detection that cannot quietly stop
The chain is read block by block against a stored position, so nothing is missed while the service restarts, and a scanner that has stalled is visible rather than looking idle.
Reorg handling
A payment reversed by a chain reorganisation is marked reversed and announced, not silently kept. If it is re-included later it comes back rather than being lost.
Public health endpoint
A status-only check for uptime monitors: one yes-or-no answer — every network being scanned and collected, and no critical reconciliation finding open — with HTTP 503 when the answer is no. It needs no credential, because a monitor that needs one stops working exactly when you need it. The detail behind the answer stays private.
Not built yet
These are real gaps, not roadmap decoration.
Mainnet
Coming soonContracts are deployed on BNB Smart Chain Testnet and Ethereum Sepolia. Mainnet follows an external audit.
Tron
Coming soonThe address derivation and chain adapter are built and tested against live Tron. Contracts are not deployed there yet, and collection needs a model for Tron’s staked resources first.
Subscriptions
Coming soonRecurring on-chain charges. Built but switched off, deliberately set aside so that one-off payments could be finished properly first.