Payment processing and settlement · engineering partner
Payment settlement software development,
engineered as a system you own.
TrustChange builds payment processing and settlement software for EU PSPs, EMIs, neobanks and licensed VASPs. We engineer the batching and netting engine, the funding calendar, the payout scheduler, reconciliation and the GL exports as bespoke code around your ledger — not a SaaS licence with a per-settlement fee. Ops, treasury and finance work from one canonical settlement record, with the audit evidence a reviewer expects.
- EU-based engineers
- PSD2-aware fields
- PCI DSS scope kept small
- Tamper-evident audit log
- GDPR-aware storage
What "settlement" means here
Payment settlement processing software as a first-class product, not a nightly cron
Most searches for payment processing and settlement software surface either a bolted-on job in the gateway or a multi-tenant SaaS with a fixed batch model. We work the other way. TrustChange is a bespoke payment settlement processing software partner: your settlement record, your batching windows, your netting rules, your ledger. What you buy is engineering — settlement is a scheduled, configurable, reviewable product surface, not a scary cron job in ops chat.
Deciding whether to build, wrap or replace an incumbent? Start with CTO advisory. The wider gateway view sits on payment gateway engineering. The reconciliation angle in depth: payment ledger & reconciliation development.
Subsystems
Three subsystems inside every payment settlement software engagement
Settlement is not one job. It is a batching and netting engine, a funding and payout orchestrator, and a ledger and reporting layer that must agree on every settled position. We build the three together, on one plan, with one team accountable end to end.
-
01
Batching & netting engine
The engine that groups captures, refunds and chargebacks into settlement batches, nets across counterparties and rails, and closes to cut-off with a deterministic output.
- Configurable batch windows
- Multilateral netting
- Cut-off scheduler
-
02
Funding & payout orchestration
The layer that funds acquirer, PSP and bank accounts, releases payouts to merchants or counterparties on schedule and handles retries under policy.
- Funding calendar
- Payout scheduler
- Retry with backoff
-
03
Ledger, GL & audit exports
Double-entry postings for every settlement movement, matched to bank statements and PSP files, with GL exports and auditor-shaped bundles from one canonical store.
- Idempotent postings
- Bank statement match
- GL & auditor exports
Stack
What sits behind bespoke payment processing and settlement software
Eight layers, one system. Every layer names an owner, a control and a piece of audit evidence — nothing is left implied under the "settlement" label.
Delivery patterns and evidence: how we deliver. Platform view: fintech infrastructure. Exception routing: payment processing exception management software.
| Layer | What we build |
|---|---|
| Canonical settlement record | One typed settlement record joining captures, refunds, chargebacks, fees, FX and interchange across rails One shape per settlement class, versioned in your repository. |
| Batching engine | Rule-based batching with per-rail cut-offs, per-currency handling and configurable windows Batches are configuration, not code — reviewable in the admin console. |
| Netting logic | Bilateral and multilateral netting across counterparties, rails and currencies with tolerance handling Every netted position stores its inputs; a later audit can reproduce the calc. |
| Funding & payouts | Funding calendar for acquirer, PSP and bank accounts; payout scheduling to merchants and counterparties Cut-offs are enforced by the scheduler, not by inbox habit. |
| Reconciliation | Daily reconciliation of settlement batches against bank statements, PSP webhooks and acquirer files with a break workflow Break cases route to aged queues with SLAs; re-run per case, not per batch. |
| Ledger integration | Double-entry postings into your ledger with source id, batch id, rule version and operator id on every movement Retries never mint money twice; every posting carries a full chain of evidence. |
| Reporting & GL | Close packs, GL exports, merchant statements and reviewer-shaped bundles from one canonical store Finance, ops and the auditor read the same source of truth. |
| Runtime & delivery | EU-hosted, CI/CD pipelines, observability, 24/7 on-call cover Your identity provider, your key custody, your data regions. |
Settlement day
From capture stream to reconciled close
Every settlement day in the platform goes through the same shape. Predictable cadence is what makes settlement boring for finance and procurement — which is the goal.
- 01
Capture
Continuous
Captures, refunds, chargebacks and fees stream into the canonical settlement record as they clear the payment path.
- 02
Batch
Per cut-off
The batching engine groups movements by rail, currency and counterparty according to your window rules.
- 03
Net
Per batch
Netting reduces gross movements to a settled position per counterparty and rail; every input is stored.
- 04
Fund
Cut-off bound
Funding calendar releases funds to acquirer, PSP and bank accounts on schedule; retries follow policy.
- 05
Post & match
Immediate to T+1
Ledger posts the settled positions; reconciliation matches to bank statements and PSP files under tolerances.
- 06
Report
Daily / month-end
Close pack, GL exports, merchant statements and auditor bundles publish from the same canonical store.
Delivery
How we deliver payment settlement software development
Five steps, in this order. Settlement work runs inside the product backlog — no separate finance phase bolted on before month-end, no big-bang release of an untested settlement engine.
- 01
Scoping
Weeks 1–2
We map rails, counterparties, currency mix, cut-off expectations, licence context and reporting shapes. Output: a scope, a control map and a costed plan.
- 02
Architecture
Weeks 3–4
Settlement-record schema, batching windows, netting rules, ledger integration and export schemas written down first. Auditor requirements shape the design.
- 03
Build
Two-week sprints
Batching, netting, funding, payouts, reconciliation and reporting ship in slices. Each merge runs tests, static checks and a dependency scan.
- 04
Hardening
Before cut-over
Replay against historical settlement days, load work, failure drills and a third-party review window. Cut-over is rehearsed with treasury, not assumed.
- 05
Launch and run
Cut-over + ongoing
Named engineers on 24/7 cover. Runbooks, dashboards, cut-off playbooks and the audit bundle are handed to your team on day one.
Engagement
Four ways to buy your settlement platform build
Same engineers, same standard. Only the commercial shape changes.
-
Fixed-scope build
A defined settlement platform at a fixed price and date. Best when rails, counterparties and cadence are settled.
-
Dedicated team
A standing squad with a lead. Best for long roadmaps and new rails each quarter.
-
Staff augmentation
Senior engineers inside your team. Best when you already own the plan and need settlement depth.
-
CTO advisory
Architecture and buy-vs-build review before you commit. Best at the design stage.
Questions
FAQ: payment settlement software development
Six answers up front on scope, off-the-shelf trade-offs, batching/netting/cut-offs, rails and reconciliation, PSD2/PCI/AML/GDPR and support. Bring the rest to the call.
What does payment settlement software from TrustChange actually cover?
We engineer a bespoke, client-owned payment processing and settlement software layer around your ledger: the canonical settlement record, the batching and netting engine, the funding calendar, the payout scheduler, reconciliation against bank statements and PSP files, GL and auditor exports, and the operator console that sits on top. It ships as source code in your repositories, with the IP assigned to you and no per-settlement fee.
How is your build different from off-the-shelf payment settlement processing software?
Off-the-shelf settlement platforms bundle a fixed batch and netting model and a licence fee, and the settlement logic lives inside the vendor's platform. TrustChange shapes the settlement record, the batching windows and the netting rules against your actual rails, counterparties, currency mix and reporting cadence. A bespoke build takes longer up front, but you keep every rule, every adapter and every posting decision.
How do batching, netting and cut-offs work in the settlement engine?
Batching groups captures, refunds and chargebacks by rail, currency and counterparty under your window rules. Netting reduces gross movements to a settled position per counterparty and rail — bilateral or multilateral, with tolerance handling. Cut-offs are enforced by the scheduler, per rail and per market, so a SEPA batch and a card batch can close on different clocks without a code fork.
Which rails, counterparties and reconciliation sources do you cover?
Card acquirer files, PSP webhooks and settlement files, SEPA and SEPA Instant statements, wires, open-banking pulls and on-chain reads for digital-asset legs. Counterparties can be acquirers, PSPs, banks, merchants, corporates or internal accounts. Reconciliation matches settlement batches against source files under configurable tolerances; unmatched entries open cases with evidence attached, in the same aged queue your ops team already works.
How are PSD2, PCI DSS, AML and GDPR engineered into the settlement layer?
TrustChange is an engineering partner, not a law firm — your compliance team sets the policy, we ship the controls and the evidence. That means PSD2-aware fields on card and open-banking settlements, PCI-scope-minimising handling of card data, AML rules that run inside the transfer path where relevant, tamper-evident audit logs and GDPR-aware storage with retention rules per case class. Nothing about licences or QSA reports is claimed on your behalf.
Do you also run the settlement platform after launch, or hand it over?
Both are on the table. Most clients start with named TrustChange engineers on 24/7 cover during the first months while their own team ramps up, then take the platform in-house with runbooks, dashboards, cut-off playbooks and the audit log. Some keep us on as a dedicated development team or on staff augmentation for new-rail adapters, netting-model changes and roadmap work.
Book a discovery call for payment settlement software development
Bring the rails, the counterparty mix, the cut-off pain and the reporting shapes. We come back with a control map, an architecture view and a costed plan for a settlement platform you own end to end. No demo theatre.