Products & templates

A product is the behavior contract behind every obligation. It supplies defaults and hard constraints for new loans; creating a loan resolves those terms into the contract, and the resolved facts stay with the loan.

Three product families

Family	Economic model	Schedule	Typical use
Consumer installment	Principal accrues interest and amortizes through installments.	Daily, weekly, biweekly, semimonthly, or monthly progressive schedule.	Personal and point-of-sale installment lending.
BNPL purchase plan	Merchant-funded purchase financing, with optional checkout down payment and consumer finance charges.	Short progressive schedule, often biweekly or monthly.	Pay-in-4 and longer purchase plans.
Merchant advance	Purchase of receivables for a purchase price; remittance follows verified sales.	Projected sales/remittance schedule, not fixed consumer installments.	Business-purpose working-capital funding.

Merchant advances are a separate product family. Selecting merchant_advance changes the allowed terms, lifecycle, accounting, reconciliation, and API resource; it does not toggle an installment loan into a commercial contract.

One aggregate, two blocks

A consumer product is created atomically at POST /v1/loanproducts with two blocks: the native engine settings and the LendEasy lmsConfig policy that governs disclosure and statements.

curl -X POST "$BASE/v1/loanproducts" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: create-harbor-product-01" \
  -d '{
    "fineract": {
      "name": "Harbor 18-month personal loan",
      "shortName": "HBR18",
      "currencyCode": "USD",
      "principal": 8400.0,
      "numberOfRepayments": 18,
      "repaymentEvery": 1,
      "repaymentFrequencyType": 2,
      "interestRatePerPeriod": 13.25,
      "interestRateFrequencyType": 3,
      "amortizationType": 1,
      "interestType": 0,
      "interestCalculationPeriodType": 1,
      "transactionProcessingStrategyCode": "advanced-payment-allocation-strategy",
      "loanScheduleType": "PROGRESSIVE",
      "isInterestRecalculationEnabled": false,
      "accountingRule": 1,
      "charges": [{ "id": 12 }]
    },
    "lmsConfig": {
      "productClass": "COVERED_CONSUMER",
      "aprEnabled": true,
      "aprRounding": "NEAREST_0_01_PERCENT_HALF_UP",
      "aprTolerancePolicy": "REGULAR",
      "statementEnabled": true,
      "statementLeadDays": 10
    }
  }'

{ "resourceId": 3 }

GET /v1/loanproducts returns the product list with each product’s lmsConfig and a derived configurationStatus—CONFIGURED or MISSING. A product whose LendEasy configuration is MISSING cannot originate loans. GET /v1/loanproducts/template returns the option catalogs, including the product-class, APR-rounding, and APR-tolerance options, and GET /v1/loanproducts/{productId} returns one product.

Updates replace the aggregate

PUT /v1/loanproducts/{productId} is a full replacement of both blocks—native settings and lmsConfig together. There is no draft, validate, or activate lifecycle and no product versioning: existing loans are unaffected because the terms they resolved at origination are frozen on the loan, not looked up from the product at servicing time. Treat edits to a live product as a governed operational change, because every loan created after the write uses the new behavior.

Consumer calculation settings

The native block pins the calculation choices that must not drift between schedule preview and servicing:

• repayment frequency (repaymentEvery plus its frequency type) and term;
• interest rate per period, declining-balance interest type, and the interest-calculation period;
• equal-installment amortization;
• transactionProcessingStrategyCode—the server owns the payment-allocation order for due, overdue, and in-advance money;
• loanScheduleType: "PROGRESSIVE" with interest recalculation disabled; and
• charges referenced by id from the charge-definition catalog.

Progressive schedules are required for consumer products in the public catalog. They recalculate after dated transactions and schedule modifications while preserving posted history.

Disclosure and charge policy

lmsConfig carries the Regulation Z posture: productClass: "COVERED_CONSUMER" marks the product as covered consumer credit, aprEnabled requires a finalized disclosure at approval, aprRounding pins the disclosed scale, and aprTolerancePolicy (REGULAR or IRREGULAR) records the accuracy class the product asserts.

Charge definitions live at /v1/charges and are themselves two-block aggregates: the native charge settings plus an lmsConfig with a financeChargeFlag (FINANCE_CHARGE, NOT_FINANCE_CHARGE, or EXCLUDED) and a legalBasis citation. The finance-charge flag is immutable once set—APR treatment never changes retroactively; only the legal basis may be corrected. A charge definition without its classification reports configurationStatus: "MISSING" and cannot be attached to products or loans, so an APR-enabled product can never reference an unclassified fee.

See APR & disclosures for Harbor’s worked calculation.

Statement and overpayment policy

statementEnabled schedules due-date statements for every loan on the product, and statementLeadDays sets how many days before each due date the statement job generates them. An optional overpaymentTolerance bounds how far a payment may exceed the outstanding balance before the overpayment guard rejects it.

For variable preauthorized consumer debits, the statement is the notice artifact, so the lead time must satisfy Regulation E § 1005.10(d): a FULL_DUE autopay enrollment is rejected unless the product’s statement lead leaves at least the ten-day advance-notice window. Per-rail payment failure handling is tenant-level policy, not product configuration—see autopay failure policies.

Merchant-advance settings

Merchant products configure purchase-price and purchased-amount bounds, remittance-rate limits, permitted sales sources, reporting cadence, projection method, reconciliation tolerances, grace windows, near-breach indicators, breach rules, and payment allocation. They do not expose consumer-only APR or installment-interest settings.