Skip to main content
This guide covers the building blocks of a card-based credit program on Lead: revolving credit lines, cards issued through your issuer processor, spend settling through the card networks, and the daily purchase of the receivables that spend creates. A card program is several interacting systems with real decision points, so this guide is organized around those decisions rather than one linear sequence.

​
How it works

The credit chain is the same as any lending program — Entity → Application → Account (credit_with_underwriting) → Balance — with structure: revolving, so repayments restore available credit. Cards are created at your issuer processor and reported to Lead as Card objects; spend settles with the networks through Lead’s Network Settlement process; and because Lead is the lender of record, network settlement originates receivables on Lead’s books, which are grouped into a daily sale you purchase — today via the Sales Request/Response file exchange, with a Sale API planned.

​
Example scenario

Fieldstone issues charge cards to small landscaping businesses. Bluebonnet Landscaping is approved for a $25,000 line; Fieldstone reports the application, opens a revolving balance, issues a card through its processor, and reports it to Lead via the Cards API. Bluebonnet spends $4,000 in week one; that spend settles through the networks and creates receivables at Lead, which roll into the daily sales Fieldstone purchases. Fieldstone services Bluebonnet’s balance and repayments through its daily files.

​
Objects involved

​
Before you start

  • Sandbox credentials with the lending-chain scopes plus card/read_write; an issuer-processor relationship (cards are created there — Lead’s Cards API is how you report them).
  • Use the Cards API Beta for new programs; the Cards file schema remains the path for existing file-integrated programs.
  • The receivables sale runs on files today. You acknowledge each day’s purchase through the Sales Request/Response exchange over SFTP — Sales Request file schema, Sales Response file schema, and how settlement amounts work. A sale API is planned: one daily sale object you review and accept in a single call, acceptance settling the funds (Platform Evolution). The cycle’s shape is unchanged across transports; build against the day’s sale as a unit.
  • Servicing (repayments, interest, fees) is reported via the daily Balance and Transaction files. The Accounts and Subledger Balance APIs, and the daily files, all have planned unified-model successors (user accounts, user balances, user transactions — Platform Evolution); same flows, migration in cohorts with notice.

​
The credit line

The origination chain matches Instant Loan Origination and Disbursement steps 1–4 with one change: the Balance uses structure: revolving — no fixed maturity or expected finance charge required; available credit is the live constraint, with the sum of posted card disbursement transactions capped by it and repayments you report restoring it. Decision point: charge-card (pay-in-full) and revolving-credit programs use the same objects; the difference is your repayment terms and servicing, not the object model.

​
Cards

Report each card your processor creates: POST /v0/cards { "account_id": "...", "form": "physical | virtual", "...": "..." } Cards are created active; manage the lifecycle through the dedicated activate/deactivate/close endpoints. Statuses describe your report — a card closed in error is correctable back to active. Keep status current promptly: Lead’s compliance oversight depends on it.

​
How spend settles

Authorization and settlement happen at your processor and the networks; funds move through Lead’s Network Settlement process. Your integration work is reconciliation: consume the transaction settlement data from your processor, submit the posted transactions with their network settlement date through the Transactions file, and then Lead will perform our Network Settlement Reconciliation.

​
Purchasing the day’s receivables

Network settlement originates receivables on Lead’s books; each business day, those past your program’s hold period are grouped into a single sale priced per how settlement amounts work — principal plus imputed interest for the hold period. You purchase the day’s sale as a whole: today by acknowledging it through the sales files, with the settlement amount moving from your settlement account. Treat it as a daily operational rhythm with a funded settlement account as the pre-check — the day’s purchase settles whole or not at all. When the sale API ships, the same cycle becomes a single accept call on a daily sale object; empty days will be represented explicitly, so a quiet day is distinguishable from a broken pipeline.

​
Servicing and reporting

Daily Balance and Transaction files carry repayments, interest, and fees. For revolving products the reported position is operationally load-bearing: available credit — which gates the next draw and authorization — is computed from what you report.

​
Getting started

Run the origination chain in sandbox with structure: revolving; exercise a multi-draw sequence including a draw rejected for exceeding available credit (a normal operating event, not an error); report a card via the Cards API and round-trip its lifecycle; validate a servicing file against the File Reference schemas. Today, with files, the sandbox coverage doesn’t include simulating network settlement, which means the sales process will not include any dependency on network settlement. However, once the Sale API launches, simulation will be available in sandbox. Receivables & the Daily Sale · Sales Settlement Amount · Network Settlement · Balances & Transactions · Cards · Launch a Debit Card Program · Instant Loan Origination and Disbursement If something in this guide doesn’t match what you see, contact your Lead team.