Solution
Financial systems where every movement of money is accounted for
We engineer payment, ledger, wallet and lending platforms whose first requirement is correctness: no transaction lost, none applied twice, and every balance explainable from the entries behind it.
The problem space
Financial software has a property most software does not: its errors are denominated in money and are noticed by customers, finance teams and regulators. A request that times out and is retried can become a duplicate payment. A balance stored as a single mutable number can drift from the transactions that should explain it. A provider's settlement file can disagree with internal records by an amount nobody can trace. These are engineering failures with well-understood remedies, and the remedies need to be in the foundation.
The foundation is a ledger. A double-entry ledger records every movement as balanced debits and credits across accounts, is append-only, and derives balances from entries. Payments, wallets, lending and fees are all products built on top of it. Around the ledger sit the mechanics that make it trustworthy in a distributed system: idempotency on every write, explicit state machines for each payment, reliable event publication, and reconciliation against every external party.
Starone provides engineering. We do not hold financial licences and make no claim of regulatory approval. Systems are designed to support the obligations of the licensed entity that operates them, including record keeping, audit, customer due diligence and reporting. Determining which obligations apply is a matter for the client and their compliance and legal advisers.
Why it is hard
Engineering challenges
Duplicate and lost transactions
Networks fail between a request and its response, so the caller cannot know whether the payment happened. Retrying without protection charges the customer twice; not retrying leaves the payment in limbo. Every money-moving operation needs an idempotency key that makes a repeat request return the original result.
Balances that cannot be explained
Updating a balance column directly loses history and invites race conditions when two transactions touch the same account. When the number is wrong there is nothing to audit. Balances must be derived from immutable ledger entries, with any cached balance treated as a verifiable projection.
External providers with uncertain outcomes
Card processors, banks and payment networks respond asynchronously, time out, send webhooks out of order and occasionally reverse a result days later. Treating a provider call as a simple success or failure produces stuck and mismatched payments. Each payment needs a state machine that models pending, unknown and reversed states explicitly.
Reconciliation left to month end
Internal records, provider reports and bank statements describe the same money in different formats and at different times. If they are compared only periodically and by hand, breaks accumulate and their causes are lost. Reconciliation needs to be automated and continuous, with every unmatched item raised as a tracked exception.
Concurrency on hot accounts
A merchant settlement account or a fee account may be touched by a large share of all transactions. Naive row locking turns it into a bottleneck, and optimistic approaches without care permit overdrafts. The ledger design has to handle contention deliberately while still preventing a balance from going below its limit.
Compliance checks in the critical path
Screening, identity verification and transaction monitoring depend on third-party services with their own latency and failure modes. If they are bolted on, an outage either blocks all customers or silently lets transactions through unchecked. The flow has to define what happens when a check is slow, unavailable or returns a possible match.
How we build it
Architecture
The platform centres on an append-only double-entry ledger, with payment orchestration, provider integrations and compliance services built around it and connected by reliably published events.
- 01
Double-entry ledger service
Every financial event is recorded as a transaction whose debit and credit entries sum to zero, written atomically in a relational database such as PostgreSQL under serialisable or carefully locked transactions. Entries are never updated or deleted; corrections are new reversing entries. Amounts are stored as integers in minor units with an explicit currency, never as floating-point values.
- 02
Idempotent API layer
All mutating endpoints require an idempotency key supplied by the caller. The key, the request fingerprint and the eventual response are stored in the same transaction as the business effect, so a retry returns the stored result and a reuse of the key with a different payload is rejected. The same principle is applied to inbound webhooks and message consumers.
- 03
Payment orchestration
Each payment is a persisted state machine with defined transitions such as created, authorised, captured, settled, failed and reversed. An orchestrator drives transitions, calls providers through adapters, and schedules status enquiries when a response is missing. Funds are placed on hold in the ledger before an external call and released or finalised according to the outcome.
- 04
Provider and rail adapters
Banks, card processors, payment networks and wallet schemes are each wrapped in an adapter that normalises their API, error codes and webhook formats. Adapters apply timeouts, bounded retries with backoff and circuit breakers. Routing rules can direct traffic to an alternative provider when one degrades, where the commercial arrangement allows it.
- 05
Onboarding and compliance integration
Customer onboarding is a workflow that collects data, calls identity verification and sanctions-screening providers, and routes uncertain results to a case queue for human review. Transaction monitoring consumes the event stream and raises alerts against configurable rules. The workflow defines explicit behaviour for provider timeouts, so the decision to hold or proceed is a recorded policy.
- 06
Reconciliation engine
Provider settlement files, bank statements and internal ledger entries are ingested, normalised and matched by reference, amount and date using configurable rules. Matched items are closed automatically. Unmatched and partially matched items become exceptions with an owner and an ageing clock, and the engine runs as often as the source data allows.
- 07
Audit, reporting and event stream
State changes are published through a transactional outbox to a durable log such as Kafka, which feeds reporting stores, monitoring and downstream systems without loading the ledger database. An immutable audit record captures who did what and when, including operator actions. Regulatory and management reports are generated from these stores and can be traced back to source entries.
Channels
- Web
- Mobile
- Partner APIs
- Batch files
API Gateway
- Authentication
- Rate limiting
- Idempotency keys
- Request signing
Transaction Services
Java and Spring Boot, stateless, horizontally scaled
- Payment initiation
- Authorisation
- Ledger posting
- Limits and risk
Kafka Event Backbone
- Transaction events
- Outbox relay
- Partitioned topics
- Dead-letter topics
Ledger DB & Redis
The ledger is authoritative, the cache is not
- Double-entry ledger
- Read replicas
- Balance cache
- Distributed locks
Reconciliation & Audit
- Settlement matching
- Break detection
- Immutable audit log
- Reporting exports
Monitoring
- Latency and error SLOs
- Consumer lag
- Tracing
- Business alerts
What an engagement delivers
- Ledger design with chart of accounts and posting rules
- Idempotent payment and wallet APIs with published contracts
- Payment state machines and provider adapters
- Onboarding workflow integrated with KYC and screening providers
- Automated reconciliation with exception management
- Audit trail and reporting data stores
- Failure-mode test suite covering timeouts, duplicates and reversals
Before you start
Decisions to make early
- Build a ledger or use an existing one
- A ledger is conceptually small and unforgiving in its details. Adopting an established open-source or commercial ledger saves time when its account model fits your products. Build your own when you need posting rules, multi-currency behaviour or performance characteristics that existing options do not provide, and budget for the testing that correctness demands.
- Strong or eventual consistency
- The ledger write and any balance check that guards it must be strongly consistent; this is not a place for eventual consistency. Everything derived from the ledger, such as statements, notifications, analytics and search, can be eventually consistent and fed by events. Drawing this line clearly keeps the critical path small and fast.
- One payment provider or several
- A single provider is simpler to integrate, reconcile and reason about, and is a sensible starting point. Add a second when availability targets, geographic coverage or cost require it. Multiple providers mean multiple reconciliation feeds, differing dispute processes and routing logic that itself needs testing.
- How to scale transaction throughput
- First remove contention: batch postings to hot accounts, use sub-accounts, and keep transactions short. Then scale reads through replicas and projections. Partition the ledger by account or tenant only when a single well-tuned database is demonstrably the limit, because cross-partition transfers add real complexity.
FAQ
Common questions
Is Starone a licensed financial institution?
No. Starone is an engineering company. We design and build the technology for organisations that hold, or are obtaining, the relevant licences. We make no claim of regulatory approval, and licensing and regulatory interpretation rest with the client and their advisers.
How do you prevent double charging?
Through idempotency at every layer. Client requests carry an idempotency key recorded atomically with the ledger posting, provider calls use the provider's own idempotency mechanism where one exists, and message consumers record processed message identifiers. A repeated request returns the original result instead of creating a new movement.
Can the platform support card data and security standards?
The architecture is designed to minimise exposure, typically by using a provider's hosted fields and tokenisation so that raw card data does not enter your systems. Network segmentation, encryption, key management and access logging are designed in alignment with frameworks such as PCI DSS. Formal assessment and certification are carried out by the operating entity with a qualified assessor.
How are failures tested before go-live?
By injecting them. Test suites simulate provider timeouts, duplicate and out-of-order webhooks, partial failures during posting and process crashes mid-transaction, then assert that the ledger still balances and no payment is lost or duplicated. Reconciliation is exercised with deliberately mismatched files.
Related
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.