Refund a charge · LendEasy Docs

Return a paid charge as an explicit ledger credit, capped by the net paid amount, with any outbound cash riding a separately approved refund funding.

A charge refund applies when money allocated to a charge must be returned. The ledger effect and the cash movement are deliberately separate: the governed command posts the credit, and a REFUND funding moves any money out.

Returning money already paid

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

Case contextRequired on human calls

ApprovalMaker-checker; a different user on the funding

Ledger effectA credit capped by the net paid amount

UndoNone — the transaction is never edited or deleted

Credit first, cash only if it must leave

Charge readassessed, paid, waived, outstandingautomatic
Credit postsreduces what the borrower owesautomatic
Funding approveda different user, before submissiona person
Funding POSTEDonly now has cash been returnedwaits

Ledger posting alone does not prove cash was returned; track the funding to POSTED first.

Available-to-refund calculation

Refundable charge amount

paid toward charge
− prior posted charge refunds
− refunds already in flight
= available to refund

Resultcurrent available amount

Read the applied charge first: GET /v1/loans/7204/charges/44. A caller cannot refund the assessed amount when only part was paid.

Post the ledger credit

curl -X POST "$BASE/v1/loans/7204/transactions?command=chargeRefund" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_HBR_PAYMENT_REVIEW_8" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hbr-charge-refund-2027-06-04" \
  -d '{
    "transactionDate": "2027-06-04",
    "transactionAmount": 12.0,
    "note": "Approved refund of returned-payment fee.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30427,
  "changes": {
    "transactionDate": "2027-06-04",
    "transactionAmount": 12.0
  }
}

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

Where the money goes

The credit first reduces what the borrower owes; a refund that exceeds outstanding obligations produces a credit balance on the loan. When cash must actually leave, create a REFUND funding against the loan—POST /v1/loans/7204/fundings with fundingType: "REFUND". It moves money for the ledger effect this command created; it does not post a second ledger transaction.

Accounting and replay

Re-read the loan’s transactions for the refund’s component allocation and journal references. If the source payment later returns through the provider flow, reconciliation prevents the combined return and refund from overstating the account benefit; the recon exception queue surfaces the conflict rather than normalizing it away.

Duplicate protection

Retrying with the same Idempotency-Key returns the original result. Distinct requests are validated against the charge’s current paid balance, so two refunds cannot consume the same $12.00.

There is no undo for a posted credit

A refund posted in error is corrected by a new governed action agreed in the case, chosen for its own economic meaning. If the REFUND funding has not been submitted yet, cancel it rather than sending cash you must then ask back.