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.

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 shows assessed, paid, waived, and outstanding amounts. A caller cannot refund the assessed amount when only part was paid.

Post the ledger credit

The refund is the governed native command chargeRefund on the transactions route. A human call carries LendEasy-Case naming an open case when case management is enabled.

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 when the tenant records how the money will move. The command writes a governance record, and maker-checker can park it for a second approver.

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"—which starts in APPROVAL_REQUIRED and must be approved by a different user before submission. The funding moves money for the ledger effect this command created; it does not post a second ledger transaction.

Ledger posting alone does not prove cash was returned—track the funding to POSTED before telling the customer the money is on its way.

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 rather than posting a second credit. Distinct requests are validated against the charge’s current paid balance, so two refunds cannot consume the same $12.00.