Build vs. buy payout infrastructure

Your app -> ACH provider

The product team wants instant payouts. Another rail is added. Then push-to-card. Then fallback routing. Then returns, retries, reconciliation, tax data, and operations tooling. This page walks through what a complete build actually contains, so the build versus buy comparison is between two real systems, not between a demo and a brochure.

What a complete build actually requires

• Recipient model. Who is being paid? What destinations, verification data, tax data, and history belong to the recipient?
• Payout model. What is the difference between the amount owed, the payout, each payment attempt, and the final result?
• Routing. Which eligible rail should be used for each payment, and what happens when the first choice is unavailable?
• Reliability. How will the system handle timeouts, retries, idempotency, event processing, and duplicate prevention?
• Exceptions. How will failures, returns, unavailable routes, and manual reviews be represented?
• Finance. How will the ledger, settlement data, reconciliation, reporting, and exports work?

A project that begins with a single payment call can become a financial operating system. The sections below break down the pieces that surprise teams most.

Rails: each network is its own integration

There is no single wire that moves money. RTP, FedNow, Visa Direct push-to-card, and ACH are separate networks with separate message formats, operating windows, limits, and failure modes. Building means integrating each one you want, then keeping each integration current as the network changes.

The rails also behave differently. Instant rails typically land in about a minute when the recipient’s bank supports the rail, while ACH settles on standard ACH timelines and returns can arrive days later. Your routing logic has to know which rail each recipient can actually receive on and fall back cleanly when the first choice is unavailable. The tradeoffs are covered in ACH versus instant rails; a build has to encode all of them.

Bank integrations: you need a bank relationship

None of those networks accept a direct connection from a software company. Money moves through a bank, so a build needs a banking relationship: either a direct one, which involves diligence, ongoing oversight, and real minimums, or a sponsor bank partnership, which still takes months to establish and comes with continuing obligations. This is the part of the build that no amount of engineering speed compresses, because the timeline belongs to the bank, not to your team.

Compliance: KYC, KYB, and screening

Before the first dollar moves, the build needs to verify who it is paying. That means KYC for individuals, KYB for businesses, collecting tax identity data, and sanctions screening on every recipient, with a review queue for the matches that need human judgment. It also means tax reporting obligations that recur every January whether or not anyone budgeted for them. Compliance is not a launch task. It is a standing function with its own tooling and its own on-call.

Status architecture: statuses, webhooks, timeouts

A payout is not a request and a response. It is a state machine: created, screened, routed, submitted, settled, or somewhere in the exception branches. A build needs to define those states, consume the events each rail and bank emits, publish webhooks your own product can rely on, and decide what happens when an expected event never arrives. Timeout handling is where naive builds break first: a payment that is neither confirmed nor failed cannot be safely retried without idempotency, and cannot be safely ignored either.

Reconciliation and the ledger

Finance will ask a simple question: does what we think we paid match what actually left the bank? Answering it takes a double-entry ledger that records every movement, and a reconciliation process that ties ledger entries to bank statements and explains every difference. Skip this and month-end close becomes archaeology. In a serious build, the ledger is not a reporting afterthought; it is the source of truth the whole system writes to.

The operating cost: a team, not a project

The build estimate usually prices the first version. The real cost is the standing team: engineers who maintain rail and bank integrations as they change, an operations function that works returns, failures, and support escalations, and compliance staff who own screening and reporting. That team exists for as long as the system moves money. When you price the build, price year three, not the launch.

When building makes sense

Building can be rational when infrastructure ownership creates strategic value.

Examples include proprietary money flows, unusual routing economics, very large scale, deep internal payments expertise, or requirements that existing infrastructure cannot model well. If payments is the product, owning the layer can be the right call.

When buying makes sense

Buying is attractive when the payout layer is necessary but not the reason customers choose your product.

A sports platform wins through its sports product. A creator platform wins through its creator experience. A marketplace wins through its buyers and sellers. For those teams, integrating a payout API that already owns routing, retries, screening, and reconciliation turns a multi-quarter build into a normal integration.

If the team spends a year building retry logic, return handling, and reconciliation, ask whether that work improves the core product enough to justify the cost.

The hybrid model

Your product
Earnings
Contracts
Approvals
Business rules
      |
Payout infrastructure
Recipients
Routing
Rails
Failures
Reconciliation

The product determines why money should move.

The payout layer determines how to move it and record the result.

The decision matrix

Read the table honestly. Build wins on control and on flows a provider cannot model. Buy wins on time, coverage, and the operating burden. Most teams are not choosing between good and bad; they are choosing which set of problems they want to own.

The real question

Do not ask whether your engineers can integrate a payment API.

Ask whether you want to own everything that integration becomes over the next three years: the rails, the bank relationship, the screening queue, the ledger, and the team that keeps all of it running.