LendEasy/DocsLMS + Servicing·v1
Start integrating
Guides›Loans›Record 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.

On screen. Merchant Credit, in the Payments & credits column of the loan actions menu.

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

Merchant identity belongs to the case

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 recording how the merchant money settled; every execution writes a governance record.

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.

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

Derive the Idempotency-Key from the merchant return reference—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.

A reversed merchant refund is a new posting

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