Payouts 101

The direction matters.

Checkout
Customer -> Business

Payout
Business -> Recipient

Checkout solves the problem of collecting money. Payouts solve the problem of getting money out to the right people and keeping a clean record of what happened.

A payout starts with money owed

Suppose a creator earns:

Content revenue      $1,200
Affiliate revenue      $425
Bonus                   $75
                    -------
Total                $1,700

Before the platform sends $1,700, it needs to know that $1,700 is actually owed.

For a small program, that calculation may live in a spreadsheet. For a larger program, earnings, splits, commissions, deductions, refunds, and adjustments can turn calculation into its own system.

The recipient comes next

The payout needs a destination.

That could be a bank account or an eligible card destination. The platform also needs to associate the destination with the correct person or business.

Recipient data changes. People switch banks. Cards expire. Businesses update legal information. One recipient may be paid by several programs.

A good recipient record is reusable and separate from any single payout.

Then the system picks a rail

Money moves over a payment network.

For US payouts, common routes include RTP, FedNow, push-to-card, and ACH.

Not every destination supports every route. The system may need to check availability and choose the best eligible option for that payment.

Status matters

A payout is not simply paid or unpaid.

A useful status model can include:

Created
Processing
Submitted
Completed
Failed
Returned
Action required

If an API request times out, the lack of a response does not prove that the payment failed. The payment may have succeeded while the response was lost.

The system needs to determine the real status before it sends money again.

Returns are part of the lifecycle

Some rails can produce a return after the original payment was submitted.

ACH uses standardized return codes to explain what happened. An account may be closed, an account number may be invalid, or the receiving institution may be unable to locate the account.

The payout record should capture the return, update the financial state, and tell operations what to do next.

Reconciliation closes the loop

Suppose a business intends to send 10,000 payouts totaling $4.8 million.

Finance needs to know how much completed, how much failed, what was returned, what remains pending, and whether the ledger matches the external financial activity.

That is reconciliation.

What we intended to pay
          |
What actually settled
          |
What the ledger records

When those records agree, the payout is closed.

The full lifecycle

Money is owed
     |
Amount calculated
     |
Recipient identified
     |
Destination selected
     |
Rail selected
     |
Payment submitted
     |
Status tracked
     |
Exceptions handled
     |
Result reconciled

The recipient sees the last step. The payout operation owns everything before it.