Skip to main content
A user credit balance is the loan or line of credit you extend to one of your customers. You create one with POST /v2/user_accounts/{user_account_id}/user_credit_balances and read it with GET /v2/user_credit_balances/{id}.
A revolving user credit balance returns the same shape. Its details holds only structure and, if you sent it, repayment_details.

Fields

The position blocks

All amounts are signed integers in minor units. 1500 is $15.00. Lead maintains amount_breakdown, rewards, dispute, and charge_off from the user credit transactions you post. You maintain past_due with PATCH. The User Credit Transaction Object page lists which user credit transaction types move each block.

amount_breakdown

rewards

dispute

charge_off

past_due

The interest block

Send all three fields on create. Rates are decimal strings.

The details block

All five non_revolving fields are required, including expected_finance_charge_amount, which is easy to miss.

details.repayment_details

Create and update

POST /v2/user_accounts/{user_account_id}/user_credit_balances requires an Idempotency-Key header. The request body takes these fields from the object: name, currency_code, interest, autopay_method, details, and metadata. Leave out everything else. Lead sets it, and rejects a request that sends it.
  • Lead validates the request against the parent user account in the path. The user account must exist, be active, and have the credit_with_underwriting or credit_without_underwriting feature. If it is not active or lacks a credit feature, Lead returns a 422 with operation_not_allowed.
  • name, currency_code, all three interest fields, autopay_method, and details.structure are always required.
  • The non_revolving fields in the details block are required for non_revolving and rejected for revolving.
  • New user credit balances start in active with all amounts at zero.
  • Reusing an Idempotency-Key with the same body returns the original user credit balance. Reusing it with a different body returns a 422 with idempotency_request_inconsistent.
PATCH /v2/user_credit_balances/{id} changes only the fields you send. Idempotency-Key is required on create and required on PATCH and the status endpoints. See Idempotency. You can change:
  • autopay_method and metadata. Send "metadata": null to clear it.
  • past_due and every field inside it.
  • interest.rate and interest.effective_rate.
  • details.repayment_details, for any structure.
  • details.expected_maturity_date and details.term, for non_revolving only.
PATCH has these limits:
  • You cannot change amounts other than past_due. Post a user credit transaction instead.
  • You cannot change name, currency_code, interest.effective_apr, details.structure, details.max_funding_amount, or details.expected_finance_charge_amount.
  • You cannot change status. Use the status endpoints.
  • You cannot update a closed or reporting_stopped user credit balance. Lead returns a 422 with operation_not_allowed. You can still update an inactive one.
  • If another request changed the user credit balance after yours was received, Lead returns a 409 with object_modified_concurrently. Retrieve the user credit balance and retry.

Coming from the Subledger Balance API

Most terms carry over. These are the fields that differ: