Testing a FinTech App Before Launch: Money, Ledgers, Edge Cases

Test a FinTech app in four areas before launch: how money is represented, so rounding never loses a cent; ledger integrity, so the books always balance; idempotency, so a retried request never double-charges; and reconciliation, so your records match the payment provider's. The happy-path transaction everyone demos is the one case that rarely breaks. Money is lost in retries, rounding, ordering and the cases nobody reconciled.

This is general engineering information, not compliance, legal or financial advice; confirm your obligations with your adviser. If you would rather have it tested for you, see how RAITHub would test this below, and pair a regulated build with a compliance partner.

What goes wrong in a FinTech app, and what catches it?

Write your tests from the failures, not the demo. These are the ones that reach production and cost real money.

What goes wrong	Real cause	Test that catches it
A cent appears or disappears	Money stored or computed as a floating-point number	Sum many small amounts and assert the exact integer total
The books do not balance	One side of a transfer written without the other	Assert total debits equal total credits after every operation
A customer is charged twice	A network retry repeats the request	Repeat the same request with one idempotency key; assert one charge
Balance updated out of order	Events or requests processed in the wrong sequence	Apply events out of order; assert the correct final balance
Your records disagree with the provider	No reconciliation job, or it ignores edge cases	Reconcile a day of transactions; assert zero unexplained differences
Partial failure leaves a half-transfer	Debit committed, credit failed, no rollback	Fail the second write; assert both sides roll back

How should money be represented, and how do you test it?

As integers in the smallest unit (cents, poisha), never as floating-point numbers, because floats cannot represent many decimal amounts exactly. Test the representation directly: sum a long list of small amounts and assert the exact total, apply a percentage fee and assert the rounding rule, and convert a currency and assert no fraction of a unit is created or lost. TheSkinProof, the founder's own marketplace venture built and run by RAITHub, stores amounts as integer poisha for exactly this reason. The money-type reasoning is in payments engineering in practice.

How do you test ledger integrity?

A ledger's core invariant is that it balances: every amount that leaves one account arrives in another, so total debits equal total credits. Test that invariant after every operation, not just at the end. The strongest version is a check you can run against the database itself:

-- The whole ledger must sum to zero: every debit has a matching credit.
SELECT COALESCE(SUM(amount), 0) AS imbalance
FROM ledger_entries;
-- Expect 0. Any other value means an entry is missing its pair.

-- No account should be left in an impossible state by a half-written transfer.
SELECT account_id, SUM(amount) AS balance
FROM ledger_entries
GROUP BY account_id
HAVING SUM(amount) < 0 AND account_id IN (SELECT id FROM accounts WHERE no_overdraft);
-- Expect no rows.

Run the balance assertion after each tested transfer, deposit and refund, and as a continuous check in production. The append-only, double-entry design behind it is in double-entry ledger database design. Also test that a transfer is atomic: fail the credit side and confirm the debit rolls back, so there is never a half-transfer.

How do you test idempotency and ordering?

Every money-moving request must be safe to retry, because networks retry. Send the same request twice with one idempotency key and assert a single charge and a single ledger entry. Then test ordering: apply a balance-affecting sequence out of order and assert the correct final state, because events do not always arrive in the order they were created. The concept, and why it matters for API design, is in what idempotency means in API design, and the webhook-specific plan is in testing payments and webhooks end to end.

• Repeat a "create payment" request with the same key; assert one charge and one row.
• Repeat a webhook delivery; assert the balance changes once.
• Deliver a later event before an earlier one; assert the final balance is correct from the latest state.
• Crash the handler after it acknowledges but before it writes; assert the event is retried or queued, not lost.

How do you test reconciliation?

Reconciliation is the safety net that catches everything the unit tests miss: fees, chargebacks, timing differences and partial captures. Test it with a day of mixed transactions, then assert there are no unexplained differences between your records and the provider's.

• Pull a provider report for a test day and match every line to a ledger entry; flag unmatched lines on both sides.
• Include a refund, a partial refund, a dispute and a fee, and confirm each is reflected and explained.
• Introduce a deliberate mismatch and confirm the reconciliation job reports it rather than silently balancing.
• Confirm a payout matches the sum of its underlying transactions minus fees, to the cent.

