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.
- Return evidencedmerchant reference, in the casea person
- Refund postskeyed from the return referenceautomatic
- Principal reduced$800.00 becomes $440.00automatic
- Schedule recalculated4 × $200.00 becomes 4 × $110.00automatic
Juniper partial refund
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 installmentMerchant 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:
- reverse eligible unearned finance charge tied to the refunded merchandise;
- reduce outstanding financed principal;
- recalculate remaining installments;
- if the refund exceeds the outstanding obligation, leave a credit balance for eligible amounts already paid; and
- move any customer cash only through a
REFUNDfunding 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.