Declines, Retries and Disputes: Fintech Software Development Case Studies

Three builds from our developers' project history, and years of building and using Ukraine's instant-payment banking, add to a fintech team.

Since June 22, 2026, every non-consumer originator in the US ACH network has to run risk-based fraud monitoring under Nacha's new rules. In the euro area, banks have had to check a payee's name against the IBAN before each SEPA credit transfer since October 2025. Neither rule is about payments that go through. Both are about the ones that should not.

Fintech software development mostly involves handling those moments: declines, retries, disputes, mismatched records, and suspicious patterns. The case studies below come from our developers' project history: payment orchestration between a card gateway and an ERP, real-time fraud scoring under PSD2, and trade surveillance for brokers. As of October 2026, our developers' records list 94 fintech-tagged projects, and industry tags cover 67% of their projects. More context sits in our breakdown of where our engineers work across industries.

Why fintech software development is built around the payments that fail

Fintech software development centers on failure because a single payment passes through five stages, and each one can stop it. A card is authorized, the funds are captured, the money settles between institutions, the books are reconciled, and risk checks run around all of it. The happy path through those stages is short to code. Branches for timeouts, partial refunds, duplicate webhooks and declined authentications are where most of the engineering goes. Each stage also speaks its own standard, and a product often touches several of them at once.

The rails are still moving. The Federal Reserve switched its Fedwire Funds Service to ISO 20022 in a single-day changeover on July 14, 2025. Nacha's fraud monitoring rules reached every remaining non-consumer originator in a second phase effective June 22, according to Nacha. Verification of Payee now covers euro-area credit transfers and will reach the rest of the EU next, as PwC Legal summarizes. A team building payments today ships against rules that will change before the product does.

Payment orchestration between a card gateway and an ERP

Yurii F. was deputy team lead and a key .NET engineer on a payment platform that connects Braintree card processing with SAP Business One. The project began as a proof of concept and grew into a distributed production system. It covers the full card lifecycle inside the ERP, 3-D Secure for customer and merchant payments, tokenized cards, and reconciliation of what settled against what was invoiced.

Challenge: a web checkout and a desktop ERP in one transaction

The client's finance work ran in SAP Business One. Payments had to start from the ERP client, a browser-based web client, and a customer-facing payment page. Every outcome then had to land back in the ERP as a correct accounting entry. The gateway answers in seconds, while ERP writes go through SAP's Data Interface API. Putting both in one synchronous call would have tied checkout speed to the slowest part of the system, so the SAP calls had to leave the web request path.

Card rules added a second layer. A customer paying at checkout is a customer-initiated transaction, and under PSD2 in Europe it usually needs strong customer authentication through 3-D Secure. Subscription charges, or later captures that the merchant starts without the customer present, follow different rules. The platform had to tell these cases apart on every payment and authenticate each one the right way.

Approach: three services, a queue and a payment state machine

The team split the platform into three deployable services: a web application, an agent that talks to SAP, and a scheduled job runner. RabbitMQ connects them. The web layer accepts a payment request, hands the ERP work to the queue and answers the user without waiting for SAP. The agent then posts the SAP work into the ERP at its own pace.

Yurii owned the payment orchestration. It covers authorization, capture, refund and void through Braintree's GraphQL API, CVV checks, and card vaulting so that later charges use a token instead of a card number. Keeping raw card numbers out of the ERP also keeps the ERP out of the most sensitive part of the card data environment. For authentication, the platform handled three 3-D Secure cases: customer-initiated payments, merchant-initiated payments and requestor-initiated authentication, where the merchant authenticates a stored card without the cardholder in the session.

Asynchronous processing creates its own risk: a message can arrive twice, or a retry can fire after the first attempt already succeeded. Yurii built idempotency and safe retry patterns so that a repeated message produces the same result, never a second charge. Reconciliation logic then checks that what the gateway processed matches what the ERP recorded. In our view, these two mechanisms say more about whether a payment system can be trusted than any checkout screen does.

Finance teams also needed to see settlements. Yurii built a Settlement Dashboard search with cursor pagination, deduplication and bulk enrichment across SAP HANA and Microsoft SQL Server. A query over many settlements stays fast and returns each transaction once. He also supported the move to .NET 8 and wrote tests around the payment flows.

Result: from proof of concept to a production payment platform

The platform went from a proof of concept to a production system with an SAP add-on, a web client, backend services, a message layer and a customer payment page. The project record contains no transaction volumes or before-and-after figures, so we report the architecture rather than invent a number.

More fintech work: fraud scoring and market surveillance

Payment orchestration decides whether money moves correctly. The next two cases sit one step further out, where systems decide whether it should move at all, and whether a trade was what it claimed to be.

PSD2 fraud monitoring in real time

Alex K., now the CTO of Cortance, led a real-time risk management system that detects and blocks fraud on online banking accounts and payment cards. He designed the full architecture and led the team. The system monitors transactions as they happen, flags suspicious activity and possible money laundering, and raises alerts based on known fraud patterns and dynamic parameters.

