Fintech

By building for failure from the first day, because a payment request can time out after the money has already moved. Immutable double-entry records, an idempotency key on every operation that moves value, and an event history that can be replayed to explain any balance on any date. Corrections are posted as new entries rather than edits, so support and audit read the same story.

It depends on what you are doing and who you are doing it with, and it is a question for a regulatory adviser rather than an engineer. What we can do is build so that the answer does not force a rewrite: keeping the regulated boundary explicit means a change of partner or permission is a contained piece of work.

The check itself is an integration; the work is in the flow around it. Deciding what a straightforward applicant sees, what reaches a human, what is stored against the customer and how a decision is explained later takes longer than wiring the provider, and it is what decides whether good customers finish signing up.

It is planned for per integration rather than generally. Timeout and retry behaviour is chosen for each, a payment stuck in between keeps an honest customer-facing state instead of guessing, and monitoring covers the money path first so you hear it from an alert rather than from social media.

Buy, if what you need is bookkeeping for a product whose money movements are simple and whose volumes are modest. There are decent ledger products and no prize for writing your own. Build when the money model is the product: several currencies with your own rates, funds held and released on conditions, fees split between three parties, or a settlement pattern nobody sells off a shelf. The case we are most often called in to fix is neither of those. It is a product that kept balances in its ordinary application tables because that was quick, then found eighteen months later that no two reports agreed. Describe your three most awkward money movements to us and we will tell you which side of that line you are on.

Mostly by deciding what you never touch. If card numbers pass through your servers, your compliance scope grows to include those systems and everything that can reach them, along with the assessment that comes with it. So the design goal is to keep them out: hosted fields or an element from your provider so the number goes from the customer's browser to the provider, tokens stored in place of card data, and nothing sensitive in logs, support tools, screenshots or a customer service mailbox. Those are engineering decisions taken at the start, not a certificate bought at the end. Get it right and your yearly obligation is short. Get it wrong and it becomes an assessment of your whole estate.

Both happen, most weeks, and a product that assumes otherwise will eventually confirm a payment it then has to reverse. Every callback is stored raw on arrival before anything acts on it, deduplicated on the provider's own identifier, and applied to a state machine that knows which transitions are legal, so a stale message about an earlier state is ignored rather than replayed over a newer one. Where a provider offers no ordering guarantee at all, we reconcile against their API or their settlement file instead of trusting delivery. Keeping the raw payloads matters as much as processing them, because when balances disagree the argument is settled by what actually arrived rather than by what your code decided it meant.

Longer than the integration, and it is the item plans underestimate most. A sponsor bank or a scheme will typically want your flows demonstrated in a sandbox, a defined set of test cases run and evidenced, your handling of the unhappy paths reviewed, and a production access slot scheduled with their team, all on their calendar rather than yours. Sandboxes also lie in small ways. They return responses your production traffic will not, and they almost never reproduce a timeout, which is the case you most need to have tested. So we build the failure handling against deliberately broken conditions of our own, and we ask for the certification checklist at the start so the queue is joined early rather than discovered late.