Stripe delivers webhooks at least once and doesn't promise any order. A refund event can arrive before the charge it refers to. In live mode, Stripe keeps retrying a failed delivery for up to three days. That one documented behaviour shapes fintech software development more than any choice of framework. If your system credits a balance every time an event lands, one retry turns into a double payout, and one out-of-order event leaves a refund pointing at a charge your database hasn't recorded yet. In this vertical the ledger is the product. The app is a window onto it.
So judge a fintech vendor by how it models money moving, failing and reversing. Screens are the cheap part. I've spent 11 years running an engineering studio that has built payment flows, marketplace payouts and claims platforms that end in money owed to people. The seven questions below are the ones that decide whether a build survives its first month-end close. Each answer comes from what I've seen work and what I've seen fail.
1. Can They Draw Your Ledger Before They Draw Your Screens?
A fintech system needs a double-entry, append-only ledger. Every movement is a set of entries that sums to zero. Balances are calculated from those entries rather than stored in a column you can edit. Amounts are integers in minor units, and every amount carries its currency. Currencies differ in how many decimal places they use: the Japanese yen has none, and the Kuwaiti dinar and Bahraini dinar have three. A schema with two decimals hard-coded works until the day you add a market that doesn't fit. Rounding is a written policy. If you split $100.00 three ways, someone gets the extra cent, and the code has to say who. A correction is a reversing entry, never an UPDATE statement.
A strong vendor comes out of discovery with a chart of accounts: user wallets, platform fee revenue, processor clearing, payouts in transit, disputes held. Each money flow is written out as balanced entries before anyone opens Figma. The warning sign is a balance column on the users table. That design works fine in a demo. It fails the first time two requests hit the same account in the same millisecond.
2. What Happens When the Same Payment Event Arrives Twice?
Every outbound call that moves money needs an idempotency key. Stripe supports one on every POST and keeps keys for at least 24 hours, so a network timeout followed by a retry doesn't charge the card twice. Every inbound event should be deduplicated by its event ID. That check belongs in a unique-constraint table written in the same database transaction as the ledger entry, so both commit or neither does. A payment should be modelled as an explicit state machine (pending, succeeded, failed, refunded, disputed) whose transitions are allowed no matter what order events arrive in.
ACH makes the point even more sharply. A debit that looks settled today can come back as R01 (insufficient funds) within two banking days. A consumer can return it as R10 (unauthorised) for up to 60 calendar days after settlement. So 'paid' is a state with an expiry date, and your payout logic has to know it. Nacha's risk-based fraud-monitoring rules also phase in during 2026, starting with the largest originators, which pushes more of that logic onto whoever writes the origination code. Ask the vendor to walk through an R10 on day 45, after the funds have already gone out to a seller. How clearly they answer tells you more than their portfolio.
On Snapwire we supplied 10 engineers inside a 30-person engineering organisation for two and a half years, with Stripe Connect as the payments layer under a Laravel, React and PostgreSQL stack. Over a stretch that long, connected-account onboarding states, payouts and refunds that cut across a platform fee become ordinary daily work. The team that designed for them in month one spends less time fixing them later.
3. Who Reconciles, and How Often?
Reconciliation is three-way and daily. Your internal ledger is checked against the processor's balance transactions and payout reports, and both are checked against the bank statement, usually a BAI2 or camt.053 file. Each mismatch gets classified: a timing difference that will clear on the next settlement, or a real error that needs a person. A vendor who can't name the settlement file formats your bank sends hasn't reconciled anything yet.
Treat reconciliation as a product feature with its own ops screen, built from the first sprint. At the first month-end close, finance will ask why the ledger says one number and the bank says another. A team that has matched the three sources every day can answer in minutes. A team that planned reconciliation for phase two will spend a week searching logs.
4. How Much of the Compliance Surface Can the Architecture Remove?
The cheapest compliance control is the data you never touch. With hosted payment fields and tokenisation, raw card numbers never reach your servers, which shrinks PCI DSS scope from the full self-assessment to one of the short ones. That choice is made in the architecture, well before any auditor arrives. PCI DSS v4.0's future-dated requirements became mandatory on 31 March 2025, and they turned script inventory and tamper detection on payment pages into front-end engineering work. Your React team is now inside the compliance conversation.
In the EU, DORA has applied since 17 January 2025, and it reaches through financial entities into their ICT providers' contracts: access rights, support during incident reporting, and a workable exit strategy. A vendor's answer should cover how it would hand the system back as well as how it would build it. Be clear about who holds which responsibility. Nautical Commerce, a marketplace-as-a-service platform where we took over a one-year-old codebase and delivered against a 90-day go-live model, went on to meet SOC 2. That certification belongs to the client's platform. EltexSoft itself holds no SOC 2 certification. What an engineering team adds is the evidence behind the controls: audit logs, least-privilege access, and a change history in which every change is traceable. A vendor that is clear about where its responsibility ends is also easier to record accurately in a DORA register of information.
5. Who Reviews the Code That Moves Money?
Banks apply a four-eyes principle to payments, and a fintech codebase needs the same rule for merges. We don't merge a pull request until at least one other senior engineer has reviewed it. That's our rule on every project. In fintech it also produces the change-management evidence an auditor asks for, because every change to fee calculation or payout logic has a named reviewer and a timestamp.
This matters more now that AI coding tools are in every editor. We use Claude Code and Cursor to speed up work, and everything they produce is reviewed like any other code. An LLM will readily write currency maths in floating point, and in JavaScript 0.1 plus 0.2 does not equal 0.3. Ask the vendor who reviews machine-written code that touches a balance, and what they look for.
6. Will the Same Engineers Still Be There at the Next Audit?
Fintech knowledge builds up over time and lives in people: the processor whose payout report arrives a day late, the bank cut-off that moves across daylight-saving changes, the reason one ledger account carries a manual adjustment from last March. At the industry turnover rate of more than 20% a year, you pay for someone to relearn all of that every year. Our turnover is under 5% a year. Average engineer tenure is about eight years, and the average client engagement runs about four.
MyFlyRight shows what that looks like over a long stretch. We've been its engineering partner since 2016. We built its claims-automation platform from scratch on React, Laravel and PostgreSQL to handle compensation under EU Regulation 261/2004, and that platform has since processed more than a million claims. Keeping the same team on the same regulatory rules for close to a decade means the person who reviews a change to the compensation logic is often the person who wrote the original version.
7. What Does the First Paid Phase Actually Buy?
Price is set mainly by two things: how many payment rails you use, and who holds the funds. A marketplace on Stripe Connect with one currency, cards in, payouts out, its own ledger and daily reconciliation sits in the lower half of an $80,000 to $200,000 marketplace build. Stripe carries connected-account onboarding and the regulated flow of funds, so you don't build those. Add ACH origination through a sponsor bank, a second currency, and your own ledger as the book of record, and the cost moves to the top of that range. Each extra rail brings its own return codes, file formats and reconciliation. A narrower MVP with a single flow fits in $40,000 to $100,000. A typical four-person team runs $25,000 to $55,000 a month, depending on seniority mix and on how much DevOps and QA the compliance scope requires.
Discovery should produce three things: the chart of accounts, a diagram of every money flow, and a written list of what is out of scope. A good pilot then takes one money flow all the way through: the charge, the refund, the reversal, and the reconciliation that proves they agree. On Meal4U, a stalled build we rescued, we re-estimated the scope about ten times and cut 30 to 50 percent on each pass until we reached the smallest product that could ship. That kind of discipline matters even more when every feature you add is another way for money to move.
How EltexSoft Engages on Fintech Builds
We start with a free discovery week. Its output is the ledger model and money-flow map described above, so you can judge how we think about your money before you spend any. Next comes a paid pilot with no lock-in, covering one complete money flow including refunds and reconciliation. After that we work in two-week sprints with daily standups, and every pull request is reviewed by a senior engineer before merge. The next step is to bring your processor or banking-partner documentation and the one money flow that worries you most to a discovery week, and we'll write out its entries together.
Last updated October 1, 2026