E-invoicing
Invoicing and payment links, connected to a gateway, sold on to their merchants.
A SaaS invoicing product that connects to a payment gateway, so the gateway's merchants can issue invoices, send payment links and collect online — with reconciliation and settlement available as add-ons. Sold under the gateway's brand. Integration typically takes four to eight weeks.
Updated August 2026
A gateway moves money. Invoicing is how its merchants ask for it.
Most merchants on a gateway are not sending payment requests programmatically. They are issuing an invoice, sharing a link, and waiting to be paid — and if the gateway does not offer that, they use something else and the gateway loses visibility of the transaction.
This closes that. The gateway's merchants log in under the gateway's brand, create an invoice or a payment link, and the payment collects through the gateway itself. Nothing leaves the ecosystem.
Reconciliation and settlement are where it earns its place commercially. Matching payments to invoices, then to settlement batches, is the part merchants currently do in spreadsheets — and the part a gateway can charge for once it exists.
What it looks like.
Representative screens, not screenshots — the live product carries your branding, not ours.
What merchants get.
Invoice creation
Issued from their own data, in their own branding, with your gateway's identity around it.
Payment links
A link they can send by WhatsApp, email or SMS. The most-used feature in these markets by a distance.
Collection through your gateway
Payment happens on your rails. The transaction stays inside your ecosystem rather than leaking elsewhere.
Recurring and scheduled invoices
For merchants billing the same customers monthly, which is most B2B activity.
Reconciliation
Payments matched to invoices automatically. An add-on, and usually the reason a merchant upgrades.
Settlement views
What was collected, what settled, and when. The question merchants ask support most often.
Multi-currency and multi-language
Because a Gulf gateway rarely serves one market or one language.
Your branding throughout
Domain, interface, emails and documents carry the gateway's name. We are invisible to merchants.
Build it, buy a SaaS, or licence this.
Three routes for a gateway that wants to offer invoicing. The right one depends on whether you are selling it onward.
| Build in-house | Buy a SaaS platform | Licence this | |
|---|---|---|---|
| Time to offering | 6–12 months | Weeks | 4–8 weeks |
| Whose brand merchants see | Yours | Theirs, usually | Yours |
| Payment collects through | Your gateway | Often their partner | Your gateway |
| Reconciliation and settlement | You build it | Sometimes, generically | Add-on, built for gateways |
| Who owns the merchant | You | Shared, at best | You |
| Engineering cost | High and ongoing | Integration only | Integration only |
| Right when | Invoicing is your core product | You need it internally | You are selling it to merchants |
Who this is for.
Payment gateways
You process payments and merchants keep asking how to invoice and send payment links.
Aggregators and PSPs
You sit between merchants and acquirers, and invoicing completes the merchant workflow.
Platforms with merchant accounts
Marketplaces or vertical SaaS where your users already take payment through you.
Not for a single company's own invoicing
If you need invoicing for yourself rather than to sell to merchants, an off-the-shelf tool is cheaper and we will say so.
How integration goes.
We map your gateway
How merchants are onboarded, how transactions are recorded, and where invoicing has to fit.
We agree scope and branding
What merchants see, which add-ons you sell, and what stays configurable per merchant.
We connect to your rails
Merchant records, authentication and payment collection, so it behaves as part of your product.
We wire reconciliation
Payments to invoices, then to settlement. The part merchants currently do by hand.
You launch to a subset
A group of merchants first, watching the edge cases only real invoicing produces.
We maintain it
Including regulatory change. You keep selling; we keep the engine current.
What people ask.
Yes, and that is much of the point. When a merchant sends a payment link, the payment runs on your rails and the transaction stays in your ecosystem. Products that collect through someone else's gateway give your merchants invoicing while quietly taking the transaction elsewhere.
Reconciliation matches incoming payments to the invoices that requested them, automatically, so a merchant is not doing it in a spreadsheet. Settlement shows what was collected, what has settled and when. They are add-ons because not every gateway wants to sell them, and they are usually the reason a merchant moves to a paid tier.
Not today, and we would rather say that plainly than imply otherwise. Saudi Arabia's ZATCA requirements are on our roadmap because the regional direction is clear, but describing a roadmap item as a current capability is how a deal gets won and then not delivered. If you need ZATCA compliance now, we are not your supplier yet.
You do, entirely. Merchants contract with you, pay you, and contact you for support. We are infrastructure — we do not appear in the relationship and we have no route to your merchants. If the agreement is not explicit enough on that for your comfort, say so and we will make it so.
Four to eight weeks for most gateways. The variable is rarely our end — it is how cleanly your platform exposes merchant records and transaction data. We look at that before quoting a timeline rather than after.
Let's build what's next.
Tell us what you’re building. We’ll tell you how we’d help.