Two Things Fintech Backends Get Wrong

KingCodex — Sat, 11 Jul 2026 16:41:07 +0000

Most backend tutorials stop at "hash the password, you're secure now." That's good advice for authentication. It's not much use for the rest of a payment system, where you're dealing with data you actually need back and events that don't politely arrive exactly once.

I work on payment infrastructure. Two problems come up constantly here that I almost never see discussed outside of "we had an incident" postmortems: encrypting sensitive fields correctly and making webhook handlers actually idempotent instead of just idempotent-looking.

Encryption: the part hashing can't help you with

Password hashing works because it's one-way. You never need the plaintext back. You just need to compare a new hash against the stored one.

Bank account numbers don't work like that. Neither do BVNs or NINs. You need the original value later, which means encryption has to be reversible. Once that's true, the security story depends far more on how you manage your encryption keys than on which algorithm you picked.

For a while I didn't think much about which AES mode to use. AES is AES, right?

It isn't.

AES is just the block cipher. The mode of operation determines whether your ciphertext is tamper-evident, and that matters a lot.

CBC mode encrypts data just fine, but it doesn't authenticate anything. If someone flips bits in the ciphertext, CBC will happily decrypt it into corrupted plaintext and hand it back to your application without complaint.

It gets worse. If your decryption path leaks any information about whether padding was valid, whether through different error messages, timing differences, or different HTTP status codes, an attacker can use that signal to recover plaintext one byte at a time without ever knowing your key.

This isn't hypothetical. It's the same class of vulnerability behind the ASP.NET ViewState attack in 2010 and attacks like Lucky Thirteen and POODLE against TLS.

Using CBC without a separate HMAC in an encrypt-then-MAC design is essentially waiting for someone to make a mistake elsewhere in the system.

GCM avoids this by providing authenticated encryption.

Instead of producing only ciphertext, it also generates an authentication tag. During decryption, the tag is verified before any plaintext is released. If verification fails, decryption stops immediately. No plaintext is exposed and no padding information leaks, so there is no oracle for an attacker to exploit.

For anything sensitive that needs to be decrypted later, such as account numbers, BVNs, or NINs, AES-256-GCM is a solid default.

In a NestJS + TypeORM application, I prefer hiding the encryption behind a transformer or subscriber so the rest of the application works with plaintext objects in memory without worrying about encryption details.

The difficult part isn't calling the encryption function. It's key management.

You need versioned encryption keys so records encrypted years ago with key v1 can still be decrypted after you've rotated to v3.

One rule that's worth remembering:

Never reuse the same key and nonce combination with GCM.

Do it once and you don't just weaken the encryption. You can completely compromise its security.

Idempotency: the database constraint isn't enough

Payment providers retry webhooks.

That's not a bug. It's part of the contract.

If your endpoint times out or returns an error, providers assume they don't know whether you processed the event successfully, so they try again. If your handler isn't safe to execute multiple times, one temporary network failure can become a duplicate credit, duplicate notification, or duplicate payout.

The obvious solution is adding a unique constraint on the event ID.

That's necessary.

It isn't sufficient.

A common implementation looks like this:

Check whether the event already exists.
If it doesn't, process the webhook.
Record the event as processed.

The problem is that two copies of the same webhook can arrive almost simultaneously.

Both requests check the database.

Both see that the event doesn't exist.

Both perform every side effect, including sending emails or calling external APIs.

Only afterward does one insert fail because of the unique constraint.

The duplicate database row is prevented.

The duplicate email already went out.

The fix is making the claim atomic before any side effects happen.

Instead of checking first, attempt the insert immediately:

INSERT ... ON CONFLICT DO NOTHING

If the insert succeeds, you won the race and can continue processing.

If it affects zero rows, another worker already owns the event. Return success and stop.

Redis follows exactly the same principle.

Don't do:

GET
SET

Do:

SET webhook:{event_id} 1 NX EX 86400

The "NX" option makes the claim atomic. "GET" followed by "SET" has the same race condition as checking the database before inserting.

There are two more lessons that only really stick after production incidents.

First, don't keep your claim and network calls inside one long-running database transaction.

If a third-party API takes ten seconds to respond, you've just held database locks open for ten seconds. Under load, those blocked transactions pile up surprisingly quickly.

Second, claiming the event doesn't mean the work is finished.

If your process crashes after claiming ownership but before completing the work, every retry will see the existing claim and skip the event entirely.

A more reliable approach stores a status such as "pending", "processing", and "done" instead of a simple boolean.

Another common solution is the outbox pattern, where the claim and the outbound work are committed in the same transaction, then a separate worker performs the external side effects.

Why write this down?

None of this is especially complicated.

That's exactly why it's easy to ignore.

The happy path works.

Your local tests pass.

Your demo behaves perfectly.

The problems only appear once you're dealing with real retries, real concurrency, and real production traffic.

By the time they appear, they're usually customer support tickets instead of code review comments.

If you're building anything that handles money or personally identifiable information, both of these should be defaults from day one rather than security improvements you hope to add later.

DEV Community: KingCodex

Two Things Fintech Backends Get Wrong