Service
Payment gateway
In one line
One integration, more than one acquirer behind it.
What it is
The gateway is the layer your site talks to. Its job is to keep card data out of your systems, hand the transaction to the right acquirer, and give you one API regardless of how many merchant accounts sit behind it.
That last part matters more in restricted verticals than anywhere else. If you hold three MIDs across two sponsor banks, you should still be writing one integration — and you should be able to move volume between them without a code change.
Capabilities
What you get, specifically.
Tokenisation and hosted fields
Card data is captured in fields we host and never touches your server, which keeps your PCI scope at SAQ A where the integration allows.
Multi-MID routing
Route by card brand, currency, ticket size, product or plain percentage split. Change the split without redeploying.
Automatic failover
If an acquirer stops responding, transactions route to the next MID in the chain rather than declining.
3-D Secure and fraud rules
3DS2 with configurable exemption logic, plus velocity, geolocation, BIN and blocklist rules you can tune per MID.
Cart and platform integrations
Drop-in support for the major carts, plus a documented REST API and webhooks for anything custom.
Specification
The detail.
- Integration
- REST API, hosted fields, hosted checkout, cart plugins
- PCI scope
- SAQ A with hosted fields; SAQ A-EP for direct post
- Tokenisation
- Network and gateway tokens
- Webhooks
- Signed, with replay
- Gateway fees
- Set at underwriting
- Uptime
- Set at underwriting
Rows reading set at underwriting are not omissions. Those figures are decided per merchant against your vertical, volume and history, and you will see all of them in writing before you sign.
Tell us what you sell.
Before anything sensitive changes hands, we will tell you whether a route exists for your vertical, roughly what shape it takes, and what underwriting will ask you for.