xPay Business · for merchants
Collect from your
customers’ banks.
One integration covers online checkout, pay-by-link, QR at the counter and scheduled collections. xPay picks the instrument per payment — a mandate against the customer’s bank where it can, a card where the answer has to come back now.
What you can take
Four ways in, one set of credentials.
You integrate once against xPay’s API. You do not choose a rail, and you never touch our provider’s credentials — the instrument used is on the transaction record for reconciliation, and that is where it belongs.
Online checkout
Server-to-server through the API, or an xPay-hosted page if you would rather write nothing. The customer authorises in the xPay app and your platform gets an authorisation callback immediately.
Pay-by-link
A link per invoice, generated on demand. Send it however you already reach the customer — it opens the same authorisation the checkout does.
QR at the counter
Static codes per till or dynamic codes per sale. The customer scans, authorises, and the terminal shows a confirmed result in seconds, because this one is routed to card.
Recurring collections
Plans, schedules and event-driven collection against a mandate the customer already authorised. No expiry churn, and nothing for them to do each month.
The routing rule
The cheap instrument by default. The fast one where speed decides.
A mandate against the customer’s own bank costs less to run and does not break when a card expires — but like any bank transfer it resolves in its own time. A card answers in seconds and cannot keep a queue waiting. So the context picks, not the merchant.
| Context | Instrument | Why |
|---|---|---|
| Recurring collection | Bank account | No expiry churn, and nothing for the customer to do per collection. |
| Online checkout, pay-by-link | Bank account | You hold the order until settlement, as with any bank-transfer method. |
| In store | Card | The only instrument that returns a guaranteed answer in the time a cashier has. |
| Bank collection fails | Card | Fallback, and only where the customer consented to it at enrolment. |
| Customer overrides | Either | A deliberate per-payment or per-merchant choice, theirs to make. |
The most likely integration mistake
On the bank rail, the authorisation callback is not the money. It means the charge was accepted, not that it settled. Hold the order pending and release on the settlement webhook — exactly as you would for a bank transfer. If your goods are delivered instantly and a pending state is impossible, ask us for card-first routing on your integration; it is a per-merchant configuration reviewed at onboarding, and the customer is told which instrument is charged either way.
Money and reliability
Where the money sits, and what happens when it doesn’t.
xPay holds nothing
Funds move from your customer’s bank to your registered business account. There is no xPay balance in between, which is why there is no xPay balance you can be owed.
Priced per rail, not blended
The two instruments have genuinely different cost structures, and quoting one number for both means one rail is quietly subsidising the other. Your schedule is agreed against each.
One outage is not the other
A card-rail problem does not stop recurring collections, and a mandate problem does not stop payments at a counter. Both rails share one provider, though, so a provider-wide outage is a full outage — we will not pretend otherwise.
Merchant dashboard
Everything, in one place, in real time.
Every transaction carries the instrument it used and the reason it was chosen, so a reconciliation question has an answer rather than a support ticket. The environment you are looking at is never ambiguous.
In build. The instrument core, the routing engine and the provider adapter are written; the dashboard is next, and this list is what it will open with.
- Transactions and reconciliation
- Customers and their instruments
- Payment links and QR terminals
- Recurring plans and schedules
- Refunds and disputes
- API keys and webhooks
- Team roles and permissions
- Sandbox and production environments
Start in the sandbox.
It is fully isolated, moves no real money, and simulates the whole lifecycle on both rails — enrolment, decline by reason, expiry, activation delay, collection failure, card fallback, revocation, disputes and refunds. Production is enabled when you have certified against it.