The payout stack: five layers of payout infrastructure

1. How much is owed?
2. Who should receive it?
3. Which route should the payment use?
4. Did the money move?
5. Do the financial records match the result?

That is the payout stack.

The payout stack architecture: five layers

Each question maps to a layer, and each layer feeds the next. This is the working shape of payout infrastructure: the same five layers, whether they run as spreadsheets and bank portals or as one connected system.

Layer 1  Calculate
Layer 2  Verify
Layer 3  Route
Layer 4  Send
Layer 5  Reconcile

The layers are ordered because each one depends on the output of the one above it. A mistake in an upper layer flows downward: a wrong amount gets routed and sent perfectly, and the error only surfaces at reconciliation.

If payouts are new territory, start with how payouts work from start to finish, then come back for the architecture. Here is each layer in detail.

1. Calculate

A payout starts with an obligation.

A sports platform may owe an athlete $750. A marketplace may owe a seller $4,218.37. A music company may need to split one pool of revenue across several recipients.

The first job is to get the amount right.

Artist          $6,500
Producer        $1,500
Manager         $1,000
Collaborator      $750
Platform          $250
               -------
Total          $10,000

If the calculation is wrong, a perfectly executed payment is still wrong.

The system should preserve the connection between the business event, the amount owed, the recipient, and the payment that satisfies the obligation.

2. Verify

Next, the system needs to know who is being paid and where the money should go.

A recipient record can include:

• legal name
• individual or business status
• verification status
• tax information
• bank account
• eligible card destination
• payout history

The recipient is not the payout. A recipient can receive many payouts over time.

Keeping those records separate gives the business a clean history of who was paid, where each payment went, and which recipient information was in force at the time.

3. Route

Common US payout routes include RTP, FedNow, push-to-card, and ACH.

The right route depends on the destination, network availability, speed, amount, cost, and program rules.

Payout: $750
     |
Destination: bank account
     |
RTP      yes
FedNow   yes
ACH      yes
     |
Selected route
RTP

A payout system should be able to choose among available routes instead of forcing every payment through one rail.

4. Send

Once the amount, recipient, and route are set, the payment instruction can be submitted.

Payout ID     po_8df72
Recipient     re_4712
Amount        $750.00
Rail          RTP
Status        processing

A useful status model can distinguish between created, processing, submitted, completed, failed, returned, and action required.

“Sent” is not enough. Finance and operations need to know what happened.

5. Reconcile

The last job is to connect the payment result back to the original obligation.

Reconciliation sits at the bottom of the stack because it depends on every layer above it: the obligation from layer one, the recipient from layer two, and the rail and result from layers three and four.

For any payout, the business should be able to answer:

• Why was this money owed?
• Which payment attempted to satisfy it?
• Which rail was used?
• Did the payment complete?
• Was it returned?
• Is anything still unresolved?

Obligation
Athlete payment, $750
        |
Payout
po_8df72, $750
        |
Rail
RTP
        |
Result
Completed
        |
Ledger
Obligation satisfied
        |
Reconciled

Without that connection, teams end up rebuilding the story across bank portals, spreadsheets, provider dashboards, accounting software, email, and Slack.

Where APIs fit in the stack

An API is how software drives the stack instead of a person driving each layer by hand.

Your system already knows the answers to the first two questions: who is owed money, and how much. A payout API takes those answers and handles the layers below: it selects the rail, submits the payment, and reports status back as it changes.

The reporting matters as much as the sending. When results flow back through the same interface that sent the payment, layer five can run continuously, payment by payment, instead of as a month-end matching project.

When manual workflows break

Most teams start with a manual version of every layer. A spreadsheet calculates. An inbox collects bank details. A bank portal sends. Someone matches statements against the spreadsheet at month end.

That works at low volume. It breaks in predictable ways:

• Volume. Fifty payouts a month fit in a spreadsheet. Five hundred do not, and every extra row is another chance for a copy-paste error.
• Cadence. Recipients start expecting payment days after the event, not weeks. A monthly manual batch cannot keep up.
• Failures. Returns and closed accounts arrive out of sync with the batch that caused them, and each one becomes a one-off email investigation.
• Records. The spreadsheet, the bank statement, and the accounting system slowly stop agreeing, and nobody can say which one is right.

When those symptoms appear, the question stops being whether to replace the manual stack and becomes whether to build or buy payout infrastructure.

Failure belongs in the model

A bank account can be closed. A network can be unavailable. A request can time out. An ACH entry can be returned. The same instruction can be submitted twice.

Those events should change the payout state and trigger a clear next action.

The system should know whether money moved before it decides to retry.

The outcome

The recipient should see one thing:

$750 received

Operations should see exactly how it got there.

Finance should see records that match.

Engineering should have one consistent model for recipients, obligations, attempts, statuses, and results.

That is the payout stack: calculate, verify, route, send, reconcile.