The design of a reconciliation process is in payment reconciliation software.

Buy, build or hire this testing?

Option	Choose this when	Trade-off
A payment provider's hosted ledger or balances product	Your money model fits theirs and you want less to build	Less code to test; you still test your glue and reconciliation
Your own test suite (unit plus a database balance check)	A developer can own the money, ledger and idempotency tests	Lowest cost to run; you design the invariants, which is the skilled part
A freelance tester before launch	You want one outside pass	Rounding and ordering bugs are easy to miss; check their money-systems experience
A managed QA plan or a one-off pre-launch audit	You want money, ledger, idempotency and reconciliation tested end to end	An outside dependency; it is engineering QA, not a compliance attestation; keep the tests in your repository

Doing it yourself is realistic: plan 4 to 6 days for a developer who knows the stack. The main risk of going alone is testing single transactions and never the retries, ordering and reconciliation where money actually goes missing.

Why RAITHub for this

• Money handled correctly is everyday work. TheSkinProof moves money across bKash, Nagad, SSLCommerz and cash on delivery with amounts as integer poisha and 750+ tests; Sundor Skin enforces credit limits in the database with a hash-chained audit log and 530+ tests; PadhAI is designed for 9 payment gateways. RAITHub has also built a fintech dashboard for a client.
• Tests that assert the invariant, so the ledger is proven to balance after every operation, not just checked at the end.
• Honest limits. RAITHub has not shipped a regulated or licensed fintech product (lending, custody, card issuing, money transmission). Its security testing is application-level against OWASP guidance, not a CREST- or PCI-certified penetration test, and it holds no SOC 2 or ISO 27001 certification. Confirm compliance with your adviser.

When you don't need us

• Your app uses a hosted checkout and holds no balances of its own. Test your glue code and reconciliation.
• You have a QA engineer who owns money-flow testing.
• You need a certified assessment or a licensed partner. That needs a certified vendor and your adviser; RAITHub provides neither.

How RAITHub would test this

• Scope: agree the money model, the ledger design and the provider on a free 15-minute call.
• Plan: a risk map across representation, ledger integrity, idempotency and reconciliation, with a test for each.
• Test: rounding and summation, the balance invariant after each operation, idempotent retries and out-of-order events, and a day of reconciliation with deliberate mismatches.
• Deliver: a ranked bug report with reproduction steps and a suggested fix, plus the money and ledger tests as automated tests in your repository.
• What you receive: the report, the tests and a handover note. IP is yours; an NDA is standard. This is engineering QA, not a compliance attestation.

The audit is fixed-price, quoted in writing after the call. See QA as a Service, API and backend development, and the FinTech industry page. To book it, ask for a pre-launch QA audit.

General information only; confirm compliance obligations with your adviser. Documentation checked on 10 October 2026.

Frequently asked questions

What should you test before launching a FinTech app?

How money is represented, ledger integrity, idempotency of money-moving requests, and reconciliation against your payment provider. Start with the ledger balance invariant and idempotent retries, since those are where money quietly goes missing.

Why should money be stored as integers?

Because floating-point numbers cannot represent many decimal amounts exactly, so sums and fees drift by fractions of a cent. Store amounts as integers in the smallest unit, and test by summing many small amounts and asserting the exact total.

How do you test that a ledger always balances?

Assert that total debits equal total credits after every operation, and run the same check continuously in production. A database query summing all entries should return zero; any other value means an entry is missing its matching pair.

How do you test that a payment is not charged twice?

Send the same money-moving request twice with one idempotency key and assert a single charge and a single ledger entry. Repeat the matching webhook too, and confirm the balance changes once.

Why does reconciliation need its own tests?

Because it catches what unit tests miss: fees, refunds, disputes and timing differences. Test it with a day of mixed transactions and a deliberate mismatch, and confirm the job reports unexplained differences rather than silently balancing.

Has RAITHub shipped a regulated fintech product?

No. RAITHub has built a fintech dashboard for a client and live payment flows on its own platforms, and has not shipped a licensed product such as lending, custody or card issuing. For a regulated build, pair RAITHub's engineering with a compliance partner.