Two design choices carry most of the weight. Bank staff create their own rules, actions and reports through the interface, so a new fraud pattern becomes a configuration change instead of a release. The system also integrates with an Access Control Server, the issuer-side 3-D Secure component that authenticates cardholders, so risk decisions and authentication sit in one flow. Laravel, Vue.js, PostgreSQL, Redis and WebSockets made up the stack, with live monitoring and alignment to PSD2 and ISO standards. Strong customer authentication under PSD2 requires two of three independent factors: something the customer knows, has or is.

Trade surveillance for brokers and compliance teams

Razmik P. built surveillance features in Python for a trade monitoring product that brokers' supervisors and compliance officers use to find and act on market abuse. The product ran on a high-performance tick database and stream-processing platform, which matters because surveillance has to read every order event, not a daily summary.

Built-in alerts covered layering and spoofing, quote stuffing, wash trading and marking the close. Spoofing means placing orders the trader does not intend to fill, to push a price. Wash trading means trading with yourself to fake volume, and marking the close means trading near the close to move the closing price. Clients could also write custom alerts on top of the built-in set, and case management let compliance staff investigate a flag from alert to decision.

Results at a glance

Each case covers a different kind of failure in the money chain that fintech software development must address. None of the records includes measured outcomes, so the table compares what each system was built to catch.

What Ukraine's banking practice adds to a fintech build

Ukraine's banking system already runs on the features many markets are still adding. Instant credit transfers have been live in the National Bank's payment system since December 2024, settling in about 10 seconds, around the clock, according to the NBU. The NBU's BankID system handled 27.7 million identifications in the third quarter of 2025 through 39 identifier banks, the Association of Ukrainian Banks reported. NBU data also shows that 95.5% of payment card transactions in 2025 were cashless.

Yevhen Vavrykiv, CEO of Cortance, sees that background in client work. Many countries are only now building out their fintech sector, he says, while in Ukraine it is already highly developed. People move money through instant transfers, use flexible banking apps, take loans and credit online, and sign in to services through their bank. A large part of our network is based in Ukraine and builds and uses that system every day. So beyond following a client's vision, they can propose solutions from their own experience.

In fintech software development, that experience shows up as early questions. An engineer used to ten-second transfers designs confirmation and retry behavior before the first screen is drawn. Someone who signs in to government services through a bank account treats bank-grade identity as a building block for onboarding, not an add-on. Developers who have built online lending know that every automated credit decision needs an audit trail that a regulator can read.

The stacks our fintech developers work in

Fintech software development requests rarely share one stack, and the project records above show why. Payment and ERP integration often runs on .NET, as in the flagship case. Bank payment services and trading platforms in our developers' records lean on Java with Kafka, while quantitative research, market data and surveillance lean on Python. Lending and banking platforms appear on PHP and Laravel, and identity verification flows on Node.js. For fintech requests, we match developers who have fintech project experience in .NET, Java, Python, PHP/Laravel and Node.js.

Four questions test that experience quickly on a first call:

1. How did your system stop a retried request from charging the customer twice?
2. Which records did you reconcile, against what, and who handled the mismatches?
3. Where did card or account data live, and what did tokenization keep out of scope?
4. Which regulation shaped a design decision you made, and what did you change because of it?

Fintech software development FAQ

1. CIT vs MIT: when does a stored-card payment need strong customer authentication? A customer-initiated payment generally needs strong customer authentication under PSD2, unless an exemption applies. Payee-initiated payments made under the customer's agreement, with no action from the customer, are not subject to it, according to an EBA answer. Charges without such an agreement do not qualify.
2. What does PSD2 strong customer authentication require? PSD2 strong customer authentication requires at least two independent factors from three categories: knowledge, possession and inherence. Knowledge is something the customer knows, such as a PIN. Possession is something the customer has, such as a phone, and inherence is something the customer is, such as a fingerprint. 3-D Secure is the usual way to apply it to online card payments.
3. What do Nacha's 2026 fraud monitoring rules require? Nacha's 2026 fraud monitoring rules require ACH participants to use risk-based processes to identify entries initiated due to fraud. Phase one applied from March 20 to all ODFIs and to the largest originators and receivers. The second phase, effective June 22, removed the volume threshold for the remaining non-consumer originators and third parties.
4. What is Verification of Payee in SEPA payments? Verification of Payee is a free check that compares a payee's name with the IBAN before a SEPA credit transfer is authorized. The bank returns a match, a close match, no match or a note that the check was not possible, and the payer still decides whether to send. Euro-area banks have offered it since October 9, 2025, and the rest of the EU follows from July 9, 2027.
5. What does trade surveillance software detect? Trade surveillance software detects order and trading patterns that suggest market abuse. Typical alerts cover spoofing and layering, quote stuffing, wash trading and marking the close. Compliance teams then review each alert in a case management workflow, and good systems let them add custom rules without waiting for a vendor release.

Building for the transaction that goes wrong

The three systems above share one design habit: they treat the failed, repeated or suspicious transaction as the main case, not the exception. That habit is what separates fintech software development that survives an audit from code that only passes a demo. New rules on both sides of the Atlantic are pushing every fintech software development team in the same direction.

Before hiring for a fintech build, list the failures your product must handle and the standard each one falls under. Then ask every candidate to walk through a past project where they handled the same failure. The same test works for full development vendors, such as those in our comparison of fintech software development companies under $150 an hour.