Fintech Software

In applications that carry money the real subject is not the screen but the ledger. This platform builds payment, wallet, prepaid balance and collection processes on a double-entry ledger, idempotent transaction flows and an explicit state machine.

The most expensive faults in systems carrying financial flows are these:

• Updating a balance in a single field. Without movement history there is no variance analysis and no audit trail.
• Treating an unanswered call as a failure. A transaction that succeeded on the other side appears cancelled on yours — the main source of double charges and customer disputes.
• Retried requests creating duplicates. After a network fault the client resends; without an idempotency key a second record appears.

Every movement of money produces at least two lines: a debit and a credit. A balance is the sum of those lines, never a separate field. That way "why is the balance this?" can always be answered from the movement list.

Every outbound call carries an idempotency key. A second request with the same key creates no new record and returns the result of the first. We cover this in the API integration guide.

Among transaction states, "no response received" is its own state and is not automatically treated as a failure. Such records are closed against the reconciliation file received from the counterparty.

• Ledger: chart of accounts, debit/credit lines, period close, multi-currency.
• Payments: virtual POS, instalments, partial refunds, refund references, 3-D Secure flows.
• Wallet / prepaid balance: top-up, spend, holds, refunds and balance limits.
• Reconciliation: matching bank and payment provider files, difference lists.
• Commission and deductions: commission, holds and value-date differences as separate lines.
• Authority and audit: role-based access, data scope and an immutable audit log.

Bank statements and collection channels (bank integration), virtual POS and payment institutions, e-document systems, accounting and ERP, identity verification services, and an API integration layer for enterprise applications.

• Field-level encryption on sensitive data; card data replaced with tokens.
• Authorisation limited by data scope in addition to role-based rights.
• The audit log is kept separately and cannot be altered.
• Timeouts, retries and circuit-breaker behaviour are defined for external calls.
• Webhooks are verified by signature; replayed deliveries are rejected.

On compliance scope: Card data security and financial regulation requirements depend on the nature of the business, which party holds which data, and licensing status. The compliance scope and who carries which obligation are therefore defined in writing at the start of the project. We state up front that software alone does not produce a compliance certificate.

• Prepaid balance / wallet: top-up, spend and refund flows tracked in an auditable ledger.
• Collection platform: automatic matching of multi-channel collections to customer accounts.
• Dealer or subscription billing: recurring payments, failed-charge handling and retry policy.
• Marketplace payouts: seller settlements, commission deductions and payout day calculation.

1. Ledger and identity: chart of accounts, state machine, idempotency rule.
2. Channel connections: virtual POS, banks, refunds and partial refunds.
3. Reconciliation: file parsing, matching rules, difference lists.
4. Reporting: commission checks, receivable ageing, cash projection.

Do you store card data in the system?

The default design does not: the token returned by the payment provider is stored. Where card data must be held in the system, that changes both scope and responsibility, and is decided separately at the start of the project.

Can you guarantee exactly-once processing?

Not in distributed systems. The realistic target is at-least-once delivery with the receiver refusing to process the same request twice. Idempotency keys and the state machine provide that.

How are reconciliation differences classified?

In three groups: present in yours but not theirs (a lost response), present in theirs but not yours (a missed notification), and present in both with different amounts (commission, rounding, currency). Each has its own resolution path; see the bank integration guide.

How does it work with our existing accounting system?

The ledger does not replace accounting; it produces the entries to be posted to it. The posting period and the level of detail per entry are defined at the start of the project.