LendEasy/Docs
Get API keys
GuidesLoansRecord a merchant refund

Record a merchant refund

Apply a full or partial purchase refund to a BNPL loan, recalculate unearned cost, reshape future installments, and route any borrower cash separately.

A merchant refund is value returned by the merchant for the financed purchase. It is not a borrower payment and not a lender goodwill credit. The governed command applies product-specific allocation to the purchase obligation, and the merchant evidence lives in the case.

Juniper partial refund

JUNIPER · FICTIONAL EXAMPLE

Juniper SplitPay

Promotional BNPL purchase

Purchase price
$1,440.00
Checkout down payment
$240.00
Amount financed
$1,200.00
Finance charge
$0.00
Schedule
6 × $200.00 biweekly
Disclosed APR
0.000%

Assume the $240 checkout down payment and first two $200 installments have posted. Financed principal remaining is $800. The merchant returns $360 for part of the order.

Measure Before Refund After
Financed principal remaining $800.00 −$360.00 $440.00
Remaining installments 4 × $200.00 Recalculated 4 × $110.00
Customer cash payout $0.00 $0.00 $0.00

Juniper schedule after merchant refund

$800.00 outstanding principal − $360.00 merchant refund = $440.00
$440.00 ÷ 4 remaining dates = $110.00 per installment
Result4 × $110.00

Execute

The refund is the governed native command merchantIssuedRefund. A human call carries LendEasy-Case naming an open case when case management is enabled; the case holds the merchant identity, return reference, and settlement evidence.

curl -X POST "$BASE/v1/loans/7204/transactions?command=merchantIssuedRefund" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_JUN_RETURN_7" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: jun-merchant-refund-rma-48192" \
  -d '{
    "transactionDate": "2026-09-30",
    "transactionAmount": 360.0,
    "note": "Partial purchase return, merchant reference return-RMA-48192.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'
{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30447,
  "changes": {
    "transactionDate": "2026-09-30",
    "transactionAmount": 360.0
  }
}

Refund commands also accept native payment-detail fields when the tenant records how the merchant money settled. Every execution writes a governance record, and maker-checker can park the command for a second approver.

Allocation order

The product pins the refund order. A common strategy is:

  1. reverse eligible unearned finance charge tied to the refunded merchandise;
  2. reduce outstanding financed principal;
  3. recalculate remaining installments;
  4. if the refund exceeds the outstanding obligation, leave a credit balance for eligible amounts already paid; and
  5. move any customer cash only through a REFUND funding with its own approval.

Re-read the schedule after posting for the recalculated installments. The command never assumes the entire merchant refund should be paid in cash to the customer.

Interest-bearing purchase plans

For a loan with interest, the ledger recalculates future interest and any policy-defined interest refund from the reduced balance and transaction date. That amount is an explicit transaction component; it is not hidden inside principal. Finalized historical disclosures remain immutable, while post-consummation notice policy is evaluated.

Full refund

A full merchant refund can reduce outstanding purchase principal to zero, but the loan closes only after all related funding, down-payment, fees, payments in flight, and customer credits reconcile. A checkout down payment returned by the merchant or lender has its own actual money path.

Duplicate and evidence controls

Keep the merchant return reference in the note and the case, and derive the Idempotency-Key from it—a retried webhook or double-keyed entry then returns the original result instead of posting twice. A second refund with the same reference but a different amount is a reconciliation conflict to resolve in the case, not a second posting.

Undo

There is no undo command for a merchant refund. If the merchant reverses their refund, record the correction as a new governed action with the new source reference, linked through the same case.

Unified search across guides, recipes & the API referenceEsc