Refund a payout

A payout refund means all or part of previously released funding came back from its recipient or rail. It is not permission to reverse a disbursement merely because a purchase was cancelled.

On screen. Payout Reversal, in the Payments & credits column of the loan actions menu.

Money that came back from a payout

CommandPOST /v1/loans/{loanId}/transactions?command=payoutRefund

Case contextRequired; links the original funding

ApprovalMaker-checker parks it for a second approver

Ledger effectSet by product policy

UndoNone — re-releasing money needs a new funding

Evidence first, then posting

1. Funding POSTEDthe original payout settledautomatic
2. Return evidencedsource reference from the railwaits
3. Amount computedagainst the strict formula belowautomatic
4. Refund postsonly the evidenced amountautomatic

The case links refund to original funding

curl -X POST "$BASE/v1/loans/7204/transactions?command=payoutRefund" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_JUN_CANCEL_3" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: jun-payout-refund-77210" \
  -d '{
    "transactionDate": "2026-08-24",
    "transactionAmount": 1200.0,
    "note": "Merchant returned funds before fulfillment; return ach-credit-return-77210 against funding 5107.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30451,
  "changes": {
    "transactionDate": "2026-08-24",
    "transactionAmount": 1200.0
  }
}

Refund commands also accept native payment-detail fields recording how the money came back; every execution writes a governance record.

Verify before posting

Confirm from GET /v1/loans/7204/fundings/5107 what has already been refunded. The available amount is strict:

original settled payout
− prior posted payout refunds
− payout refunds in flight
= amount available to refund

The returned amount cannot exceed this result. Derive the Idempotency-Key from the return’s source reference so a provider return event and a manual record deduplicate to one posting.

Accounting and loan effect

Product policy decides whether the refund reverses disbursed principal, leaves an unapplied credit pending purchase cancellation, or funds another explicit action—read the posted transaction and the loan summary for the component effects.

For a fully cancelled Juniper purchase, closure still waits for the $240 down-payment disposition and any customer payments. Returning the merchant payout alone does not prove the customer has been made whole.

Partial and late returns

If installments have already posted, re-read the schedule for replayed allocation and any borrower credit that results. A late return after charge-off, write-off, or contract termination routes to specialist review in the case because accounting and reporting may span periods.

Never resend on uncertainty

If a return is reported but ledger posting fails, repair the single refund post through reconciliation. If the provider outcome is ambiguous, hold the recon exception open. Do not ask the recipient or rail to return funds again from an uncertain state.

Re-releasing money needs a new funding

If the returned funds were themselves reversed or re-released, record that as a new governed action with its own evidence; actual outbound money always moves through a new funding, never implicitly.