The Hidden Cost of Building Bank Integrations Yourself

When an engineering team integrates their first payment provider, the project usually looks manageable. You are connecting to a documented API, handling a defined set of response codes, and testing against a sandbox environment that mostly matches production. Two to three weeks of engineering time, a few edge cases to handle, and it is done.

The cost accounting for that first integration is straightforward: engineering hours plus the time to write tests and documentation. For many teams, it comes to somewhere between 80 and 150 hours of engineering time, depending on the complexity of the provider's API and the team's familiarity with payment concepts. That is a visible, bounded cost that shows up in a sprint or project tracker.

The problem is that this visible build cost is only a fraction of the total economic cost of a bank integration. The rest is maintenance overhead that arrives steadily over the following years and is rarely assigned to the integration project.

What the Build Cost Understates

Every bank integration has a lifecycle that extends well beyond the initial build. The costs that do not appear in the project estimate include the following.

API version updates. Banks update their APIs, sometimes with deprecation notices that give you three to six months to migrate, sometimes with shorter timelines. Each update requires engineering time to review the changelog, assess the impact on your integration, update your code, run regression tests, and deploy. For a well-maintained API, this might be a few hours per update. For a poorly documented update that changes error handling semantics, it can take significantly longer.

Webhook reliability work. Payment provider webhooks fail. They fail because of network issues, because the provider's delivery system has a bug, because your receiving endpoint has a timeout during a deployment. Each webhook failure is a payment event that your system did not process. Building reliable webhook handling requires idempotency logic, retry handling, out-of-order delivery handling, and monitoring for delivery gaps. Most teams do not build this comprehensively during the initial integration; they discover the gaps during the first production incident.

Error handling depth. The initial integration handles the happy path and the most common error codes. Over time, production exposes a long tail of edge cases: the error code that appears only during end-of-day settlement windows, the response format change that only affects transactions above a certain amount, the timeout behavior that is different for specific corridors. Each of these requires an engineering investigation and a code change.

Reconciliation logic. When a bank's settlement report format changes, or when their fee structure changes in a way that affects expected settlement amounts, your reconciliation logic breaks. Someone has to investigate why amounts are not matching, trace it to the format change, update the parser, and verify that historical records are still valid.

The Third Integration Reveals the Pattern

The true economics of DIY integrations become visible when you add the third provider. By this point you have two integrations in production, each with its own maintenance cadence. Adding a third means that the annual maintenance overhead now applies to three integrations, and the incremental cost of each new one compounds the base load.

More concretely: each provider has its own API changelog to track, its own webhook format, its own error handling nuances, and its own settlement report format. Each of these is a surface that can change, requiring engineering attention. Three providers means three surfaces. Five providers means five. The maintenance burden scales linearly with provider count in a way that the initial build cost does not communicate.

There is also a knowledge concentration problem. The engineer who built the first integration understands its quirks. When they are no longer on the team, that knowledge needs to be reconstructed when the next issue occurs. With three or four proprietary integrations, the institutional knowledge overhead grows, and the cost of turnover or team growth becomes higher because new engineers need to understand multiple integration patterns simultaneously.

The Normalization Tax

Each bank speaks a slightly different dialect of payment data. Transaction identifiers use different formats. Status values use different vocabularies (one bank uses "PROCESSING," another uses "PENDING," another uses "IN_FLIGHT," all for the same state). Amount fields may include or exclude fees. Timestamp formats vary. Currency handling varies for multi-currency accounts.

When you build multiple direct integrations, you are implicitly building a normalization layer every time you add a new provider. You write code to map that provider's statuses to your internal model, to parse their timestamp format, to handle their fee inclusion convention. This normalization code is usually written in the context of a specific provider integration, which means it is scattered across your codebase and often inconsistently applied.

The normalization tax is invisible when you have one integration. It becomes significant when you have four, because the differences between provider data models are larger, and the inconsistency in how you have handled normalization creates bugs that surface during reconciliation or reporting.

What the Alternative Looks Like

The alternative is a single integration point that abstracts over provider-specific details. Your application calls one API surface, receives normalized responses, and does not need to understand whether a transaction went through FAST, DBS PayNow, or a cross-border wire provider. The normalization and provider-specific handling lives in the integration layer, not in your application.

This is the model Checker implements. A platform integrating with Checker makes one API call to route a payment and receives a normalized response regardless of which underlying provider was selected. Provider-specific error handling, webhook format differences, and reconciliation format parsing all happen inside Checker. When a provider updates its API, Checker updates its integration; the platform's code does not change.

We want to be honest about what this does not solve. Using a payment orchestration layer does not eliminate the need to understand payment concepts or to make architecture decisions about how payments fit into your data model. You still need to handle webhook delivery reliability on your end, because your webhook receiving infrastructure can fail regardless of who sends the webhook. You still need to think carefully about idempotency. The orchestration layer removes the per-provider complexity, not the fundamental engineering discipline that reliable payment processing requires.

The Build Decision Framework

The question of whether to build direct integrations or use a layer like Checker is worth thinking about honestly rather than defaulting to one answer.

Build direct if: you have a very small number of providers (one or two) that you are confident will not grow, you have specific integration requirements that an orchestration layer cannot meet, or payment infrastructure is a core differentiator in your product that requires deep control of the integration details.

Use an orchestration layer if: you expect to add providers over time, you have a small engineering team where maintenance overhead is a real constraint, you need multiple providers for redundancy or cost optimization, or your team's expertise is in your product domain rather than in payment infrastructure engineering.

The framework reduces to one question: is the engineering time you would spend building and maintaining direct integrations better spent on your actual product? For most growing platforms where payments are infrastructure rather than product, the answer is usually yes, and the cost of DIY integrations is more visible once you account for the maintenance tail rather than just the initial build.

The first integration always looks like two weeks. The true cost is the decade of maintenance that follows it, multiplied by the number of providers you end up with.