Fintech
Fintech software where the money always balances
Taking a payment is the easy half. Agreeing on what happened, after a timeout and a retry, is the half that keeps finance teams awake.
Four things that decide whether a fintech build survives
4 things that decide this
- 01Your PCI scope is decided by how you embed the payment form, not by which processor you chose. A hosted field and a direct-post form put you in different questionnaires.
- 02Money belongs in integer minor units, never a float. A float cannot hold 0.10 exactly, and the drift shows up in a reconciliation nobody scheduled.
- 03A payment call that times out has not failed. It has an unknown outcome, and the only safe repair is an idempotency key you sent before the first attempt.
- 04Design the ledger before the screens. Money moves as entries that are reversed rather than edited, which is what keeps your totals and the processor's agreeing.
Fintech bugs do not crash. They disagree.
A normal web bug announces itself. A money bug does not. Your system says the customer paid. The processor says the charge was disputed. Both records look reasonable and neither can prove the other wrong.
The gap usually opens in an ordinary place. A webhook arrives twice. A network call times out after the charge succeeded. A refund lands before the payment it reverses. Each is a normal Tuesday for a payment processor, and each becomes a support ticket a month later.
So we design the ledger before the screens. Money moves as entries that never get edited, only reversed. That is duller to demo and it is the reason the numbers still tie out in year two.
Our own count
What we have actually shipped
7
Production builds with Stripe integrated, including Stripe Connect for marketplace payouts
22
Case studies published with the client named and the stack listed
3
Named AI-on-financial-data products: Trading CoPilot, IRS Escape Plan, PremiumAudit.io
The fintech work we take
Product engineering where payments, real-time data and AI meet. Not core migrations.
Payment integration that reconciles
Hosted fields, webhook handling that tolerates duplicates, and a ledger that agrees with the processor. Stripe across seven builds, plus Stripe Connect where money is held between two strangers.
Double-entry ledgers
Append-only entries, reversals instead of edits, and balances derived rather than stored. When a regulator or an auditor asks how a figure arose, the answer is a query.
Marketplace and escrow flows
Holding funds, releasing on a condition, and freezing on dispute. WorkMateAI does exactly this for Australian trades, with chargeback evidence generated from the record.
Real-time data pipelines
Webhook ingestion, enrichment and alerting where late data is worse than no data. Trading CoPilot takes TradingView alerts and routes them through a human approval step.
AI on financial documents
Reading 1040s, K-1s, 1099s and audit paperwork, then checking the extraction rather than trusting it. IRS Escape Plan and PremiumAudit.io both run this pattern.
Human approval gates
An agent that proposes and a person who confirms. In Trading CoPilot the trade waits on a yes from Telegram before the broker connection executes anything.
- Charge sentIdempotency key attached first.
- TimeoutNo response. Outcome unknown.
- RetrySame key, so no second charge.
- WebhookMay arrive twice, or out of order.
- Ledger entryWritten once, never edited.
- ReconciledYour total equals the processor's.
Every step here is ordinary. The failure is treating a timeout as a failure, retrying without a key, and charging a customer twice for one order.
One analytics script can change your compliance position
Most teams believe using Stripe puts them out of scope. That is true only for certain integration types. A hosted redirect or an iframe keeps you in the lightest questionnaire. A direct-post form or a JavaScript SDK that touches the page can move you into a heavier one.
The 2025 revision made this sharper. Two script-control requirements were lifted out of the lightest questionnaire and replaced with a broader attestation about the site itself. Qualifying now means confirming your site is not open to script attacks, which is a wider claim than protecting one page.
Practically, a marketing tag added to checkout by someone in another team can move you. We treat the checkout page as a controlled surface, with a written list of every script on it and a reason each one is there.
- Pick the integration model before the design, because it sets the scope.
- Never let a full card number reach your servers, your logs or your error tracker.
- Keep an inventory of checkout scripts, and make adding one a decision.
Systems where money and documents have to agree
“Their attention to detail, quality of employees, and work ethic were outstanding.”
Nicolas de Quesada · CEO, Lexpair
Shipping fast against shipping something that balances
| Criterion | The usual build | How we build |
|---|---|---|
| Money storage | A decimal or float column, because it renders nicely. | Integer minor units, with the currency stored beside the amount. |
| Retries | Retry on timeout and hope the customer notices the double charge. | An idempotency key generated before the first attempt, reused on every retry. |
| Webhooks | Process on arrival, assume each event lands once. | Deduplicated by event id, processed out of order safely. |
| Corrections | Update the row and lose the old value. | Write a reversing entry, so the history survives the fix. |
| PCI position | Discovered during the annual questionnaire. | Chosen at design time, with the integration model picked deliberately. |
What these builds run on
Application
Data
Payments
AI
Questions fintech teams ask us first
01How much does it cost to build a fintech product?
The drivers are how many money movements you support, how many parties hold funds, and which licence or standard you must answer to. A single-currency subscription product is a different build from a marketplace holding money between strangers. Scoping calls cost nothing. Where we would have to read an existing codebase to answer honestly, we run a paid two-week diagnostic and you keep the findings either way.
02Which SAQ type will our architecture put us in?
Your integration choice sets it, not your processor. Fully hosted fields from a compliant provider point toward the lightest questionnaire. A form that posts card details directly, or a script that can alter the payment page, points to a heavier one. Decide this before you build the checkout, because changing it later means rebuilding it.
03Can you build our ledger if we already have a payment provider?
Yes, and it is a common starting point. The processor knows what it charged. It does not know what you owe a seller after fees, refunds and a partial chargeback. That reconciliation layer is yours to own, and we build it as double-entry so every figure can be traced back to the events that produced it.
04Can you build the layer that sits around our core platform?
Yes, and that is where most of the value sits. The core holds the balances and answers to the regulator. The layer around it decides whether your product works: a sub-ledger that reconciles daily, payment flows that model an unknown outcome rather than treating a timeout as failure, and onboarding that produces evidence somebody can examine later. We build that layer, and we keep it portable.
05How do you keep an AI feature from inventing a number?
Never let the model be the source of a figure. In our tax and audit work the model extracts and the system checks the arithmetic, so a wrong reading becomes a flagged discrepancy rather than a confident total. Where an action moves money, a person approves it. Trading CoPilot waits for a yes before any trade reaches the broker.
Go deeper
- Fintech compliance and ledger design →The regulation map and why the ledger is the product.
- Why you never use floats for money →The rounding error that compounds quietly.
- Idempotency key →How a retried payment avoids a second charge.
- Payment gateway integration →Reconciliation, disputes and multi-currency edge cases.
