Payment rails
Payment gateway engineering,
card and crypto in one ledger.
We build gateways for PSPs, EMIs and neobanks across the EU. One team owns the router, the ledger, the risk rules and the payout path. You get a gateway you can run, reconcile and prove.
- EU-based engineers
- PSD2-aware delivery
- PCI DSS readiness
Rails
The rails we wire in
Every market wants a different way to pay. The router hides that from your product team. One integration, many methods.
Moving between fiat and digital assets? See on and off-ramp integration.
| Rail | What we build |
|---|---|
| Card acquiring | Tokenised card flow with 3-D Secure step-upVault, retries and refunds sit behind one API. |
| SEPA & SEPA Instant | Bank file and API rails with payout batchingMandates, returns and R-messages handled in code. |
| Open banking | PIS and AIS links under PSD2 consent rulesConsent state is stored, not guessed. |
| Crypto pay-in | On-chain deposits with confirmation policyQuotes lock a rate for a set window. |
| Payouts | Fiat and on-chain withdrawal with approvalsEvery payout carries a signed approval trail. |
| Local methods | Wallet and bank redirect methods per marketNew methods plug into the same router. |
Scope
Four systems behind one API
A gateway is not one service. It is four that must agree on every cent. We build them together, on one plan, with one team accountable.
-
01
Router & orchestration
One router picks the cheapest working path. It fails over when a provider slows down or drops.
- Rule-based routing
- Provider failover
- Retry windows
-
02
Ledger & reconciliation
A double-entry ledger holds every movement. Provider files reconcile against it each day.
- Double-entry core
- Daily file match
- Break queue
-
03
Risk & fraud controls
Rules and velocity checks run before capture. Analysts get a queue they can actually work.
- Velocity rules
- Sanctions screening
- Case review
-
04
Merchant tooling
Onboarding, dashboards and API keys ship with the gateway. Support stops living in your inbox.
- KYB onboarding
- Merchant portal
- Webhook logs
Money path
From tap to settled funds
Payments fail in the gaps between steps. So we design the whole path, then make each hand-off replayable.
- 01
Authorise
Seconds
The router picks a path. Risk rules run before the charge is taken.
- 02
Capture
Same day
Funds are captured and written to the ledger as a double entry.
- 03
Reconcile
T+1
Provider files are matched line by line. Breaks land in a queue.
- 04
Settle & report
T+1 to T+2
Merchants are paid out. Reports go to finance and your auditor.
Engagement
Four ways to buy the work
Scope changes as you learn. The commercial model should move with it.
-
Fixed-scope build
A defined gateway, a fixed price, a dated plan. Best when scope is settled.
-
Dedicated team
A standing squad with a lead. Best for long roadmaps and steady releases.
-
Staff augmentation
Senior engineers inside your team. Best when you own the plan already.
-
CTO advisory
Architecture and hiring guidance. Best before you commit to a build.
Questions
Before you brief us
The four things payment teams ask first. Ask the rest on the call.
Related work sits on our fintech infrastructure page and in how we deliver.
Do you replace our current provider?
Not always. We often wrap what you have in a router first. You keep the rails that work and add new ones later.
Can one gateway take cards and crypto?
Yes. Both settle into the same ledger. Finance reads one report instead of two.
How do you handle PSD2 and SCA?
We build the exemption and step-up logic into the flow. Your advisers set the policy. We ship the code and the evidence.
Who owns the gateway at the end?
You do. We build bespoke, client-owned systems. There is no white-label licence and no per-seat fee.
Tell us how the money should move
Bring a rough flow. We come back with an architecture view, a risk list and a costed plan. No demo theatre.