The Payout Stack

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.

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.

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.

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.