Issue a cash refund · LendEasy Docs

Post an approved cash refund on the ledger and settle money back to its recipient through a separately approved refund funding.

A cash refund moves money out. It requires both a ledger basis—why the amount is owed—and a verified payout path. The two are deliberately separate operations: the governed command posts the ledger effect, and a REFUND funding moves the money.

Ledger effect and cash, kept apart

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

Case contextRequired on human calls

ApprovalMaker-checker on the command; a different user on the funding

Ledger effectOne refund transaction; the funding posts no second one

UndoNone — cancel the funding, then correct in the case

From an approved basis to settled cash

Basis in the caseaccount credit, overcollection, settlement correction, charge-refund excessa person
Refund poststhe ledger effect, not the moneyautomatic
Funding approveda different user than its creatora person
Rail settlesSUBMITTED to POSTEDwaits

The command cannot create refundable value from a note — the basis is evidenced and approved in the case before anything posts.

Post the ledger effect

curl -X POST "$BASE/v1/loans/7204/transactions?command=refundByCash" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_HBR_REFUND_9" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hbr-cash-refund-2027-06-05" \
  -d '{
    "transactionDate": "2027-06-05",
    "transactionAmount": 63.20,
    "note": "Verified overpayment refund.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30441,
  "changes": {
    "transactionDate": "2027-06-05",
    "transactionAmount": 63.20
  }
}

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

Move the money

Outbound cash rides a refund funding:

curl -X POST "$BASE/v1/loans/7204/fundings" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_HBR_REFUND_9" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hbr-cash-refund-funding-2027-06-05" \
  -d '{
    "amount": "63.20",
    "currency": "USD",
    "fundingType": "REFUND",
    "recipientType": "BORROWER",
    "recipientRef": "412",
    "instrumentId": 704,
    "rail": "ACH",
    "reason": "Verified overpayment refund per case."
  }'

The funding starts in APPROVAL_REQUIRED and settles through SUBMITTED → PROCESSING → SETTLED_PENDING_POST → POSTED.

Recipient controls

The selected instrument must belong to the entitled recipient and be active and verified; DISBURSEMENT_HOLD restrictions block funding creation. Changing the destination means cancelling the funding before submission and creating a new one—nothing is redirected in flight. Masked destination details appear in review; raw account data does not.

Failure handling

A failed payout does not automatically create another payout. Retry with a new funding linked to the same case, and only after the provider outcome is definitive. If cash settled but ledger posting failed, the funding lands in POSTED_FAILED_REVIEW and the posting is repaired—money is never sent twice on uncertainty.

No single record proves the refund

The completed refund links across the ledger transaction, governance record, funding approval and settlement, instrument mask, customer notice, and reconciliation result—each readable from its own API, all joined through the case.

A settled refund is not clawed back by command

Before the funding is submitted it can be cancelled and the ledger effect corrected by a new governed action agreed in the case; once cash has settled, recovering it is a separate, separately evidenced action rather than a reversal of this one. The refund transaction, its funding, and their governance records stay readable either way.