Partner Credit Lines

DayZero keeps the credit ledger for a partner's card-backed lending product. The partner builds the merchant interface, executes every movement of money through its own processor, and owns the lending decision, which it records on the assessment (in the console or with the API). DayZero recognises each posted card transaction, originates the loan, computes fees, interest, balances and payoff figures, allocates payments, closes the month, produces statements, posts the accounting, and queues issuer controls derived from committed available credit. Issuer delivery is asynchronous: a saved balance or queued control is not confirmation that a card's limit has changed.

Nothing here moves money. Read every "payment" below as recording and calculation, never as a transfer.

Every amount is in integer cents. 4545000 = $45,450.00. Every figure the merchant sees is returned by the API; never derive balances, due dates, or statuses in the client.

Connecting

https://api.ondayzero.com/api/v1/credit/...
Authorization: Bearer dz_your_token_here       # token type "api"
x-business-id: YOUR_BUSINESS_ID                # the operator (lender) business
Content-Type: application/json

A token minted for exactly one business may leave out x-business-id; that business is used. When the header is sent it wins, and one outside the token's businesses is 403. A token for several businesses, or none in particular, must send it (401 otherwise).

Before a test run, check which book you are on: GET /credit/environment returns { "business_id", "sandbox", "sandbox_business_id", "live_business_id", "programs": [{ "id", "display_name", "issuing_enabled", "issuing_provider", "issuing_provider_mode" }] }. sandbox is true on a sandbox business, and issuing_provider_mode is mock for a program whose cards come from DayZero's in-memory test issuer and live otherwise. Assert on both before you push money-shaped data. On a live business with a paired sandbox, sandbox_business_id names it; on a provisioned sandbox, live_business_id names the live business it rehearses (both are null otherwise). See Sandbox.

Tokens are issued under Settings › Developers, and they need two-factor authentication on the DayZero account that owns them: minting or rotating one needs a verified second factor, and a token stops working (403, AUTH_085) if its owner later removes their second factor. See API tokens. API access is off by default for every account: ask for it under Settings › Developers (POST /api/v1/tokens/access-request with use_case_kind, one of internal_automation, reporting_sync, firm_client_workflows, product_integration, ai_agent, migration, evaluating or other; use_case is optional with a listed kind and must be at least 20 characters without one or with other; company_name is optional). An owner or admin of a business with the CFO Suite add-on who has two-factor authentication enrolled is approved immediately (and, if they never asked, on their first API use); anyone else waits for a DayZero operator to decide the request, and you are emailed either way; GET /api/v1/tokens/access reports where it stands. Until it is approved, minting a token or registering an API client is 403 (AUTH_069); the sandbox can still be provisioned meanwhile, with Create without token (see Sandbox). The credit surface sits behind the CFO Suite add-on and returns 403 (BILLING_003) until it is enabled for the business; the partner_program plan includes it (see Billing and token access).

Every response is wrapped: { "success": true, "message": null, "code": null, "data": { ... } }. Unwrap data before use.

Every credit refusal carries a machine-readable code beside the message. Match on code: the message text may change between releases, the codes are stable. Per-section tables below repeat the codes that section raises.

Timeouts and retries

Requests complete well inside 30 seconds; treat anything longer as a timeout. A 429 was refused before anything ran (see Rate limits): retry it after Retry-After. After a timeout, a dropped connection or a 5xx the request may have been applied, so retry it with exponential backoff (the first attempt and then five retries, six attempts in all, waiting 1s, 2s, 4s, 8s and 16s before each retry) only when a repeat is harmless: a read; a write deduplicated on a key you send (lines opened on external_line_id, settlements on external_settlement_id, payments on external_payment_id, loans imported onto a line on each loan's external_settlement_id, interchange rows on external_reference, card issue on idempotency_key, card registration on provider_card_id, payment aliases on alias, assessment requests on external_application_id; these keys are optional on each call, but a call sent without its key is not deduplicated, so send it on every write you might retry); or a write that sets a value outright, such as a card's limits (PATCH /credit/cards/{id}/limits), suspending a card, lifting its suspension or terminating it, or a webhook endpoint's settings (PATCH /webhooks/o2c/{id}). A keyed repeat returns what the first call made and writes nothing, also when it arrives while the first is still running: it waits for the first to finish and answers with its result. Other writes are not harmless to repeat: opening a line without external_line_id or issuing a card without idempotency_key (each call makes another), changing a line (a limit increase the program holds for acknowledgement issues a new disclosure each time), completing an assessment (a second completion is 409), registering a webhook endpoint, rotating its secret or a token, test-firing and redelivering. After a timeout on one of those, read what it changes before sending it again. Show the merchant the last figures you have with their as_of timestamp rather than zeroes while a call is failing.

Reference and Postman

• API reference: https://api.ondayzero.com/api/v1/credit/docs renders every endpoint, request body, and response. No token is needed to read it.
• OpenAPI spec: GET /api/v1/credit/openapi.json (also committed as docs/api/credit-openapi.json). It holds only the credit, webhook-registry, and token endpoints. Generate your own client from it if you prefer.
• Postman: docs/api/credit.postman_collection.json. Set the baseUrl, token, and businessId collection variables.

Compatibility

Changes inside /api/v1 are additive. A field is never removed or renamed, and a value never changes meaning, without a dated deprecation in docs/api/CHANGELOG.md at least 90 days before the change ships. New endpoints, new optional request fields, new response fields, new enum values on response fields, and new event types are additive; ignore any field or event type you do not recognise. Every response from /api/v1/credit, errors included, carries X-DayZero-API-Version with the contract version, a date. That header, info.version of the spec and the newest entry in docs/api/CHANGELOG.md always name the current one; log it with each figure you store.

Browser code on an origin we allow can read these response headers: X-DayZero-API-Version, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After, X-Total-Count and X-Request-Id. They are listed in Access-Control-Expose-Headers; without that a browser hides every response header but a handful of standard ones. Server-side callers always see all of them.

Rate limits

Three calls are limited per business, over a rolling window:

Every response from these calls carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (seconds until the oldest counted call leaves the window). A call over the limit is 429 with code: "GEN_005" and Retry-After set to the same number of seconds:

HTTP/1.1 429
Retry-After: 42
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 42

{ "error": "rate_limited", "message": "...", "code": "GEN_005" }

A refused call is not processed, so retrying it after the wait is safe. Batch settlements (up to 1,000 per call) rather than sending one at a time.

An API token also has its own request budget per minute across every call it makes (the token's rate_limit_per_minute, or the platform default). A call over it is 429 with code: "AUTH_058" and the same Retry-After and X-RateLimit-* headers, Retry-After being the whole seconds until the oldest counted call leaves the window.

Operator actions

Operator actions are performed in the DayZero console by a signed-in person, not calls your product makes; an API token receives 403 on each of them, whoever created it, unless this section names an exception. On a sandbox business, importing loans (onto a line, and the loan migration wizard), writing off a loan and adjusting a loan are open to any token, with no two-factor step-up, so a partner can rehearse a migration end to end from a script; on a live business they stay operator actions with the step-up below. Tell us and we run them. Creating and changing a program (POST /credit/programs, PATCH /credit/programs/{id}), importing loans onto a line (POST /credit/lines/{id}/loans/import), writing off and adjusting a loan (POST /credit/loans/{loan_id}/write-off, POST /credit/loans/{loan_id}/adjustments) and pushing the journal (POST /credit/finance/journal/push) are operator actions.

The operator actions that move money or change terms also need a two-factor step-up: the operator's DayZero account must have a second factor, verified in the current session, and a first factor verified in the last 10 minutes. Without a second factor the call is 403 AUTH_050; with a stale check, 403 AUTH_056. The console answers both by asking for the factors and sending the action again, so an operator is never simply refused. They are: creating and changing a program, importing loans (onto a line, and applying a loan file, POST /credit/programs/{id}/loans/import), writing off and adjusting a loan, deciding a limit-change request, applying an MCC allow list, switching who manages a program's cards, approving and activating a scorecard version, making a scorecard the program's default (PATCH /credit/scorecards/{id} with is_default, which changes the rules new assessments are measured against as activating a version does), lowering a scorecard's required_approvals (the same call; it removes a sign-off; renaming a scorecard or raising required_approvals asks for no step-up), and provisioning the paired sandbox when it mints a token. The other operator actions, reading an import batch or report, reading billing lapse risk, and listing or previewing templates among them, need a signed-in operator and the firm's own two-factor policy only.

Deciding a limit review is an operator action unless the program's limit_change_policy is direct; see Limit reviews. Deciding a limit-change request (POST /credit/limit-change-requests/{id}/decision) is an operator action under every policy; asking for one, reading them and cancelling your own are open to your token. Under approval_required no caller changes a limit with PATCH, and under console_only your token cannot; see Limit changes.

Deciding a bank-settlement match (POST /credit/payment-matches/{id}/override) and re-running a step of the daily sweep (POST /credit/sweeps/runs/{id}/rerun-step) are operator actions as well; reading the matches and the run log is open to your token. See Bank-matched settlement and What runs on DayZero's schedule.

A program's card setup is operator-only as well: previewing and applying its MCC allow list (POST /credit/programs/{id}/mcc-allowlist/preview and POST /credit/programs/{id}/mcc-allowlist/apply, see MCC allow list) and switching who manages its cards (POST /credit/programs/{id}/card-management, see Switching who manages the cards).

Provisioning the paired sandbox (POST /credit/sandbox/provision), copying configuration to it (POST /credit/sandbox/sync-config) and reading whether API access is about to lapse (GET /credit/billing-lapse-risk) are operator actions on the live business; see Sandbox and API tokens.

The compliance registry and its records are operator actions as well: listing, previewing, approving and retiring templates (GET /credit/compliance/templates, GET /credit/compliance/templates/{id}/preview, POST /credit/compliance/templates/{id}/approve, POST /credit/compliance/templates/{id}/retire), generating a disclosure by hand (POST /credit/lines/{id}/disclosures), withdrawing a limit increase a disclosure holds (POST /credit/disclosures/{id}/withdraw), and sending or waiving an adverse-action notice (POST /credit/adverse-actions/{id}/send, POST /credit/adverse-actions/{id}/waive). Reading a line's disclosures, downloading them, and reading the adverse-action queue are open to your token. See Compliance.

On a live business the loan migration wizard is operator-only from end to end (on a sandbox any token may run it): uploading a file (POST /credit/programs/{id}/loans/import/parse), correcting its mapping (PUT /credit/import-batches/{id}/mapping), the dry run and the apply (POST /credit/programs/{id}/loans/import), and reading batches and reports (GET /credit/import-batches/{id}, GET /credit/import-batches/{id}/report, GET /credit/programs/{id}/import-batches). So is attaching the history beside it: uploading a payments or statements file (POST /credit/programs/{id}/history/import/parse), adding statement documents (POST /credit/import-batches/{id}/documents), the dry run and the apply (POST /credit/programs/{id}/history/import), its report (GET /credit/import-batches/{id}/history-report), and marking a historical payment returned (POST /credit/historical-payments/{id}/reversal). Reading the attached history is open to your token. Building the loan file from a stored partner pull (POST /credit/programs/{id}/loans/import/from-partner-pull) is sandbox only, as pulls are. See Launching with existing loans and Attaching the history.

Storing a launch readiness evaluation (POST /credit/programs/{id}/readiness/evaluate) and forcing a program active (force_activate) are operator actions; reading readiness is open to your token. See Launch readiness.

Changing a scorecard is an operator action too: creating one (POST /credit/programs/{id}/scorecards, or from a seed with POST /credit/programs/{id}/scorecards/from-seed), changing its settings (PATCH /credit/scorecards/{id}), opening a draft (POST /credit/scorecards/{id}/versions), editing or discarding a draft (PATCH /credit/scorecard-versions/{id}, DELETE /credit/scorecard-versions/{id}), recording an approval (POST /credit/scorecard-versions/{id}/approve), activating a version (POST /credit/scorecard-versions/{id}/activate), and running a backtest (POST /credit/scorecard-versions/{id}/backtest) all return 403 to an API token. Reading scorecards and previewing a version against a business are open to any token; validating a version stores a report and can move a draft to validated, so it needs a token with the credit scope (a credit:read token, or a viewer in the console, gets 403). See The scorecard.

The four sweep endpoints — POST /credit/cycles/close, POST /credit/cycles/assess-late, POST /credit/accruals/run and POST /credit/sweeps/daily — are operator actions on a live business: an API token receives 403, and a signed-in person must pass the firm's two-factor check. On a sandbox business anyone with access, API token included, may run them; that is how a partner runs the clock forward. See Sandbox.

Completing an underwriting assessment by hand (POST /credit/underwriting/assessments/{id}/completion, which scores figures the caller supplies) and measuring one at once without waiting for the merchant's data (POST /credit/underwriting/assessments/{id}/run) follow the same rule: open to any token on a sandbox business, which is how the sandbox validator walks an application; on a live business an operator action, so an API token receives 403 (AUTH_057) and a signed-in person must pass the firm's two-factor check. A live merchant's assessment is completed by the nightly sweep once the data is in, or by an operator. See Underwriting.

The /api/v1/loans/ endpoints are a different product — a company's own borrowings (the business-loan subledger) — and are not part of this API.

Pagination

Every list under /credit answers with the same envelope, { items, next_cursor, has_next, limit }, with two documented exceptions below. Pass next_cursor back as cursor (as after on the event feed and the ledger, whose cursors are sequence numbers). has_next looks one row past the page, so a full last page is not "more", and next_cursor is null on the last page. Treat a cursor as an opaque string.

An offset cursor is the position of the next row. On a newest-first list that gains rows while you page, a row can repeat or be skipped; these lists change a few times a day at most. The loans, payments, events, ledger, notification and limit-change request cursors are keys, and are exact.

Every paged list returns items, next_cursor, has_next, and limit. Pass next_cursor back as cursor (or after on the event feed and ledger). has_next looks one row past the page, so a full last page is not "more". The loan page inside the subledger response carries the same cursor under loans, loans_next_cursor, and loans_has_next.

total is present only when you pass include_total_count=true, because it costs a count query, and then it is present on every list that offers it: loans, payments, underwriting assessments, cards, payment aliases, registered partner pulls and the issuer lists (the rows marked "yes" above). GET /credit/lines answers the same flag with an X-Total-Count header instead, its body being an array. It counts every row matching the filters, not the page. A list that does not offer it never carries a total field (the event feed and ledger have none: a count over a gapless sequence says nothing).

Exceptions. The event feed also returns its page as events and has_more, the names it had before the envelope was shared; they are the same values as items and has_next and are kept for existing clients. GET /credit/programs and GET /credit/lines are offset/limit and return a JSON array, not an envelope, and stay that way; on GET /credit/lines, include_total_count=true returns the matching count in an X-Total-Count response header. For a merchant dashboard, call GET /credit/lines/{id} rather than listing every line; to find a line by your own id, filter the list with external_line_id or external_merchant_id (see Open a credit line).

Lending models

A program is one partner's configuration: the parameter envelope, the policy positions, statement branding, GL posting, and card issuing. Lines open under a program and inherit from it. The program's lending_model chooses how credit is billed:

The rest of this guide describes per_transaction, which is the default for new programs.

A program's lending_model is fixed once any line has been opened under it, in any status: the two models keep different books (loans, or cycle draws), and a line's book cannot move from one to the other. A PATCH that changes it then is refused with 400 CREDIT_564; create a new program with the other model and open new lines under it. Sending the model the program already has is not a change. A program with no lines yet may still switch.

curl -X POST https://api.ondayzero.com/api/v1/credit/programs \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "slug": "northwind",
    "display_name": "Northwind Capital",
    "status": "draft",
    "lending_model": "per_transaction",
    "allowed_term_days": [30, 45, 60, 90],
    "default_rate_bps": 2000,
    "default_disbursement_fee_bps": 100,
    "allocation_order": "interest_fee_principal",
    "loan_ordering": "oldest_first",
    "minimum_payment_cents": 2500,
    "due_soon_days": 3,
    "early_payoff_terms": {"interest_rebate": "none", "fee_rebate": "none"},
    "legal_lending_entity": "Northwind Lending LLC dba Northwind Capital",
    "statement_branding": {"accent_hex": "#5B21B6", "footer_text": "Questions? support@example.com"},
    "covenants": {"cash_covenant_bps": 5000}
  }'

Create the program as draft and move it to active with PATCH once the launch checks pass: on a live business, creating it active runs the same checks and is refused (CREDIT_660) while a blocking one fails (a sandbox is not gated).

Program parameters

Rules the program does not state are not guessed. Where a path needs one, it returns 409 CREDIT_POLICY_UNDECIDED, its message naming the missing rule.

Rule changes reach new loans only. A loan is made under the terms in force when it originates, and keeps them until it is repaid. Its rate, fee and term come from its line. The program's pricing rules (interest_accrual_start, late_terms, early_payoff_terms, interest_cap_pct_of_principal_bps, and lending_model) are copied onto the loan when its transaction posts, or when it is imported, as the loan's pricing_terms (see Interest). Its accrual, its cap, its payoff quote and repayment schedule, and every recomputation after a backdated payment, a reversal, a waiver or a dispute use the loan's copy. So a PATCH that changes one of these rules applies to the transactions that post from then on; every loan already on the books is priced exactly as before, for past days and future ones. On a compliance program the change is disclosed to the merchants on those terms. The program's other settings (allocation order, loan ordering, minimum payment, due-soon days) are not pricing and apply to every loan as they change.

In the console, the program form shows the late rule and both early-payoff rebates as choices. A program that carries no rule shows Not decided, and saving sends nothing for it; picking a basis is the decision and is saved, with a grace of 0 too. The amounts a basis needs (the penalty rate, the flat fee) appear only for that basis and must be above zero. A rule set through the API is kept key for key: the form replaces only what the operator changed and keeps keys it does not show, such as a cap or a fee recurrence. A new per-transaction program starts on the FRD position (note rate, grace 0, no rebate), shown selected; a new cycle-draw program starts on Not decided for all three, so its launch checks fail until someone chooses. The launch check's Set the late rule link opens the form at the late rule.

A program update is checked as a whole before any of it is written: the terms, the rule bodies, the limit envelope, the limit-review policy against the envelope and limit_change_policy, and, for a move into active, the launch checks. If any check fails the program is exactly as it was; a patch is never half applied. These refusals are specific to updates:

Open a credit line

Called once, on approval. Returns the id every later call needs. Unspecified terms inherit the program defaults.

curl -X POST https://api.ondayzero.com/api/v1/credit/lines \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "program_id": "PROGRAM_ID",
    "external_merchant_id": "merchant_00417",
    "external_line_id": "line_00417",
    "credit_limit_cents": 25000000,
    "term_days": 30,
    "disbursement_fee_bps": 100,
    "start_date": "2026-03-18",
    "linked_account_name": "Business Checking",
    "linked_account_mask": "3397",
    "plaid_account_id": "acc_31x",
    "autopay_enabled": false
  }'

start_date is the signing date: the effective date named in the credit agreement. PATCH /credit/lines/{id} changes the repayment account and AutoPay, the status (below), and the limit where the program allows it (see Limit changes).

external_line_id is your key for the line, unique within your business. An open that carries one already in use returns that line (201), writes nothing and emits no second credit.line.opened, so an open that timed out is safe to send again, even while the first is still running (the repeat waits for it). The repeat is answered with the line as it stands: terms it carries that differ (another program, limit or term) are not applied, and the response shows the stored ones; change a line with PATCH. Without external_line_id, every call opens another line.

To find a line by your own id, list with it: GET /credit/lines?external_line_id=line_00417 returns the line carrying that id (an array of at most one, empty when there is none), and GET /credit/lines?external_merchant_id=merchant_00417 every line carrying that merchant id. Both match exactly, only within your business, and combine with program_id, status and include_total_count.

merchant_legal_name, merchant_state (a two-letter US state, DC or territory code; anything else is 400 CREDIT_601) and merchant_address (line1, line2, city, state, postal_code, country) say where the merchant is, which decides the disclosure template a compliance program uses. They are optional, except that a program with compliance.enabled refuses a line without all three (400 CREDIT_600, naming the missing fields) and refuses a PATCH that clears one. PATCH /credit/lines/{id} sets them on an existing line.

A card with the line. On a program with card_management: dayzero and issuing_enabled: true, send card to issue the merchant's card in the same call: card: {} is enough, with optionally display_name (the card's label at the issuer; the default is the merchant's legal name), card_type (virtual, the default, or physical), spend_interval (TOTAL only) and transaction_limit_cents. A Ramp card uses the program's issuing identity (ramp_cardholder_user_id): one user you control on your own Ramp account, set once on the program and verified against Ramp when set. The merchant is never a Ramp user and the request names no cardholder (cardholder_provider_user_id is deprecated and ignored when the program has an identity). Once the line is open DayZero issues the card exactly as POST /credit/cards would (see Cards), with the program's MCC allow list and an initial ceiling of zero. Its share of committed line headroom is queued for delivery, and the response carries the card and its issuer_sync_status. If the issuer refuses issuance, the line is still open, card is null and card_issue_error says why (the error code and message, as POST /credit/cards would have returned it); issue the card later with POST /credit/cards. A repeat of the open (same external_line_id) returns the card the first one issued and issues nothing. On any other program card is refused with 400 CREDIT_551 and no line is opened.

When the merchant keeps its books on DayZero, send merchant_business_id (on open, or later with PATCH): the merchant's own DayZero business. An underwriting assessment requested for the line then measures that business rather than yours. It must be a business your token can access; otherwise the call returns 403.

The dashboard

GET /credit/lines/{id} returns everything the summary cards and metadata row need:

Line status

PATCH /credit/lines/{id} with status (pending, active, suspended, closed) moves a line between states. A change needs a reason (up to 255 characters); without one the call returns 400 with code CREDIT_030. Sending the status the line already has changes nothing and needs no reason, except suspended for a line collections holds suspended (below). The reason is stored on the line (status_reason, status_changed_on) and carried on the event.

Each carries previous_status, status, reason, actor, changed_on, and the figures outstanding at that moment: outstanding_cents, past_due_cents, open_loan_count, credit_balance_cents and has_outstanding_balance. actor is operator (a signed-in person in the console), api_token (your integration), or collections (the nightly ladder, below). Closing a line that still owes money is allowed; the event says so, and the balance stays collectable. Other moves, such as pending to active, record the reason and emit nothing.

Who holds a suspension. A suspended line says who suspended it, as suspended_via on the line: collections when the collections ladder suspended it, operator when anyone else did (a person in the console or your integration through PATCH). Any move out of suspended clears it. The rule it carries: collections reinstates only a line it suspended itself, when the merchant catches up; a line an operator suspended is reinstated only by an operator, even if it was suspended while the line was delinquent and the merchant then catches up. To keep a line that collections suspended from being reinstated whatever the merchant pays, send status: "suspended" with a reason for it: the suspension becomes an operator's (suspended_via: "operator", the reason stored as status_reason), with no event, since the status does not change. Without a reason that call is 400 CREDIT_030. A line suspended before lines recorded this was stamped collections by a one-off backfill wherever the record proves it (the line is in a suspend_line stage it entered on or before its suspension, or its newest credit.line.suspended event says actor: collections and is dated that day); any other has suspended_via: null and is never reinstated automatically.

A suspension or closure may carry reason_code: credit_risk, delinquency, fraud, merchant_request or administrative. It changes nothing on the line or the event. On a program with adverse-action notices on, the first three record an adverse action.

Only an active line has spendable ledger headroom. A pending, suspended or closed line has zero available credit, and a partner-managed line's credit.line.limit_changed carries zero. For DayZero-managed cards, the status transaction queues a durable line-level issuer recomputation; it does not synchronously change every card. After commit, the worker freezes the managed funds, installs zero capacity for a stopped line, and leaves them frozen. Activation or reinstatement queues a fresh allocation and resumes eligible cards only after delivery succeeds. Repeated changes coalesce into the same request and are recomputed from current committed state. Until delivery completes, do not describe a line status response as an issuer-confirmed suspension or restored card availability. An explicit card suspension remains a synchronous decrease; see Cards.

What suspension and closure stop, and what they do not. Suspending a line removes its ledger headroom and queues the issuer stop described above; the debt keeps its terms. A suspended line's loans keep accruing interest day by day, go past due on their own due dates, are billed at month-end with a statement like any other, get their credit.autopay.due events, take payments, and stay on the collections ladder, which moves the line to deeper stages and, if collections suspended it, reinstates it when the merchant catches up. The merchant can still do everything on the borrower portal that helps them pay, AutoPay included. A transaction that clears late on a suspended card is real: it originates its loan, and a refund or a dispute on the line is applied as on any other. A suspended line is not given a limit review (it has no spendable headroom until reinstated, and is reviewed in its next cadence window after that). Closing a line ends it for good, and the same holds while it still owes: it accrues, closes its periods and issues statements, takes payments and is collected until it is paid off, after which the period that shows the payoff is closed and the line is left alone. Collections never moves a closed line to suspended or back to active, and never releases a closed line's cards. A closed line that never owed anything is never touched.

On a compliance program a line can open pending for the merchant's acknowledgement of its disclosure. While that disclosure waits, a move to active is refused (400, CREDIT_617): the line opens when the merchant acknowledges. An operator in the console may activate it without the acknowledgement by sending acknowledgement_override: { "reason": "..." } with the status change; the disclosure is then recorded as overridden, not acknowledged (see Acknowledgement). An API token can never send it (403, CREDIT_618). The override is ignored on any other move, or when nothing awaits.

Closing is line administration. Where the program's limit_change_policy is console_only, an API token that tries to close a line receives 403 with code CREDIT_031, and a signed-in operator closes it in the console instead. limit_change_policy is the program's line administration policy, and it governs the limit too (next section). Suspending and reinstating stay open to your token whatever the policy, so a risk hold never waits on a person.

Limit changes

A line's limit is a credit decision, so the program's limit_change_policy says who may move it and whether a second person must agree. It is set on the program (POST /credit/programs, PATCH /credit/programs/{id}) and applies to every line under it.

limit_change_reason (up to 255 characters) on the PATCH says why the limit moved; it is carried on the event and the ledger. A PATCH that sends the limit the line already has is not a change and is never refused, and the policy governs only the limit: the other fields on the same PATCH behave as described above. A line opened without a program has no policy, and its limit changes with PATCH.

Ask for a change:

POST /credit/lines/{credit_line_id}/limit-change-requests
{ "requested_limit_cents": 30000000, "reason": "Q4 ad budget doubled" }

reason is required (up to 255 characters). The call returns 201 with the request. It is refused with 400 when the limit asked for is the one the line has (VALIDATION_480) or sits outside the program envelope (CREDIT_512), with 400 (CREDIT_068) when the line has no program, and with 409 (CONFLICT_094, the body carrying the pending limit_change_request_id) when a request is already pending on the line: one at a time.

GET /credit/lines/{id}/limit-change-requests lists a line's requests newest first (status filters; paged, see Pagination), and GET /credit/limit-change-requests/{id} returns one.

Deciding is an operator action in the console, behind the firm's MFA step-up; an API token gets 403:

POST /credit/limit-change-requests/{id}/decision
{ "decision": "approve", "note": "Credit committee, 1 Oct", "limit_cents": 28000000 }

decision is approve or reject; note is optional and stored as decision_note. Approving moves the line through the same path as a direct PATCH: the limit is checked against the envelope, one credit.line.limit_changed event is emitted (its payload carries limit_change_request_id, with the request's reason), and issuer-control recomputation is queued. The request reads approved, with applied_at set; that timestamp records the local limit change, not issuer delivery. limit_cents approves a different figure inside the envelope: requested_limit_cents keeps what was asked, applied_limit_cents holds the figure applied, and decision_note begins "Applied $280,000.00 instead of the $300,000.00 requested." Rejecting leaves the limit alone. Every way a request closes (approved, rejected, cancelled, expired) emits credit.limit_change_request.decided once.

• The person who asked cannot approve (400, VALIDATION_479), under every policy; they may reject or cancel. A request your token made has no requester person, so any operator may approve it, whoever minted the token.
• Approval sets the line to the figure approved, not a step from where it was. Approving the limit the line already has (it may have moved since the request was made) returns 400 (VALIDATION_480).
• A request that is not pending is final: deciding or cancelling it returns 400 (VALIDATION_478), the message naming its status.
• An unknown request id returns 404 (NOT_FOUND_110).

DELETE /credit/limit-change-requests/{id} withdraws a pending request; it becomes cancelled. Your token may cancel only a request it made (403, CREDIT_069, otherwise); an operator may cancel any.

A pending request lapses at expires_at. The nightly sweep marks it expired (in its limit-review step, counted under limit_reviews.expired), and so does an attempt to approve, reject or cancel it after that instant, which is refused with 400 (VALIDATION_478). A lapsed request never blocks a new one: asking again expires it first. On a sandbox the sweep's clock counts: running it 15 days ahead expires a request made today.

The request itself emits no event; the limit only ever moves with a credit.line.limit_changed event. Poll the request, or watch for that event, to learn that it was approved.

In the console, Change limit on a line whose program is approval_required sends a request (the button reads Send for approval); under direct and console_only it changes the limit. The line's Limit reviews tab lists its limit-change requests above the reviews, each with Approve (optionally at another figure) and Reject, both taking a note; Approve is disabled for the person who asked. The program form sets the policy under Limit changes.

A card transaction posts

Push settled transactions, never authorisations. On a DayZero-managed Ramp program the cleared webhook does this for you: a transaction in Ramp's CLEARED ("cleared and settled") or COMPLETION ("completed processing") state originates the loan, the same id under both states originates it once, and PENDING / PENDING_INITIATION are ignored until they clear. A cleared or declined transaction on a credit-line card reaches the credit ledger from the webhook whether or not the Ramp connection's accounting sync is switched on, and it is never stored among the operator business's own Ramp transactions or booked as its expense, by the webhook or by the scheduled accounting sync: it is the merchant's draw, and the loan is its record. The webhook fetches the transaction with a client that renews an expired Ramp token first, so a lapsed token does not leave a delivery without its card. Idempotent on external_settlement_id; a re-pushed batch reports duplicates rather than double-counting. Up to 1,000 per batch. A negative amount is a refund.

The loan's settled_on, and so its statement period, is the date the transaction posted at the issuer (D-12), in the program's issuer_timezone (default America/New_York). Ramp sends settlement_date as a timestamp, UTC when it has no offset; DayZero reads it in that zone, so a charge Ramp settles at 2026-04-01T01:30:00Z (21:30 on 31 March in New York) is dated 31 March and belongs to March. A date with no time is taken as given. Without a settlement_date the authorisation time stands in, then the time Ramp created the record, then the current time, each read the same way. Ramp's accounting_date is not used: it follows the Ramp account's accounting preferences and can be overridden by hand. The cleared webhook, the nightly settlement reconciliation and the sandbox's POST /credit/sandbox/card-transactions all date a transaction this way, so the webhook and the reconciliation agree on the same transaction. A settlement whose period has already closed is still placed on the open cycle. When you push settlements yourself, send settled_on as the posting date at the issuer.

curl -X POST https://api.ondayzero.com/api/v1/credit/card-settlements \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "credit_line_id": "LINE_ID",
    "settlements": [{
      "external_settlement_id": "rmp_exp_9f3k2a",
      "settled_on": "2026-05-20",
      "amount_cents": 740000,
      "merchant_name": "Google Ads",
      "card_last_four": "9721",
      "merchant_category_code": "7311"
    }]
  }'

Each accepted result carries the loan it originated:

{
  "external_settlement_id": "rmp_exp_9f3k2a",
  "settlement_id": "...",
  "loan_id": "...",
  "principal_cents": 740000,
  "disbursement_fee_cents": 7400,
  "term_days": 30,
  "due_date": "2026-06-19",
  "status": "accepted"
}

A refund result says which branch applied: refund_disposition is reduced_loan when it reduced the loan it relates to (send refund_of_external_settlement_id to name it), or carried_forward when the loan was already repaid or the refund exceeded what was outstanding. Carried-forward credit is applied against the merchant's next loans and never paid out. A refund dated before the loan it reduces last accrued interest re-accrues that loan from the day after the refund's date on the principal it leaves, unless something else has reached the loan since that date (see the backdated payments rule under Payments).

Transactions belong to the statement period containing the date they posted at the issuer.

Disputes and voids

A posted transaction can stop being plainly owed: the merchant disputes it with the ad platform through the issuer, or the issuer reports that a transaction it cleared was voided. Either way its loan goes on hold until the question is settled.

curl -X POST https://api.ondayzero.com/api/v1/credit/loans/LOAN_ID/dispute \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Invalid clicks on campaign 4471", "provider_dispute_id": "rmp_dsp_81c2", "amount_cents": 300000}'

The call returns 201 with the dispute: id, kind (dispute, or void for an issuer void), status (open or resolved), amount_cents, opened_on, source (partner for an API token, operator for the console, webhook and reconciliation for the issuer paths below), and the loan's loan_status, loan_hold_status and loan_outstanding_cents after the call. Opening it again returns the same dispute: on provider_dispute_id when one is sent, otherwise on the loan's open dispute (a retry that adds the issuer's id records it on that dispute). A loan has one open dispute at a time. Disputes can be opened on a repaid loan (a chargeback after repayment) but not on one that has been written off.

While a loan is on hold:

• Interest. It accrues nothing from opened_on, and the hold days are never charged afterwards — not when the hold is lifted, and not when a payment backdated before the hold re-accrues the loan. Days already accrued from opened_on are taken back with an adjustment register entry. Interest accrued before the hold stays, and an imported loan's interest to its import date is never taken back.
• Collections. It is left out of days past due and of the collections ladder. A loan whose due date passes during the hold is not flagged past_due and fires no credit.loan.past_due or credit.loan.due_soon while held.
• AutoPay. No credit.autopay.due is emitted for it.
• Payments. An unallocated payment's waterfall passes it by, and the line's payoff quote leaves it out; a payment with loan_id naming it, or payoff-quote?loan_ids= naming it, still reaches it (with nothing projected for hold days).
• Dashboard and statements. Its balance stays in Total Balance, and so against the limit and in available credit. It is reported as on_hold_cents and not in past_due_cents or next_due_date. The Statement Balance is never restated; amount_due_cents on the line and the summary band is what remains of the statement less the part of it on held loans. Statement periods and documents carry on_hold_cents (the part of outstanding_cents on held loans). Each loan row carries on_hold and hold_status: as the statement was issued on the issued rows, today's on view=current. A hold placed after a statement was issued does not change it; it is listed under Since this statement, where the printed statement also states the amount on hold.
• Loans. Each loan carries on_hold, hold_status (none, disputed, voided), hold_reason, hold_started_on, hold_resolved_on, hold_outcome, and principal_reversed_cents, fee_reversed_cents, interest_reversed_cents. A held loan cannot be written off (400 CREDIT_207): resolve the dispute first.

Resolve with POST /credit/disputes/{id}/resolution and { "outcome": "...", "resolved_on": "YYYY-MM-DD", "notes": "..." }. The hold covers the days from opened_on up to the day before resolved_on; resolved_on may be in the past.

A reversal posts one adjustment register entry on resolved_on and, with GL posting on, one journal entry (the issuer payable, fee income — or deferred fee income for the part not yet recognised — and interest income are reversed against the receivables). Money the merchant had already paid towards an amount that is reversed is carried forward as credit balance, exactly as an overpayment (a dispute entry in the credit balance): a voided loan with payments on it turns those payments, and any carried-forward credit it consumed, into credit balance. The dispute records principal_reversed_cents, fee_reversed_cents, interest_reversed_cents and credited_cents. A loan a void takes to zero reads voided; one a merchant win takes to zero with nothing paid on it reads reversed (with payments on it, paid). Neither has a paid_on, and hold_outcome says why. Resolving again with the same outcome returns the dispute as recorded; a different outcome is refused.

GET /credit/lines/{id}/disputes lists a line's disputes, newest opened first (status=open or resolved to filter), with items, next_cursor, has_next, limit. Events: credit.loan.disputed when a hold is placed, credit.loan.dispute_resolved with the outcome, the hold days and the amounts reversed and credited.

From the issuer. For DayZero-managed Ramp cards, holds also arrive without a call:

• A transaction DayZero recorded as cleared that Ramp later reports DECLINED (the transactions.declined webhook, or the state on nightly reconciliation; VOIDED, CANCELLED and REVERSED from other sources are read the same way) goes on a voided hold. With nothing paid on the loan it is resolved voided at once. With payments on it the hold waits for an operator to resolve it (voided, or released if the void does not stand).
• Ramp has no disputes resource and no dispute webhook. A transaction carries a disputes list (CREATED_MERCHANT_ERROR, CREATED_UNRECOGNIZED_CHARGE, CANCELLED_BY_CUSTOMER, CANCELLED_BY_RAMP, RESOLVED_BY_RAMP), which DayZero reads whenever it sees the transaction — on the cleared webhook, on reconciliation over the last 7 days, and on the nightly dispute look-back over the last 30 (see What runs on DayZero's schedule). A CREATED_* entry opens a disputed hold keyed on the entry's id (or takes over a dispute you already opened on that loan without an id); a cancellation releases it. RESOLVED_BY_RAMP is noted on the dispute (provider_status) and nothing more, because Ramp does not say who won: record the outcome yourself. A dispute Ramp first lists on a transaction older than the look-back (30 days by default) is not picked up by itself; open it through the API.
• An issuer's date is never refused, only moved: a hold starts no earlier than the transaction date, no earlier than an imported loan's import date, and after the last payment applied to the loan. A dispute Ramp dates before an imported loan joined DayZero's books (one opened on the old system) holds from the import date, and the date Ramp gave is kept on the dispute as reported_opened_on; a void reported for such a loan holds from the import date the same way. The imported interest is untouched.

Loans

GET /credit/lines/{id}/loans returns one row per card transaction, oldest first, with server-side filters and a cursor:

Each loan carries transaction_date, merchant_name, principal_cents, disbursement_fee_cents, term_days, due_date, interest_accrued_cents, the paid buckets, outstanding_cents, and status, plus on_hold and the hold fields described under Disputes and voids, and pricing_terms, the program rules it was originated under (see Interest). The status is authoritative.

voided and reversed loans are left out of the portfolio's open book, the repayment measures and (for voided) the originations behind the default rate. They cannot be written off (CREDIT_531); a voided loan cannot be disputed.

GET /credit/loans/{loan_id} returns one loan with the same fields as a row of the list.

POST /credit/loans/{loan_id}/write-off charges a loan off. It is an operator action (Operator actions). The body is optional: written_off_on (default today; for an imported loan not before its import date: CREDIT_652), amount_cents and memo (up to 500 characters). Without amount_cents, or with one at or above the whole outstanding amount, the loan is written off in full: principal, fee and interest outstanding go to zero and its status is written_off. A smaller amount_cents is a partial write-off of principal only; the loan stays open and keeps accruing on what remains. The response is loan_id, written_off_on, principal_cents, fee_cents and interest_cents written off, total_cents, full, the loan's status and remaining_outstanding_cents. It emits credit.loan.written_off, for a partial write-off too (full: false). Refused with 400 when the loan is already written off (CREDIT_530), paid (CREDIT_531), on hold (CREDIT_207), the amount is not positive (CREDIT_532) or is more than the outstanding principal (CREDIT_533).

GET /credit/lines/{id}/subledger returns the Transactions tab in one call: the summary band, the loan rows (same filters), and the period history. GET /credit/lines/{id}/subledger/export returns the same rows as CSV, with the same filters except cycle_id: one row per loan with transaction_date, merchant, loan_id, settlement_id (the issuer's transaction id), amount, disbursement_fee, payback_term_days, due_date, accrued_interest, principal_paid, fee_paid, interest_paid, outstanding and status, then on_hold (yes or no), hold_status, paid_on and past_due_since. The last four were added after the others, which keep their order and names, so a reader that takes columns by position is unaffected.

Repayment schedule

GET /credit/lines/{id}/schedule answers "what do I owe, and when": every open loan, earliest due first, with what closes it today and what leaving it unpaid will cost.

Each row carries loan_id, external_settlement_id, merchant_name, transaction_date, due_date, days_to_due (negative once the due date has passed), status, on_hold, the three buckets principal_outstanding_cents, fee_outstanding_cents and interest_accrued_cents (interest owed on as_of, including days the nightly accrual has not posted yet), their sum payoff_today_cents, and projected: the payoff on the due date and 30 and 60 days after it, each as {on, interest_cents, total_cents}. A loan already past due projects from as_of instead of its due date. Points beyond the horizon are pulled back to its last day, so a narrow horizon returns fewer points.

totals sums the rows: due_within_7_days_cents and due_within_30_days_cents (each loan due in the window, priced on its own due date), past_due_cents (loans whose due date is before as_of, priced on as_of), and payoff_today_cents. next_statement_on is the day the next statement issues: the day after the current period ends, or as_of itself when an ended period has not closed yet.

Every figure is priced by the same per-loan computation as the payoff quote, so a row's payoff_today_cents is that loan's line on GET /credit/lines/{id}/payoff-quote?as_of=…, totals.payoff_today_cents is the quote's total_cents, and each projected point is what payoff-quote?as_of=<on>&loan_ids=<loan_id> returns. The schedule is per loan, so it exists only on per_transaction programs; a cycle_draw line returns 400 (CREDIT_072).

Build the summary band from its summary object alone: total_balance_cents, statement_balance_cents, amount_due_cents, statement_period_start, statement_period_end, statement_closed_on, statement_due_date, statement_status (open or paid), and statement_download_url, plus unbilled_cents, past_due_cents, on_hold_cents, credit_balance_cents, available_credit_cents, utilisation_bps, and next_due_date. Its available_credit_cents is the dashboard's figure: zero while the line is pending, suspended or closed, and always equal to available_credit_cents on GET /credit/lines/{id}.

Interest

daily interest     = remaining principal × (rate ÷ 10,000) ÷ 365
remaining principal = original principal − principal repaid − credits applied

Each day is stored as its own record at full precision; the loan's interest is the sum of those records rounded once. Interest is charged on principal only: fees do not accrue interest and unpaid interest does not compound. A loan repaid on or before its due date carries no interest at all. There is no grace period unless the program sets one, and accrual runs until the loan is repaid in full or the program's cap is reached.

The rules in that sentence are the ones the loan was originated under. Each loan carries them as pricing_terms:

A program change never re-prices a loan already written: the daily accrual, the cap, the payoff quote and the repayment schedule read the loan's pricing_terms, and so does a backdated payment that recomputes days already accrued. The rate itself is the loan's rate_bps, copied from its line.

Adjustments

An operator can reduce what a merchant owes on one loan without a payment: waive part of the fee, waive part of the accrued interest, or credit part of the principal as goodwill. This is an operator action (Operator actions): tell us and we record it in the console.

POST /credit/loans/{loan_id}/adjustments
{ "type": "waive_fee", "amount_cents": 1200, "reason": "Fee charged twice by the processor", "effective_on": "2026-04-20" }

amount_cents may not exceed what is outstanding in that bucket; more returns 400 (CREDIT_401). reason is required and becomes the ledger memo. effective_on defaults to today and may not be before the loan was originated (CREDIT_403), before an imported loan's import date (CREDIT_652), or in the future. A goodwill_credit may not be dated before a payment already applied to the loan (CREDIT_403); one dated before days already accrued removes those days and accrues them again on the reduced principal, as a backdated payment does. A loan that is paid or written off has nothing to adjust (CREDIT_402).

Each adjustment posts one adjustment entry to the ledger with the bucket it reduced and, when the program posts to the GL, debits an expense account (Fee Waivers, Interest Waivers or Goodwill Credits, created on first use) against Notes Receivable or Interest Receivable. A loan brought to zero is paid on effective_on and emits credit.loan.paid; no other event is emitted, because the adjustment is on the ledger and the statement. The response carries the adjustment and the loan as it stands after it; the loan's fee_waived_cents, interest_waived_cents and goodwill_credit_cents are the running totals. Adjustments are never payments: the paid buckets do not move, and statements report them in their own column. GET /credit/loans/{loan_id}/adjustments lists a loan's adjustments, newest first. A payment recorded later but dated before an adjustment lifts the adjustment and applies it again after itself (see Payments); one the earlier payment leaves nothing to reduce refuses a payment you record (CREDIT_650). A pending debit that settles at an earlier date is booked anyway, and the adjustment takes effect for what that money left in its bucket: amount_cents is then what took effect (possibly zero) and requested_amount_cents what was asked for (null when it took effect in full), and the register entry's memo says why.

Statements

The month closes on its last calendar day. Close applies the month's accrued interest, freezes the Statement Balance (everything outstanding across open loans at the period end), and issues the statement. The interest a statement applies to a loan is the movement across the period in the loan's own interest, as the loan carries it: its daily records rounded once, half a cent up, and held at its cap. So a loan's statements add up to exactly its interest, and once its cap is reached its statements bill it no more interest. Close also stores the statement exactly as issued, so an issued statement never changes: what happens to its loans afterwards is shown beside it, under Since this statement, never by restating it.

The position at the period end. Payments and adjustments count when they are dated by the period end, and so do write-offs: a loan written off after the period end — even one written off before close ran — is billed as it stood at the period end (principal, fee and interest, with the status it had then), and the write-off is listed under Since this statement. A loan written off by the period end is left off.

Loans brought over from another system. An imported loan is on statements from its import date. No statement is issued for a period that ended before it. The statement whose period holds the import date brings it forward: what it owed as imported (principal, fee and interest to date, less what was repaid or credited before the import) is part of that statement's previous_balance_cents, so it is never a new purchase or fee, its interest from before the import is not interest of the period, and what it was repaid before the import counts in its paid-to-period-end columns but never in the period's payments. The roll-forward closes as for any statement: previous balance plus new purchases, fees and interest, less payments, is the statement balance. Cut-over. A line's cut-over is the earliest import date among its loans that still owed something as imported. Before it the previous system was the book: a payment that landed then is already in the imported loans' paid amounts, so a payment dated before the cut-over is 400 CREDIT_751 with nothing written (and a pending payment settling before it stays pending), whether or not it names a loan. A payment that landed after the cut-over is dated when it landed and pays the imported loans, oldest first, like any other. So import as at the day after the previous system's figures are good through (accrued_through the last day those figures cover, as_of the day after; the console's As of field), and record on DayZero only payments that landed on or after as_of. A loan imported later onto a line already on DayZero (a late transaction) does not move the cut-over: a payment dated between the two imports passes that later loan by, which was not on DayZero's books yet, and is applied to the loans that were. Each loan carries imported_on (null for a loan made on DayZero) and the source_system the import named.

Due date. At close, the statement's due date is the earliest due date, among the loans on that statement, that falls on or after the day close runs — or the close date itself when every loan on it is already due. It is stored at close and never recomputed from the issued date. In the worked example below, the March statement (closed 1 April) is due 4 April, the first loan's due date; the April statement (closed 1 May) is due 1 May, because every remaining loan is already past due — a statement can be due the day it issues.

GET /credit/lines/{id}/statements lists periods with amount_due_cents (the statement balance), paid_cents (how much of that balance has been retired since), outstanding_cents (what remains of it), on_hold_cents (the part of outstanding_cents on loans on hold), period_status (open or paid), reconstructed (see Statements closed before snapshots), and download links. GET /credit/lines/{id}/statements/{cycle_id} returns the document:

view=current follows the close: a loan written off by the period end is billed nothing and its interest is not applied (it stays on the rows of the period it was written off in, at zero), and interest is the loan's own, rounded once and held at its cap, so each row's interest is what the close applied, to the cent. pdf and html are always the issued document; view=current with either is 400 (CREDIT_641), and a view that is neither is 400 (CREDIT_640).

The CSV has one row per transaction: statement_period_start and statement_period_end, transaction_date, merchant, loan_id, settlement_id (the issuer's transaction id, which is the loan's external_settlement_id, not DayZero's settlement id), amount (principal), disbursement_fee, payback_term_days, due_date, interest_applied_this_statement, interest_accrued_to_period_end, what was paid inside the period (principal_paid_this_period, fee_paid_this_period, interest_paid_this_period), adjustments_this_period, the cumulative principal_paid_to_period_end, fee_paid_to_period_end, interest_paid_to_period_end, then outstanding_at_period_end, status, originated_this_period, and hold_status. The period columns count payments dated from the period start to the period end, so for each loan last month's cumulative figure plus this month's period figure equals this month's cumulative figure, and the three period columns summed over every row equal the statement's payments total. A loan paid off during the period stays on that statement for this reason. By default the spreadsheet is always current: a payment backdated into a closed period, or reversed out of one, moves these columns even though the issued statement balance is never restated. view=issued returns the same columns as the statement issued them. The CSV does not break out individual payments; per-payment allocation by loan is on GET /credit/lines/{id}/payments. The JSON payload carries the same figures per loan as principal_paid_this_period_cents, fee_paid_this_period_cents and interest_paid_this_period_cents.

Operator adjustments are not payments and are never in the paid columns. adjustments_this_period (adjustments_this_period_cents in the JSON) is the fee waived, interest waived and goodwill credited by adjustments effective inside the period; outstanding_at_period_end and the statement balance are net of every adjustment effective by the period end. A loan adjusted to zero during the period stays on that statement.

What is frozen

At close the statement is stored as issued (snapshot_version 1): every loan row with each figure the statement shows (principal, fee, interest applied in the period and accrued to the period end, what was paid in the period and to its end, adjustments in the period, refund credit, principal written off, what a dispute resolution reversed, unpaid principal, fee and interest, the outstanding at close, due date, status and hold, merchant and description), the roll-forward, the period dates and due date, the statement balance, the lender's identity and branding at that moment (legal_lending_entity, display_name, statement_branding), the terms (terms: rate, term, disbursement fee, when interest starts, grace, balance mode) and the totals. The rows are checked against the totals frozen on the period when they are written. A cycle-draw statement stores its settlements and its one draw the same way.

The issued part of every document of a closed period — the JSON's period, balances, roll-forward, loan rows, lender identity and branding, the PDF and the HTML down to the footer — comes from that record, so it reads the same however often, and however late, it is rendered: a refund, write-off, adjustment, dispute, payment reversal or backdated payment after the period changes none of it, and a later change to the program's branding does not reach an issued statement. issued in the JSON says where it came from: snapshot_version, reconstructed, ties (whether the rows sum to the frozen totals; one that does not is logged for us and the statement is kept as stored) and captured_at. status, period_status, paid_cents, outstanding_cents and on_hold_cents on the document are today's figures, and the rest of today's position is in since_statement.

Since this statement

Below the statement, the PDF and HTML carry a separate section, and the JSON a since_statement object, listing what has touched the statement's loans since it was issued. It starts from the balance as issued (issued_balance_cents: the loan rows' outstanding, or a cycle-draw statement's amount due) and ends in outstanding_now_cents, what those loans owe today. Each of items has date, kind, description, amount_cents (negative reduces what is owed, positive adds to it), loan_id and external_settlement_id when it touched one loan, and reference. The section is left out of the PDF while nothing has happened.

statement_paid_cents and statement_remaining_cents say how much of the balance as issued has been retired since and how much remains; they are the document's paid_cents and outstanding_cents, and what remains never exceeds the statement balance, even on a rebuilt statement whose rows add up to more than the balance frozen at close.

Money after the period

A payment after the period on a loan that has since accrued more interest retires that interest first, then the fee, then principal: the waterfall is the same for every payment. For the question "has this statement been paid?", money received after the period is attributed to the statement's balance first, loan by loan, capped at what each loan owed on the statement, and only the rest to interest charged later. So paying off one loan, later interest included, retires exactly that loan's share of the statement and never another loan's; a part payment counts in full against the loan's share. A refund, credit, adjustment, write-off or dispute resolution after the period retires a loan's share the same way. A payment the statement counted that is returned afterwards, and credit withdrawn with it, re-open debt outside the issued balance: they appear under Since this statement and on the next statement, and the statement's remaining figure never exceeds its balance.

That one figure is what the statement list's paid_cents, outstanding_cents, on_hold_cents and period_status, the document's, the summary band's amount_due_cents (and the line's), the period history, the period's own status (it reads paid once nothing of its balance remains) and the borrower portal's "Still owed" all read. Days past due, the collections ladder and AutoPay are per loan, against each loan's own due date, and do not look at statements. In the worked example, $95.62 of the $30,000 payment on 15 April retired interest charged in April, so it counts against the April statement and the March statement shows $29,904.38 paid and $15,545.62 remaining.

Statements closed before snapshots

A period that closed before statements were stored as issued has no record yet. The first time it is rendered, its record is rebuilt from the books as at its period end — refund credit, write-offs and dispute reversals dated after the period end are taken back out — stored, and flagged reconstructed: true; every later render reads that stored record. The statement list carries reconstructed, the PDF and the portal say the statement was rebuilt, and ties says whether the rebuilt rows match the totals frozen at close. A copy of a business (a sandbox cloned from another) does not inherit its source's stored statements: each of its closed periods is rebuilt the same way from the copy's own loans and payments, so nothing paid to the source after the copy was made shows on it. We rebuild the whole book in one pass with scripts/admin/credit/backfill_statement_snapshots.py (--business-id for one lender, --apply to write; a dry run otherwise).

Payments

DayZero never debits an account. Request a payoff figure, execute the debit through your processor, then report it. The response carries the allocation and corrected balances, so the UI updates without a second round trip.

Two lending models, different initiation behavior. The pending-then-settlement flow below applies to per_transaction. A cycle_draw program rejects pending: true before writing anything; only report a cycle-draw payment after the funds have landed. Do not use it to record an ACH initiation.

Payment identity and retries. Creation deduplicates by credit line plus external_payment_id; a repeated request returns the existing payment without changing its amount or other fields. Settlement with the same date is repeatable; another date is refused. A repeated reversal is refused as already reversed. Settling a pending payment replaces its paid_on with settled_on, so keep the original initiation date with the processor evidence.

# 1. Quote. Never use a displayed balance as the payoff figure.
curl "https://api.ondayzero.com/api/v1/credit/lines/LINE_ID/payoff-quote?as_of=2026-05-20" \
  -H "Authorization: Bearer dz_your_token_here" -H "x-business-id: YOUR_BUSINESS_ID"

# 2. Execute the debit on your side.

# 3. Report it. paid_on is the date the money landed.
curl -X POST https://api.ondayzero.com/api/v1/credit/payments \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "credit_line_id": "LINE_ID",
    "external_payment_id": "pay_0091",
    "amount_cents": 3000000,
    "paid_on": "2026-04-15",
    "method": "ach_payliance"
  }'

The quote's date. GET /credit/lines/{id}/payoff-quote takes as_of (default today, UTC) and, for one or more loans, loan_ids. A quote projects forward from the loans as they stand, so on a per-transaction line it cannot price a day the book has already been processed past: an as_of earlier than both today and the line's processed-to date (the latest of its register entries, its loans' last accrual, and any hold opened or resolved) is 400 CREDIT_730, and the message names the earliest date it will quote. Those loans already carry what happened after that day (interest accrued since, a later payment, a loan originated since), so a figure for it would be today's under an old date. Today and any later date are always quoted, and so is the processed-to date itself: in the worked example, a quote for 15 April asked for once that day's accrual has run, before the payment is recorded, reads $45,545.62. Quote for the day the money will land.

Allocation is not selectable per payment; the program decides it (loan_ordering and allocation_order, see Program parameters). With the defaults a payment is applied to the oldest open loan first and moves to the next only once that loan is fully repaid; within a loan it retires accrued interest, then the disbursement fee, then principal. Because interest is retired first by default, a loan cannot then reach zero principal with interest still owing. Overpayment beyond everything outstanding is carried forward as credit. A loan on hold for a dispute is passed by unless the payment names it.

What a payment can reach. Only loans DayZero carried on its date: never a loan whose transaction is dated after paid_on, and never an imported loan before its import date. That holds when the payment is first applied and every time a backdated payment re-applies it. What it leaves over is credit, and a loan originated later takes that credit at its own origination, as it would have had the payment been recorded on time.

Before you debit, ask what an amount would do. POST /credit/payments/preview takes credit_line_id (or external_line_id), amount_cents, an optional as_of (default today, UTC) and an optional loan_id, and returns what recording that payment would retire:

curl -X POST https://api.ondayzero.com/api/v1/credit/payments/preview \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{"credit_line_id": "LINE_ID", "amount_cents": 3000000, "as_of": "2026-04-15"}'

The response lists allocations, one per loan reached (loan_id, external_settlement_id, merchant_name, and the interest_cents, fee_cents and principal_cents it clears, with loan_paid_in_full), then unapplied_cents (what exceeds everything owing, which would be carried forward as credit), balances_after (total_cents, principal_cents, fee_cents, interest_cents, credit_balance_cents) and loans_remaining_open. The preview brings interest up to as_of and allocates exactly as the real call does, including a backdated as_of; the figures are what POST /credit/payments returns for the same amount and date. The per-loan rules apply to a preview with loan_id as they do to a payment: below the minimum, or not an open loan on the line, is 400. A preview records nothing, emits no event and calls no webhook; call it as often as the dialog needs. Under cycle_draw programs, allocations are per cycle (cycle_id, with loan_id null).

• Per-row Pay: pass loan_id to allocate to one loan; the program's per-loan minimum applies, or the outstanding amount when smaller. The loan must be open on paid_on. A payment dated before a later payment, adjustment or dispute resolution paid the loan off is a correction and is accepted: those later events are lifted (see backdated payments below), the loan is open again on that date, and the minimum is checked against it then. Otherwise a loan_id that is not on the line, was not yet originated (or, for an imported loan, not yet imported) on paid_on, is written off, or was paid off on or before paid_on is 400 (CREDIT_529), as is one a refund paid off (a refund keeps its place in a replay). A pending debit must name a loan open now. Nothing is recorded on a refusal: no payment row exists afterwards, so the same external_payment_id can be sent again with a correct loan. Quote one loan with payoff-quote?loan_ids=LOAN_ID.
• Pending debits: pass "pending": true to record an initiated debit without allocating, then confirm with POST /credit/payments/{id}/settlement and settled_on. The payment counts from the settled date. Sending the settlement again with the same settled_on returns the payment as settled and allocates nothing a second time, so a settlement that timed out is safe to repeat with its date. A different settled_on on a payment already settled is refused with 400 CREDIT_731, which names the date it settled on: the payment was allocated as at that date, and re-dating it would leave the two apart. On a program with bank_settlement_matching on, the bank feed can confirm it for you (below). By then the money has moved, so a settlement is always booked at settled_on, however long ago: where a later adjustment or partial write-off can no longer apply in full after it (a fee waived from 3 April that a debit landing on 2 April already paid), that adjustment or write-off is re-applied for what is then outstanding instead of refusing the settlement. The adjustment keeps requested_amount_cents beside the amount_cents that took effect, the register entry's memo says why, and the journal entry for the part that no longer applies is reversed. The bank matcher and an operator's confirmation of a match settle the same way.
• Backdated payments: a payment dated before the last processing date removes the accrual days after it and re-accrues them on the reduced principal. Everything applied to the line with a later date is lifted first and applied again after it, in date order (then in the order it was recorded): later payments, fee and interest waivers and goodwill credits, dispute holds and dispute resolutions. A later payment then retires interest only on principal still owed; a dispute reversal takes back the interest accrued before the hold on the principal the earlier payment left, and credits what had been paid towards it; a loan whose hold had not yet opened on the payment's date is in the waterfall. The register records each lift and re-application as an adjustment entry; the GL entry of a later payment or resolution is reversed and posted again only where its figures changed. A loan originated after the payment's date takes carried-forward credit again at its origination, oldest credit first, from the credit that had arisen by its transaction date: credit the earlier payment makes (or leaves a later payment with) is consumed where it would have been, and only a change is posted (one credit_applied register entry and journal entry). A partial write-off dated after the payment is lifted too, so the principal it wrote off accrues for the days before it, and is written off again on its date. If a later adjustment or partial write-off can no longer apply — a waiver larger than what the earlier payment leaves in its bucket, a write-off of more principal than it leaves — the payment is refused with CREDIT_650 or CREDIT_653, which names it, and nothing is recorded: date the payment on or after it. A dispute resolution recorded before DayZero kept how its fee reversal split, on a program with deferred fee recognition, refuses it the same way (CREDIT_651). (A pending debit settling is never refused this way, CREDIT_651 included; see above.) Refunds keep their place: they take effect when they are posted, and a backdated payment's replay does not lift them. A refund dated before its loan's last accrual is backdated itself, and re-accrues its own loan when it arrives: the days after the refund's date are removed and accrued again, through the day the loan had reached, on the principal the refund leaves, as a backdated payment does. It does so only while nothing else has reached that loan since the refund's date (a payment dated or returned after it, another register entry on the loan such as an adjustment, a write-off or credit, or a dispute opened or resolved after it), because re-accruing those days would undo what that later event did to them; then the refund reduces the loan's principal as before and the days already accrued stand. A loan written off in full is closed to the replay: nothing backdated reaches it, and what a later payment had paid it stays exactly where it landed (its write-off was worked out from it), so only the rest of that payment is applied again.
• Returns: POST /credit/payments/{id}/reversal with reversed_on and reason reopens the loans at the balances they held. The merchant is not charged interest for the interval the debit was in flight: from the day after the payment's date through reversed_on, a loan the payment closed accrues nothing and a loan it only reduced accrues on the reduced principal; the restored balance accrues from the day after reversed_on, as a payment's own reduction counts from the day after its date. A payment that left money over takes back exactly that credit and nothing else (see Credit balance), and never re-opens a loan the merchant has since won a dispute on, whether the payment paid it directly or through credit it consumed. A statement the payment had paid reads issued again, with its remaining figure and the line's amount_due_cents restored, and the register's payment_reversal entry carries reason as its memo. A loan the return leaves owing past its due date is past_due at once and, unless it is on hold or was announced before, gets its credit.loan.past_due event then (see Events).
• AutoPay: where autopay_enabled is true, the daily sweep emits one credit.autopay.due event for each outstanding loan that is due (its due_date is on or before the sweep date) and has not had one, carrying the amount to debit as at that day. A loan normally gets it on its due date; a loan already past due when AutoPay is switched on, or due on a day the sweep did not run, gets it on the next sweep. Each loan gets one, ever (the event's idempotency key is autopay.due:{loan_id}), so a debit that fails is not asked for again: retry it from your side, or take a payment another way. Execute it and report it as a payment. A loan on hold gets none until the hold is released.

GET /credit/lines/{id}/payments lists payments newest first. On every read of a payment — the response to recording it, the same payment reported again, and this list — unapplied_cents is what it carried forward as credit: its amount less what its allocations retired, including the whole amount when it reached no loan. A pending payment has not been applied yet and a returned one's credit was taken back, so both read 0.

Payliance reporting integration

Connect Payliance on the lender business under Integrations → Payliance, or use POST /api/v1/payliance/connect with api_key, environment (production, staging or sandbox) and sync_from. The key is encrypted at rest. Payliance must allow the outbound IP addresses of both the API server and the sync worker. Connection verifies all three reporting feeds; the UI then starts an import. API callers start it separately with POST /api/v1/payliance/sync.

Payliance routes are outside /credit: a credit-only API token cannot access them. Writes require ADMIN permission on the lender business. GET /api/v1/payliance/status exposes health and checkpoints, never the key. DELETE /api/v1/payliance/disconnect removes credentials and stops scheduled imports while keeping evidence and matches.

For per-transaction repayments, record Payliance acceptance as:

{
  "credit_line_id": "LINE_ID",
  "external_payment_id": "THE_PAYLIANCE_UNIQUE_TRAN_ID",
  "amount_cents": 15000,
  "paid_on": "2026-10-30",
  "method": "ach_payliance",
  "pending": true
}

The amount is $150.00. Use the actual event date and retain the returned payment id. The connector automatically links a unique same-business reference with an exact positive debit amount and a Payliance method. Use references unique across the lender business, even though payment creation itself deduplicates per line. An operator can explicitly link an existing repayment when references differ.

Transactions, settlements and returns are imported separately, with every provider page followed. Sync runs every six hours through the previous day and re-reads two recent days. A settlement invokes the existing credit settlement path; a return invokes reversal. Notifications of change never reverse money. Partial returns, unknown directions, ambiguous references and incomplete evidence remain for review. Staging and sandbox evidence never changes live loan balances.

Bank reconciliation. Select settled items or late returns in the integration and find an exact signed bank total within five days of every selected event. A confirmed match attaches evidence to the existing bank row. If the linked repayments have posted loan journals using one separate cash/clearing account, an uncategorized bank offset can be moved to that account. Existing categorization, closed periods, missing journals, mixed clearing accounts and net-of-fee deposits require review. Check the accounting result separately from the evidence-link result.

Settlement authority. Production Payliance onboarding establishes the processor as the ACH settlement authority, including after its key is disconnected. Bank observations can attach evidence but cannot independently create ACH repayments or settle pending Payliance debits. Historical unreconciled bank repayments block automatic processor allocation until an operator chooses the canonical payment or confirms that a pending repayment is distinct. Matching does not attach historical money by amount alone. A confirmed bank decision returns effect (evidence_attached, settled, returned, or null), so the UI can distinguish reconciliation from another financial allocation.

Existing duplicates. The authority rules prevent new automatic duplicate credit; they do not silently unwind historical double-allocated payments. Review and correct those explicitly. If an old bank payment becomes canonical while another pending row already exists, the duplicate pending row stays nonallocating and must be cancelled explicitly.

A genuinely distinct landed debit. For either lending model, including cycle-draw, an administrator can reconcile a separate payment without creating an unsupported pending payment. Fetch GET /api/v1/payliance/transactions/{id}/payment-candidates?credit_line_id={line_id} and review every row in unreconciled_bank_payments. Then send POST /api/v1/payliance/transactions/{id}/match-payment with {"distinct_payment":{"credit_line_id":"…","reviewed_bank_payment_ids":["…"],"note":"Why this is a separate landed debit"}}. The existing { "payment_id": "…" } mode instead selects the canonical existing repayment; the modes cannot be combined. Distinct creation requires positive settled production debit evidence without a return. Amount, reference and date come from that evidence. Missing or stale acknowledgments return 409: refresh the list and review it again. The repayment and its canonical evidence link are recorded atomically.

review_before_apply also holds matching ACH returns. Explicit confirmation can reverse an applied repayment once; attaching another observation to an already-reversed repayment only adds evidence.

GET /api/v1/payliance/transactions?reference=... searches all imported payment references and authorization IDs before cursor pagination. Credit-workspace links can therefore locate older evidence directly instead of searching only the currently loaded page.

Credit balance

A line carries credit when the merchant is owed money: a payment beyond everything outstanding, a refund larger than what its loan still owed (or of a loan already repaid), or a dispute won by the merchant (or a void) on money they had already paid. It is never paid out; the next loan the line originates consumes it. DayZero records each deposit of credit as an entry with its source, and each loan that consumes credit draws on the oldest entry first and is named on it.

GET /credit/lines/{id}/credit-balance?status=open

The response carries credit_balance_cents (the dashboard figure), entries_remaining_cents (the sum of the entries' remaining_cents: equal to it less unattributed_cents), unattributed_cents, open_entry_count, and the entries newest first, paged (items, next_cursor, has_next, limit; filter with status, comma-separated). Each entry has:

What a returned payment takes back. Exactly the credit that payment made, and from where it went. The part no loan has consumed is withdrawn. The part loans consumed is taken back from exactly the loans its entry lists, newest loan first: each owes that amount again (a credit_applied register entry and, with GL posting on, the reverse of the credit-applied journal entry). Credit from refunds and disputes, and credit from other payments, is not touched. A loan since written off keeps what it consumed; that part is not recovered. A backdated payment that leaves a later payment with less over withdraws the difference from that payment's credit in the same way, and one that leaves it more over adds to its entry; the same holds for a dispute resolution it replays.

A loan the merchant won a dispute on. When the merchant wins a dispute on a loan that consumed credit (or the loan is voided), the reversal takes what is still owed off the loan and turns the part the credit had paid into the dispute's own credit. If that credit's source is then taken back — its payment returned — the dispute credit made from it was never real either: the withdrawal comes off the dispute's entry, not the loan, which stays at zero; the reversal then reads as having taken that principal off the loan itself (a credit_applied and an adjustment register entry that net to nothing on the loan, and no journal entry), and the dispute's credited_cents falls by the same amount. Where a later loan had already consumed that dispute credit, that loan owes it again. The entries' consumptions and withdrawn_cents record every step, and a loan without such a dispute is treated exactly as before.

The same holds for a returned payment that paid such a loan directly. The merchant had paid part of the loan before winning, so the reversal took less off the loan and credited the rest. With the payment returned, the reversal takes that part off the loan instead, bucket by bucket (principal, fee and interest, up to what it credited of each): the loan stays closed for what the merchant won and owes again only what they would have owed without the payment. The return's payment_reversal entry restores the payment's allocation, an adjustment entry (from the dispute) takes the re-split part off again, the dispute's credited_cents falls by that part, and the dispute's credit entry gives it back: what no loan consumed is withdrawn, and a loan that consumed it owes it again. With GL posting on, the return's journal entry takes that part out of Customer Credit Balance rather than back onto the receivable. A payment applied after the resolution paid none of what it credited and re-opens the loan as any return does.

Credit from before entries were kept. A line that already held credit when entries began has its balance as one opening entry with no source. It is written the first time the line's credit moves (or by scripts/admin/credit/backfill_credit_balance_entries.py --apply, which does every line at once and is a dry run without --apply). What consumed credit before that is not reconstructed: a payment from before entries existed that bounces takes its credit back from the opening entry, then from the loans that consumed it, then from loans whose consumed credit no entry accounts for (read from the register). Until a line's opening entry exists, the endpoint reports its balance as unattributed_cents and lists no entries.

DayZero checks every night that the credit_balance_cents of each line with a register equals the sum of its entries' remaining_cents (see What runs on DayZero's schedule).

The payoff quote also carries disclosure: the line's terms applied to the quoted principal as one single-payment loan made on as_of (see Disclosures and adverse action). It is null when nothing is outstanding.

Bank-matched settlement

When the money is visible in a bank feed DayZero already syncs, a pending payment does not need the settlement call: the debit showing up in the bank confirms it. Turn it on per program with bank_settlement_matching: true (PATCH /credit/programs/{id}, an operator action; off by default). Two kinds of account are read:

• the line's linked repayment account (plaid_account_id on the line), where the merchant connected it through DayZero — on your business, or on the merchant's own DayZero business named in merchant_business_id. On a merchant's books only that account is read;
• your own bank accounts, where a wire repayment lands with a sender name.

Every new bank transaction that could be a repayment goes through four rules, in order:

A deposit on your account that fits a pending payment by amount and window but whose sender is not a recorded alias is never applied on the amount alone. It is recorded as an unmatched_candidate on the lines it could be (at most five) and looked at again on every later pass, so recording the sender as an alias lets the next pass settle it. Business days skip weekends; bank holidays are not modelled.

Payment aliases. Record the sender name a merchant's money arrives under with POST /credit/lines/{id}/payment-aliases (alias, up to 255 characters, as the sender name, reference or account mask reaches your account; optional alias_type: sender_name (the default), account_mask, reference or other; source up to 64 characters; note up to 255). Matching folds case, drops punctuation and strips company suffixes, so "NORTHWIND LENDING, INC." and "Northwind Lending Inc" are one alias. Sending an alias the line already has returns it; an alias that already points at another line is refused (CREDIT_537), and one that is empty once cleaned is CREDIT_536. GET /credit/lines/{id}/payment-aliases lists a line's aliases and DELETE /credit/payment-aliases/{id} removes one. GET /credit/payments/resolve?description=... takes the text an incoming payment arrives with and returns credit_line_id (set only on an exact match, with matched_on: "alias"), normalised, and candidates for partial overlaps, which are for a person to confirm and are never treated as a match. It records nothing: take the line id and post the payment as usual.

Settling and reversing go through the same path as your own calls, so the allocation, the ledger, the spend-limit push, and the credit.payment.settled / credit.payment.reversed events are identical. Matching runs whenever the bank feed syncs, and the nightly sweep re-reads the last 16 days, which catches a payment recorded after its debit had already synced.

GET /credit/lines/{id}/payment-matches lists every decision for a line, newest bank date first: kind (settled, returned, ambiguous, unmatched_candidate), the rule that decided (linked_account, alias, ach_return), matched_on (the bank date applied), amount_cents, the bank description, notes saying what matched, candidate_payment_ids when more than one payment fit, and a confidence between 0 and 1 that is informational only. Filter with kind (comma-separated) or unresolved=true for the rows waiting on an operator. A transaction is decided once; running the matcher again never applies it twice.

An operator decides the open rows in the console (Payments tab, Payment matches) or with:

POST /credit/payment-matches/{id}/override
{ "action": "confirm", "payment_id": "...", "note": "Matches the Payliance trace" }

confirm settles the payment as at the bank date — or, on an ach_return row, reverses it. payment_id is needed when the row does not name a single payment; it must be on the row's line, for the bank amount, and pending (or, for a return, already applied). Confirming closes the same transaction's open rows on other lines as superseded. reject records that the transaction is not this line's payment, and it is not offered again. A row that already settled or reversed a payment cannot be overridden: if the money did not land, reverse the payment.

A worked example

Five transactions post in March on a 30-day term with a 1% fee at 20% APR. Nothing accrues in March; the March statement bills $45,450.00 of principal and fees. By 15 April two loans are past their due dates and have accrued $72.33 and $23.29. A $30,000 payment on 15 April retires those two loans and a third in full (interest, fee, principal), clears the fee on the fourth and pays $6,824.38 of its principal, and does not touch the fifth. The April statement bills $15,581.97: the remaining principal, the fifth loan's fee, and $36.35 of interest accrued to 30 April.

Underwriting

Request an assessment during the application; it returns pending, already carrying waiting_on, wait_deadline and ready_at (below), worked out when the request is made. Bank backfill, categorisation, and enough history for trailing ratios can take up to three days. Poll GET /credit/underwriting/assessments/{id} for status, completed_at, and failure_reason, or watch the event feed for credit.underwriting.completed.

The nightly sweep measures a pending assessment only once the merchant's data has landed: a bank connection exists and its first Plaid sync (the historical backfill) has finished, the categoriser has been over the imported transactions (no more than 2% still waiting for a first pass), and, when a Shopify store is connected, a sync or a Shopify pull has finished in full and no history import is still running (orders arriving are not enough: the import writes them for hours before it ends). It also checks that the data is current: a Plaid connection the merchant must log in to again, or a bank feed failing for a reason you must fix (not_shared, not_found, auth_failed, not_configured), waits on bank_reconnect and emits credit.bank_connection.reconnect_required; a bank source that has not synced, or whose newest balance is not recent, waits on bank_data_stale; a store not pulled in the last 3 days waits on shopify_data_stale. These are the same tests the measures apply (see Underwriting measurers). When the scorecard has a chargeback rule (shopify_chargeback_rate), a store's sales are not enough: the sweep also waits until a finished sync has pulled the twelve months of disputes the rule counts, the same test that leaves the rule unmeasured (dispute_history_incomplete) until then. Until then the assessment stays pending and says what it is waiting on:

POST /credit/underwriting/assessments/{id}/run does not wait: it measures and completes at once, and records what was still missing in waiting_on. Its optional body takes as_of, segment (for per-segment thresholds, see Criteria) and fail_if_unmeasurable (true marks the assessment failed when no criterion could be measured). It is open to any token on a sandbox business and an operator action on a live one (an API token receives 403 AUTH_057; see Operator actions). The record behind these fields is financials._readiness, which also carries completed_because (data_ready, deadline or on_demand) and the counts the check read.

DayZero measures every criterion on the program's active scorecard that has a registered measurer from the categorised ledger, the bank feed, Shopify, and the debt schedule, and returns per-criterion value, threshold, comparator, passed, source, and evidence, plus a weighted score_bps. passed: null means the figure could not be measured yet, which is different from a failure; unmeasured_reason says why. unmeasured_keys lists the measure keys that came back unmeasured and required_unmeasured the required ones among them: score_bps leaves unmeasured criteria out (under the default exclude_from_denominator policy), so a score of 10000 with most criteria unmeasured rests on very little. decision is null until the lender records one (see Recording the decision).

Send auto_approve: true (with external_merchant_id, and optionally merchant_legal_name and merchant_email) and DayZero opens the merchant's line itself when the completed assessment allows it, and records the approval (decided_via: auto). A token opens lines only on an active program, as POST /credit/lines does.

Who asked. auto_approve sent on the request, true or false, is what applies. A request that omits it takes the program's auto_approve_default (see Program parameters): true and the assessment auto-approves as if the request had asked; false (the default) and the lender records the decision. On a sandbox a partner application (an external_merchant_id, or an external_application_id starting tie:) auto-approves even when neither asked. The assessment's auto_approval.source says which applied: request, program_default or sandbox_implicit; it is set from the moment the assessment is requested, so a pending assessment already says whether a line will open on its own. An integration that never sends auto_approve is switched to automatic approval by turning the program's default on, with no change on its side.

The gate. On a live business a line opens when:

• no criterion failed (any failure, required or not, opens nothing);
• every criterion that is required for the application was measured. A criterion that is not required and could not be measured does not hold the line: a merchant with no Shopify store, no scheduled debt (debt_service_coverage_ratio reads no_debt_service) or no invoices is judged on what it does have;
• at least one criterion passed;
• every required manual check that applies was attested (see the hold below).

On the sandbox only failures (of a criterion, or of a required manual check) stop it, so a synthetic merchant with no history can rehearse the whole flow. A sandbox application with an external_merchant_id (or an external_application_id starting tie:) auto-approves even when auto_approve is not sent; send auto_approve: false to hold a sandbox application for a lender decision, e.g. to rehearse a decline.

The limit. When the scorecard sizes limits (scoring.limit_sizing, below) the line opens at the lower of the requested limit and the sized one; with no requested limit, at the sized one (and the rules written as a multiple of the limit are scored at it). Either way it is held to the program's maximum. A request below the program's minimum opens nothing rather than lending more than was asked (requested_limit_below_program_minimum), and neither does a sized limit below it (sized_limit_below_program_minimum). On a live business a scorecard that sizes limits and found nothing to size from opens nothing (limit_sizing_unmeasured); a sandbox falls back to the requested limit. The term is the requested one, else the program's first.

An oversized request. A merchant who applies for more than its measures support fails the rules written against the limit (× requested limit, or a required or applies_when condition on it) at the limit applied for, while every other rule reads the same figure whatever the limit. When only such rules failed and the sized limit is lower than the requested one, DayZero scores the application again at the sized limit, the limit the line would open at anyway. If nothing fails there, that second evaluation is the recorded result: criteria (each limit rule's threshold resolved at the sized limit), the counts, score_bps and grade are its, and the assessment carries limit_rescored (requested_cents, sized_cents, reason: rescored_at_sized_limit), as do auto_approval, credit.underwriting.completed and credit.underwriting.decided. The first evaluation is kept on the record (financials._evaluation_at_requested: its summary and criteria at the requested limit), so what was applied for and refused can always be read. If something still fails at the sized limit, or a rule that reads no limit failed, or the scorecard does not size limits, the result at the requested limit stands as it always did and limit_rescored is null. The gate then runs on the recorded result, so an application re-scored this way opens at the sized limit (limit_source: sized) with no decline recorded for the larger request. This is deterministic: the same figures and the same scorecard always give the same result.

The rate. A line opened from an assessment, automatically or by an approval that names no approved_rate_bps, takes the scorecard's rate for the assessment's grade (scoring.rate_by_grade), else the program's default_rate_bps, else 1800. The assessment's pricing says which (rate_bps, rate_source: grade, program_default, platform_default, request or existing_line, and grade).

The manual-check hold. A manual check marked required on the scorecard holds the line while it is pending: auto_approval.status is held with manual_checks_pending. When a reviewer attests the last required check (POST /credit/underwriting/assessments/{id}/manual-checks/{check_id}, status: attested) DayZero runs the same gate again on the figures the completion recorded and, if it passes, opens the line and emits credit.line.opened and credit.underwriting.decided (decided_via: auto). A required check attested failed opens nothing (manual_check_failed); one with an exception noted also opens nothing (manual_check_exception). Neither is a final decline or queues an adverse-action notice.

What happened is on the assessment as auto_approval and in the credit.underwriting.completed event:

credit.underwriting.completed carries status (completed or failed), the counts, unmeasured_keys, required_failed, required_unmeasured, weighted_score_bps, grade, segment, auto_approval (null unless the request, the program's default or the sandbox asked for it), limit_sizing (null without sizing) and limit_rescored (null unless re-scored); a line opened this way also emits credit.line.opened and credit.underwriting.decided, so one field answers for every outcome.

Limit sizing and risk-based pricing

In the console, edit a draft scorecard version's Limit sizing and pricing section: add basis measures in priority order, their annualising multipliers, the percentage of that annualised figure to lend, optional caps, and the rounding increment (entered in dollars). Rate by grade takes percentages for the grade bands defined under Scoring; blank uses the program default. Saving does not change the active policy: validate, approve and activate the version as usual. No sizing or rate policy is added until you choose it.

Both live on the scorecard's scoring object, so they are versioned, validated and approved with the rest of it:

{
  "method": "weighted_pass_ratio",
  "unmeasured_policy": "count_as_zero",
  "limit_sizing": {
    "basis": [
      {"measure": "trailing_3m_revenue", "multiplier": 4},
      {"measure": "trailing_12m_revenue", "multiplier": 1},
      {"measure": "shopify_trailing_12m_revenue", "multiplier": 1}
    ],
    "percent_of_annual_bps": 200,
    "caps": [
      {"measure": "average_daily_cash_balance", "multiple": 2},
      {"measure": "trailing_12m_ad_spend", "multiple": 0.0626}
    ],
    "round_down_to_cents": 10000
  },
  "rate_by_grade": {"A": 1500, "B": 1800, "C": 2100, "D": 2400}
}

The sized limit is the first basis measure that was measured above zero, times its multiplier (to a year), times percent_of_annual_bps; then held under each caps entry that was measured (value × multiple; an unmeasured cap is skipped and reported) and rounded down to round_down_to_cents. The assessment's limit_sizing shows every input: basis_measure, basis_value, basis_multiplier, annual_basis, basis_limit_cents, each cap with its cap_cents, binding (the measure that set the figure) and sized_limit_cents (null, with reason: sizing_basis_unmeasured, when no basis measure had a value). The validator refuses a sizing measure DayZero cannot measure or that is not a currency, and warns about a rate_by_grade label no grade band uses, or a band with no rate. A scorecard without limit_sizing lends the requested limit, as before; one without rate_by_grade prices at the program's default.

The figures in the standard seed follow from its own limit rules: §10 asks for three months of revenue of at least 12 times the limit, which allows about 2.08% of annualised revenue, so the seed sizes at 2% of the annualised three-month figure (roughly a week of sales); §7 asks for average daily cash of at least half the limit, so cash caps it at twice the average; the ad-spend rule (twelve months of ad spend at least 15.96 times the limit) caps it at 0.0626 times that spend. A limit sized this way passes the limit rules it was sized from. The seed scores count_as_zero, so a merchant whose debt service or customer concentration could not be measured grades lower than one whose could; with every applicable rule passed, a bank-only merchant scores about 84% (grade B, 18%), and one that also has Shopify data, from which its customer concentration can be read, about 91% (grade A, 15%).

Which rules apply to whom

applies_when and required can read shopify_data (1 when DayZero holds Shopify data for the merchant: a connected store or pulled orders; 0 otherwise). The standard seed's refund and chargeback rules apply only when it is 1, and the chargeback rule is required only then: a merchant with only bank data is not held for Shopify figures it cannot have. debt_service_coverage_ratio and revenue_concentration_top_customer are scored but not required, so their absence never holds a line.

Recording the decision

The scorecard is evidence; the decision is the lender's. Record it on a completed assessment with POST /credit/underwriting/assessments/{id}/decision, from a token with the credit scope (sandbox and live) or in the console, where a live business asks for the same two-factor check as other sensitive credit writes:

{
  "decision": "approved",
  "merchant_message": "Welcome aboard.",
  "note": "Credit committee, 3 Nov",
  "approved_limit_cents": 20000000,
  "approved_term_days": 60,
  "open_line": true
}

decision is approved or declined. merchant_message (up to 1000 characters) is shown to the merchant as written. note (up to 2000) is internal: it appears in the console only, never in a token's response or an event. On an approval approved_limit_cents and approved_term_days default to the requested ones (the limit to the sized one when that is lower) and must fit the program (CREDIT_512, CREDIT_513); they are refused on a decline (CREDIT_554). approved_rate_bps sets the rate of a line the approval opens; without it the line is priced as above (grade, then program default). With open_line (the default) DayZero opens the line the way auto-approval does, or links the one already open for the merchant; open_line: false records the approval and opens nothing. If the line cannot be opened nothing is recorded and the error is returned. A decline queues the adverse-action notice when the program's compliance policy has them on.

One decision per assessment. Repeating the same one returns the record (200); a different one is 409 CREDIT_553; a pending or failed assessment is 409 CREDIT_552. Reversing a decision is not supported. The assessment's decision then reads:

The decision is emitted once as credit.underwriting.decided.

Decision requirements (optional). Operators can configure underwriting_decision_policy on the program. max_evidence_age_days defaults to null (no expiry); when set, approvals require an assessment requested within that many days. An expired explicit approval returns 409 with reason: evidence_expired; automatic approval reports the same gate reason and opens nothing. Request a new assessment rather than changing the completed evidence. No expiry interval is supplied by DayZero.

decline_reason_catalog maps lender-approved codes to merchant-facing sentences. Send decline_reason_codes on the final decline to select its principal reasons. The selected code and sentence are frozen as decision.decline_reasons and included in the decided event and notice. Unknown codes and reasons on approvals are refused. require_decline_reasons defaults to false; enabling it requires at least one selection. Failed criteria remain assessment evidence and are never automatically asserted as the lender's principal reasons. A decline without selected reasons can still be recorded under the default policy, but its notice cannot be sent.

Nonfinal updates. Subscribe to credit.underwriting.updated for data-required and manual-check/gate transitions. It carries assessment_id, external_application_id, monotonically increasing version, assessment status, waiting_on, auto_approval_status, gate_reasons, and manual-check ids/statuses. Unchanged rechecks emit nothing; returning to an earlier state creates a new version. Internal notes and recipient identity are excluded. Completion and final-decision events retain their separate, once-per-assessment meaning.

Application-only notices. The existing notices-due Send action can deliver a final decline before any line exists. It uses the application's recorded merchant_email, merchant_legal_name, merchant_state and merchant_address, the program's enabled adverse-action policy, and an approved template. Delivery uses the existing transaction-staged, deduplicated borrower-notice pipeline. No automatic send is enabled. Notices whose source is not a final decline, or whose reasons do not match the decision, are blocked for operator review.

For historical reconciliation, operators can run uv run python -m scripts.admin.report_credit_decline_notices --business-id <uuid>. This read-only report lists missing final declines and missing/mismatched decision reasons, including sent records. It neither rewrites decisions nor infers reasons. Review pending records through the existing reason-required waiver workflow; sent records require operator review.

Send what is being applied for with the request:

POST /credit/underwriting/assessments
{ "program_id": "...", "external_application_id": "app_00417", "requested_limit_cents": 25000000, "requested_term_days": 60 }

The request is refused before anything is recorded when there is nothing to measure it against: a program_id that is not one of your programs is 404, and when neither the request (scorecard_version_id, criteria_override) nor the program (underwriting_criteria or an active scorecard version; none when the request names no program and no line) gives criteria, the call is 409 CREDIT_POLICY_UNDECIDED (an assessment opened then could never complete). Activate a scorecard version (see The scorecard), or name one.

Send external_application_id and the request is safe to repeat: a second request with the same external_application_id for the same credit_line_id (or, with no line, for the business) returns the assessment the first one opened, in whatever state it has reached, and opens nothing. Completing an assessment closes it: POST /credit/underwriting/assessments/{id}/completion on an assessment that is already completed or failed is 409 with code: "CREDIT_556", as deciding a limit review twice is refused. Read the assessment instead of completing it again. Completion scores figures the caller supplies (measured_values, a map of criterion key to figure, is required; financials, evidence, segment and manual_checks are optional), so, like /run, it is open to any token on a sandbox business and an operator action on a live one (an API token receives 403 AUTH_057).

Each criterion in the response carries, beside the fields above: threshold resolved for this application (a 0.5 × limit rule at a $250,000 limit reads 125000), threshold_basis and threshold_value as written on the scorecard, required as it applies to this application, and applicable (false when the rule's applies_when excludes the application; such a rule is not scored). The response names what it ran against in scorecard_version_id and scorecard_version_number (null for an override), so the result can be reproduced later even after the scorecard changes, and the program the application is under in program_id (the line's, or the one the request named; null on an ad-hoc assessment with neither).

A completed assessment carries adverse_action_reasons: the criteria that were measured and failed, as criterion_key, label, measured, threshold, comparator, direction (below, above, not_equal, equal, outside), required, weight and contribution_bps (the criterion's weight over the points the application could earn). Required criteria come first, then the heavier weights. GET /credit/underwriting/assessments/{id}/adverse-action adds explanatory sentences. These are assessment evidence for the reviewer, not the final decision's principal reasons. Notices use only the explicitly selected decision.decline_reasons.

required_failed lists the measure keys (trailing_12m_revenue, …) of the required criteria that failed, each key once even when two rules on the same key failed. To see which rule failed, read criteria[]: each entry has its id, label, required and passed.

grade is set when the scorecard has grade bands. manual_checks lists the policy items a person reviews (restricted industries, lien searches, and the like), each pending, attested, exception, or not_applicable. Attest one with POST /credit/underwriting/assessments/{id}/manual-checks/{check_id} ({ "status": "attested", "note": "...", "attachment_s3_key": "..." }), or send manual_checks with the completion call (an operator's, on a live business). attachment_s3_key is the s3_key that POST /api/v1/upload/direct returns for the uploaded evidence; that endpoint is outside the credit surface, so a credit-scoped token cannot call it, and a check that requires evidence is attested in the console or with an unscoped token. Manual checks are reported beside the score. They never change it and never record a decision.

The merchant's bank connection

The assessment reads the merchant's bank feed, which lives on the merchant's own DayZero business. Start the connection from your Apply wizard's Connect step: DayZero finds the merchant's business, or creates it the first time, and hands you a hosted Plaid Link for the merchant to complete inside your wizard. DayZero emails nothing.

POST /credit/bank-connections
{ "program_id": "...", "external_merchant_id": "tie_merchant_00417",
  "merchant_email": "ap@merchant.com", "merchant_legal_name": "Northwind Goods LLC",
  "completion_redirect_uri": "https://apply.example.com/connect/done" }
-> { "id": "...", "status": "pending", "hosted_link_url": "https://hosted.plaid.com/...",
     "expires_at": "...", "merchant_business_id": "...", "merchant_business_created": true }

The response is the connection: id, status (pending, completed, failed or expired), created (false when a connection already pending for the merchant, or the line, was returned instead of a new one), hosted_link_url (null once the connection is no longer pending), expires_at (four hours), merchant_business_id, merchant_business_name and merchant_business_created. Send merchant_business_id as the assessment's subject_business_id. The business is linked to your business from then on, and the person who started the connection (the token's owner, for a token) is given read access to it, a viewer membership, so the token reaches it as a subject: it is listed by GET /credit/underwriting/subject-businesses and accepted as subject_business_id and merchant_business_id. A token limited to your business reaches it too, but never as x-business-id. Another person's token reaches it once they start a connection for the merchant. If Plaid will not make the Link the call is 503 CREDIT_787 and nothing is kept.

When the merchant finishes, the connection lands on the merchant's business like any bank connection, its accounts are linked, and the bank backfill the assessment waits on (waiting_on: bank_connection, then bank_backfill) starts. The connection becomes completed with institution_name and accounts (each plaid_account_id, name, mask, type, subtype; never a number or token), and plaid_account_id names the repayment account: the one checking account the merchant shared, else the one depository account, else none. On a line it is recorded there (plaid_account_id, linked_account_mask, linked_account_name) and recorded_on_line is true. credit.bank_connection.completed is emitted with the same fields. A merchant who leaves Link fails the connection (failure_reason: exited; plaid_error when Plaid could not connect, no_accounts when nothing was shared) and credit.bank_connection.failed is emitted. A Link not used before expires_at reads expired and emits nothing. After a failure or expiry, start again: the new Link is on the same business.

Read the connection with GET /credit/bank-connections/{id} if your wizard polls it rather than the feed. When the merchant has finished and Plaid's notice has not reached DayZero, the read asks Plaid itself. A connection on another business is 404 CREDIT_783.

A line opened later with the same external_merchant_id is linked to the merchant's business (unless the request names another merchant_business_id), and takes the repayment account when the request sends no plaid_account_id, linked_account_mask or linked_account_name. A connection the merchant has yet to finish then records its account on that line.

Change Payment Method. GET /credit/lines/{id}/linked-accounts lists every bank account the line's merchant has linked on DayZero: plaid_account_id, name, mask, type, subtype, institution_name, connection_status (the connection's state at DayZero, requires_reauth when it needs the merchant again) and on_line (the account on the line now), with the line's merchant_business_id and plaid_account_id. A line linked to no business lists nothing. Record another account with PATCH /credit/lines/{id}; connect a new bank with POST /credit/bank-connections and credit_line_id.

Sending the merchant's data

A merchant you bring through the credit API has a DayZero business that holds only what you send. Every measure on the scorecard reads one of the sources below; send each one you hold, and the measures that read it are measured instead of passed: null. Every call names the merchant the same way (program_id with external_merchant_id, or credit_line_id; merchant_legal_name and merchant_business_id as for a bank connection, with the same CREDIT_780, CREDIT_781, CREDIT_784 and CREDIT_788 refusals), creates the merchant's business the first time, gives your token read access to it, and is safe to repeat. They all land on one business per merchant, whichever comes first. A business created this way gets DayZero's standard chart of accounts, so its bank rows are categorised to sales, transfers, loans and expenses rather than left in Uncategorized.

Only the bank is required: the assessment waits for it (waiting_on). The rest never hold an assessment; a source you do not send leaves its measures unmeasured. GET /credit/merchant-data (the merchant by merchant_business_id, credit_line_id, or program_id with external_merchant_id) lists every source with status (provided, not_provided or stale), required, last_received_at, items, the measures it feeds and, when it is missing or old, what to send (detail); a merchant you have no business for is 404 CREDIT_836. The same states are on the assessment's readiness record as financials._readiness.detail.sources.

Pushing the bank yourself

The recommended way to bring a merchant's bank: you already hold the accounts, transactions and balances in your own backend, so you push them and nothing else is read. Register a feed with "provider": "direct_push" and your own key for the merchant as app_id (letters, digits and underscores; nothing is read from BigQuery), then push, as often as you like:

POST /credit/bank-feeds
{ "provider": "direct_push", "app_id": "tie_merchant_00417", "program_id": "...",
  "external_merchant_id": "tie_merchant_00417", "merchant_legal_name": "Northwind Goods LLC" }
-> { "id": "...", "status": "pending", "created": true, "provider": "direct_push",
     "merchant_business_id": "...", "merchant_business_created": true, "accounts": [] }

POST /credit/bank-feeds/{id}/ingest
{ "accounts": [{ "account_id": "acct_1", "institution_name": "First Bank", "display_name": "Operating",
                 "last4": "4242", "type": "cash" }],
  "transactions": [
    { "transaction_id": "txn_1", "account_id": "acct_1", "amount_cents": 1500000, "currency": "USD",
      "description": "SHOPIFY PAYOUT", "status": "posted", "transacted_on": "2026-10-30",
      "category": "INCOME_OTHER_INCOME", "category_source": "stripe_fc" },
    { "transaction_id": "txn_2", "account_id": "acct_1", "amount_cents": -3500, "currency": "USD",
      "description": "SERVICE CHARGE", "status": "posted", "transacted_on": "2026-11-02",
      "category": "BANK_FEES_OVERDRAFT_FEES", "category_source": "stripe_fc" },
    { "transaction_id": "txn_0", "account_id": "acct_1", "status": "void", "amount_cents": 0,
      "description": "reversed", "transacted_on": "2026-10-29" } ],
  "balances": [{ "account_id": "acct_1", "as_of": "2026-11-05", "current_balance_cents": 4250000, "currency": "USD" }] }
-> { "inserted": 2, "updated": 0, "voided": 1, "pending_skipped": 0, "balance_days": 7,
     "accounts_used": 1, "accounts_skipped": 0, "feed": { ... } }

Up to 100 accounts, 5,000 transactions and 1,000 balances a call: send a long history in pages, oldest first. Send at least a year of history and the twelve-month measures stop reading insufficient_history; a bank-only merchant with less is scored on an annualised figure only where the criterion opts in (allow_annualized). Each posted row is booked on the account's bank ledger with its journal entry, and after a push that changed anything the vendor naming, transfer detection, payout matching and categorisation a Plaid feed gets run on the merchant's business. Underwriting treats the feed as the merchant's bank: the assessment no longer waits on bank_connection, bank_backfill clears with the first push (first_synced_at), and the feed reads active.

Freshness. The bank measures read what you push for three days: while the feed's newest transaction or balance is more than 3 days older than the day measured (a balance may trail by 4), the assessment waits on bank_data_stale and the bank measures (average_daily_cash_balance, cash_runway_months, nsf_count_12m, shadow_debt_and_mca_90d) come back unmeasured with bank_data_stale and the source in evidence.bank_sources. So push at least daily while a merchant is being assessed, and push its closing balance each day. GET /credit/bank-feeds/{id} shows latest_transaction_on and latest_balance_on; GET /credit/merchant-data reports the bank as stale with what to send.

The merchant's bank feed from your BigQuery

When you already hold the merchant's bank through Stripe Financial Connections and copy it into BigQuery (one dataset per organisation, ab_stripe_fc_{app_id}, with the accounts, transactions_current and balances tables), DayZero can read it there instead of asking the merchant for a Plaid Link. Grant DayZero's service account READER on each dataset (we send you its email; never a project-level role), then register the merchant's feed:

POST /credit/bank-feeds
{ "app_id": "org_abc123", "program_id": "...", "external_merchant_id": "tie_merchant_00417",
  "merchant_legal_name": "Northwind Goods LLC" }
-> { "id": "...", "status": "pending", "created": true, "dataset": "<project>.ab_stripe_fc_org_abc123",
     "merchant_business_id": "...", "merchant_business_created": true, "accounts": [] }

app_id is the organisation id the dataset is named after (letters, digits and underscores; 400 CREDIT_831 otherwise). The merchant is named as for a bank connection (program_id with external_merchant_id, or credit_line_id; the CREDIT_780, CREDIT_781, CREDIT_784 and CREDIT_788 refusals above apply), and it is the same business: a feed and a bank connection for one merchant land on one DayZero business, a line opened later for the merchant is linked to it, and the caller is given read access to it as a subject. Send merchant_business_id from the response as the assessment's subject_business_id. Registering the same app_id again returns the feed (created: false), and resumes it if it was removed; for another merchant it is 409 CREDIT_832, with the feed's bank_feed_id and merchant_business_id.

DayZero syncs a feed when it is registered and every six hours after. Each sync reads what arrived since the last one and writes it to the merchant's business: every posted transaction (amounts as Stripe gives them, money in positive) on a bank ledger per account with a journal entry against Uncategorized Income or Expense, then the same vendor naming, transfer detection, payout matching and categorisation a Plaid feed gets; a voided transaction is hidden; a pending one is left until it posts. Each reported balance is that day's closing balance, and every other day back to the first transaction is worked out from the nearest reported balance and the day's transactions, so the average daily balance has a figure for each day. An account the merchant also connected through Plaid (same last four at the same bank) is left out, or its money would be counted twice, and so is a credit account (skipped_reason: covered_by_plaid, credit_account). Stripe returns up to 180 days of history, so rules over twelve months read insufficient_history from the bank alone, unless the criterion opts into an annualised figure (allow_annualized, see Criteria). Balances keep their currency (the key of Stripe's balance hash; currency on a pushed balance, default USD), and underwriting reads only those in the merchant business's own currency.

Underwriting treats the feed as the merchant's bank: the assessment no longer waits on bank_connection, and bank_backfill clears when the first sync lands (first_synced_at).

The rest of the merchant's data

The sources that need no bank: each is pushed the same way, named for the same merchant, and read by the measures in the table above.

Shopify. For a merchant whose Shopify Admin API token you keep, POST /credit/shopify-pull reads its orders, refunds, disputes and Shopify Capital transactions onto the merchant's business without DayZero storing the token. Encrypt the token with the API token you call with as the key:

1. salt: 16 to 32 random bytes, hex. iv: 12 random bytes, hex.
2. key = PBKDF2-HMAC-SHA256(your API token, salt, 100,000 iterations, 32 bytes).
3. AES-256-GCM-encrypt the Shopify token with key and iv, with the normalised shop_domain (<store>.myshopify.com, lowercase) as additional authenticated data. Send the ciphertext base64 as encrypted_token and the 16-byte tag hex as auth_tag.
4. token_hash = hex SHA-256 of {salt}:{shop_domain}:{shopify token}.

POST /credit/shopify-pull
{ "program_id": "...", "external_merchant_id": "tie_merchant_00417", "shop_domain": "northwind.myshopify.com",
  "encrypted_token": "...", "salt": "...", "iv": "...", "auth_tag": "...", "token_hash": "..." }
-> { "merchant_business_id": "...", "orders_synced": 1840, "refunds_synced": 41, "disputes_synced": 3,
     "capital_transactions_synced": 0, "orders_complete": true, "disputes_complete": true,
     "token_persisted": false, "synced_at": "..." }

The token needs read_orders (and read_shopify_payments_disputes for the chargeback rule). The Shopify measures read a pull for 3 days (shopify_data_stale after), so pull at least that often while a merchant is being assessed. orders_complete or disputes_complete false means part of the window was not read and the measures that need it stay unmeasured until a pull completes. A call without a Bearer credential is 400.

Profile. PUT /credit/merchant-profile takes business_started_on (not in the future), legal_entity_type (sole_proprietorship, partnership, llc, s_corp, c_corp, nonprofit, other), naics_code (2 to 6 digits), mcc (4 digits), industry, country (ISO alpha-2) and currency (ISO 4217). Fields left out keep what an earlier call set. months_in_business reads the start date first, with evidence.source: partner_profile and basis: declared; without one it falls back to the first Shopify order or bank transaction, basis: inferred, a lower bound. The currency becomes the merchant business's while its books are empty (currency_applied), and every measure reads money in it.

Existing debt. PUT /credit/debt-facilities replaces the merchant's facilities with the list you send:

PUT /credit/debt-facilities
{ "program_id": "...", "external_merchant_id": "tie_merchant_00417",
  "facilities": [{ "facility_id": "mca_77", "lender": "QuickCap", "facility_type": "mca",
                   "current_balance_cents": 3000000, "payment_amount_cents": 25000,
                   "payment_frequency": "daily", "maturity_on": "2027-03-01" }] }
-> { "facilities": 1, "created": 1, "updated": 0, "removed": 0, "none_attested": false,
     "total_balance_cents": 3000000, "annual_debt_service_cents": 6300000, "declared_at": "..." }

Each facility has your facility_id (sent again it is updated, left out it is removed), lender, facility_type (term_loan, line_of_credit, mca, revenue_based, sba_loan, equipment_loan, mortgage, credit_card, other), current_balance_cents, and optionally original_amount_cents, payment_amount_cents with payment_frequency (daily counts 252 business days a year, weekly, biweekly, semi_monthly, monthly, quarterly, annual), interest_rate_bps, started_on and maturity_on. They go on the merchant's debt schedule, where existing_debt_facilities (the balances) and debt_service_coverage_ratio (earnings over a year's payments) read them; nothing is posted to its ledger. "facilities": [] attests the merchant has no debt: existing_debt_facilities reads 0 (none_attested_on), where with no schedule and no attestation it is unmeasured (no_debt_schedule), and debt_service_coverage_ratio reads 100 (evidence.capped; 0 when the business spends more than it earns), where it is otherwise unmeasured (no_debt_service). Both carry none_attested and partner_declared_at in their evidence.

Ad spend. POST /credit/ad-spend upserts daily spend:

POST /credit/ad-spend
{ "program_id": "...", "external_merchant_id": "tie_merchant_00417",
  "covered_from": "2025-10-01", "covered_through": "2026-11-04",
  "days": [{ "platform": "meta", "spent_on": "2026-11-04", "spend_cents": 182000, "currency": "USD" },
           { "platform": "google", "spent_on": "2026-11-04", "spend_cents": 64000, "currency": "USD",
             "account_id": "123-456-7890" }] }
-> { "days_written": 2, "covered_from": "2025-10-01", "covered_through": "2026-11-04", "other_currency_days": 0 }

One row per platform (meta, google, tiktok, other), account_id (optional) and spent_on; sending one again replaces it. covered_from to covered_through (default: the earliest and latest day sent) is the window your figures are complete for: a day in it without a row is a day with no spend, so a window with no days attests none. Windows widen across pushes. The ad-spend measures read this spend before the Advertising & Marketing ledger and Meta Ads (evidence.source: partner_ad_spend, with partner_ad_spend_by_platform) while the window covers 90% of the measure's and covered_through is no more than 3 days before the day measured (partner_ad_spend_stale otherwise, and the measure falls back to the ledger or Meta). A measured window with no spend reads 0. Spend in another currency than the merchant's books is kept and not counted (partner_ad_spend_excluded_currency_days).

Invoices. POST /credit/receivables upserts the merchant's invoices to its customers by invoice_id: customer_id, customer_name, amount_cents, currency, issued_on, due_on, paid_on and status (open, paid, void; default paid with paid_on, else open). Up to 5,000 a call; invoices not sent are kept. When the merchant has no DayZero invoices, revenue_concentration_top_customer is the top customer's share of the invoices issued in the last 365 days in the books' currency, void ones left out (evidence.source: partner_receivables), before it falls back to Shopify orders.

Meta Ads. A merchant can also connect Meta Ads on its DayZero business, which the ad-spend measures read when no pushed spend covers the window. That connection is the merchant's own sign-in in DayZero; there is no hosted Meta link for a partner to hand out yet, so push the spend instead.

Limit reviews

A line opens at the limit you approved. With a limit_review_policy on the program, DayZero re-derives each line's limit on a cadence from the same measurers an assessment uses, records what it found as a review, and either proposes the new limit for an operator or applies it.

"limit_review_policy": {
  "enabled": true,
  "cadence": "weekly",
  "formula": { "basis": "trailing_3m_revenue", "pct_bps": 2500 },
  "floor_cents": 1000000,
  "cap_cents": 50000000,
  "max_step_up_bps": 2000,
  "max_step_down_bps": 5000,
  "min_change_cents": 100000,
  "triggers": [
    { "key": "shopify_refund_rate", "op": "gt", "value": 0.08, "action": "step_down_bps", "amount": 2500 },
    { "key": "cash_runway_months", "op": "lt", "value": 2, "action": "freeze" }
  ],
  "apply": "proposal"
}

The policy is checked when the program is saved: a floor or cap outside the envelope returns 400 (CREDIT_061), and so does narrowing the envelope under a stored policy; apply: direct on a program whose limit_change_policy is not direct returns 400 (CREDIT_062); a trigger on a measure DayZero does not have returns 400 (CREDIT_063). Send limit_review_policy: null to turn reviews off and drop the policy, or enabled: false to keep it.

How the limit is worked out

Always in this order, and every stage is recorded in the review's evidence.steps:

1. Formula. The basis × pct_bps, rounded down to whole dollars. When the basis cannot be measured, the current limit is the starting point and the formula is skipped.
2. Clamp. Into the floor and cap, and the program envelope.
3. Steps. No more than max_step_up_bps above the current limit, no more than max_step_down_bps below it.
4. Triggers. A step_down_bps trigger that holds caps the limit at the current limit less its cut; when several hold, the largest cut wins. A freeze trigger allows no increase. The floor and the envelope still hold after a cut, and a frozen line is never lifted above its current limit, even to reach the floor.

A result within min_change_cents of the current limit is no_change. A trigger whose measure cannot be read does not fire.

Worked example, with the policy above, on a $250,000 line: trailing three-month revenue of $1,200,000 gives $300,000; that is inside the $10,000–$500,000 floor and cap, and exactly the 20% step allowed, so the review recommends $300,000. If the Shopify refund rate were 11%, the refund trigger would cap it at $250,000 less 25%, so the review recommends $187,500. If cash runway were 1.4 months, the freeze would hold it at $250,000: no change.

freeze is not a suspension. The line, its cards and its spending are untouched; the review simply cannot raise the limit, and any open proposal on the line is withdrawn.

What a review reads

The basis and any trigger on the merchant's own books (revenue, ad spend, Shopify, bank) are read from the line's merchant_business_id. A line not linked to the merchant's DayZero business has those measures reported unmeasured with reason_code: "no_merchant_business", never read from your books, so its formula leaves the current limit standing. The two credit-book measures, credit_utilisation_90d and credit_repayment_performance_180d, are read from the line itself and work on every line. Each review's evidence.measurements holds every measure it read, with the same evidence an assessment shows.

Proposals and direct apply

A review that changes the limit is applied when the policy says apply: direct and the program's limit_change_policy is direct; otherwise it is proposed. A direct apply goes through the same path as PATCH /credit/lines/{id}: the limit is checked against the envelope, one credit.line.limit_changed event is emitted (its payload carries limit_review_id), and issuer-control recomputation is queued. applied describes the ledger decision; issuer delivery is tracked separately.

Decide a proposal:

POST /credit/limit-reviews/{review_id}/decision
{ "decision": "apply", "limit_cents": 28000000, "reason": "Credit committee, 3 June" }

decision is apply or dismiss; reason is required; limit_cents applies a different figure than the one recommended (it must sit in the envelope). Who may decide follows the program's limit_change_policy:

A decided review is final: deciding it again returns 409 (CREDIT_065). Applying a proposal after the line's limit has moved returns 409 (CREDIT_066); run a new review. Applying the limit the line already has returns 400 (VALIDATION_480). An unknown review id returns 404 (CREDIT_067). A newer review always replaces an open proposal on the same line: the old one becomes dismissed with the reason "Superseded by the review of …".

A review is DayZero's recommendation; a change someone asks for is a limit-change request, decided on the same tab under the same limit_change_policy. The two are separate records and do not replace each other: a pending request survives a new review, and an applied review does not touch a pending request (approving it afterwards sets the line to the figure the request names). See Limit changes.

Running and listing reviews

The nightly sweep reviews every active line (a suspended or closed line spends nothing, so it is not reviewed) whose program has an enabled policy and that has no review dated in the current cadence window; a review run by hand in the window counts. POST /credit/lines/{id}/limit-reviews/run (body {}, or {"as_of": "2026-06-01"}) runs one now whatever the cadence says, and is open to your token; it returns 400 (CREDIT_064) when the program has no enabled policy or the line is not active, and refuses a future as_of on a live business. GET /credit/lines/{id}/limit-reviews lists a line's reviews newest first.

Each review carries as_of, source (sweep or manual), cadence_window (2026-W23 or 2026-06), status, current_limit_cents, recommended_limit_cents, change_cents, applied_limit_cents, basis_key, basis_value (whole currency, null when unmeasured), frozen, triggers_fired (each with the figure measured), evidence, requested_by (null for the sweep), decided_by, decided_at and reason.

Events

credit.line.limit_review is emitted when a review proposes or applies a change, and again when a proposal is applied or dismissed (a superseded proposal included). The payload carries limit_review_id, credit_line_id, external_line_id, as_of, status, current_limit_cents, recommended_limit_cents, applied_limit_cents, basis_key, basis_value, frozen, triggers_fired (key and action), decided_by and reason. A review that changes nothing emits nothing. The limit itself only ever moves with a credit.line.limit_changed event.

In the console

The line's Limit reviews tab lists the line's limit-change requests first (see Limit changes), then every review with the limit when reviewed, the recommendation and the change, the basis, the triggers that fired, and the measurements and working behind it. A proposal has Apply (with the option to apply a different figure) and Dismiss, each asking for a reason; Review now runs one on the spot. The policy is edited in the program form under Limit reviews: cadence, basis and percentage, floor and cap, step limits, the smallest change worth making, whether a change is applied or proposed (proposed only, when the program's limit changes need an operator), and the triggers as rows.

Error codes

Covenants

A covenant is a promise the lender holds a line to, tested every night against the borrower's own books (the line's merchant_business_id): keep cash above a floor, leverage below a ceiling, debt service covered, inventory turning, current assets covering current liabilities, or any ratio of two ledger selections. Nothing a covenant finds changes the limit, the line or a card on its own.

POST /credit/lines/{id}/covenants writes one with kind (min_cash, max_leverage, min_dscr, min_inventory_turns, min_current_ratio or custom_ratio), threshold (whole currency units for min_cash, a decimal ratio otherwise), an optional comparison (gte, gt, lte, lt; the minimums default to gte, max_leverage to lte, and custom_ratio must say), warn_band_bps (a pass within this share of the threshold is a warning; 1000 = 10%), label, notes and active. A custom_ratio also carries numerator_selector and denominator_selector, each naming ledgers by ledger_ids, types (asset, liability, equity, revenue, expense) or concepts (asset.cash, liability.long_term_debt, expense.cogs, …), read as the balance as of the night or the net flow over window_days. PATCH /credit/covenants/{id} changes any of these (active: false stops the check and keeps the history); DELETE /credit/covenants/{id} removes the covenant and its checks.

How each built-in kind is measured: min_cash is the balance of the cash, petty-cash and undeposited-funds ledgers; max_leverage is total liabilities over equity, where equity is total assets less total liabilities; min_current_ratio is current assets over current liabilities, with fixed assets, equipment, accumulated depreciation, notes receivable and security deposits left out of the assets and long-term debt out of the liabilities; min_inventory_turns is cost of goods sold over the trailing 365 days over the average of the opening and closing inventory balances; min_dscr is the debt_service_coverage_ratio underwriting measurer. A figure the books cannot supply (no matching ledger, a zero denominator, a line with no merchant_business_id) reads unmeasured, never zero.

The nightly sweep's covenants step (check_covenants, default on) writes one check per covenant per night; POST /credit/lines/{id}/covenants/check (?as_of=) runs tonight's check now and re-records the night in place. GET /credit/lines/{id}/covenants lists the covenants with latest_check and recent_checks (the last 60 nights, oldest first); it is also open, read-only and without the add-on, to the business that borrows on the line (viewer: borrower). GET /credit/lines/{id}/covenant-checks pages the history newest first. Each check carries value, threshold, status (pass, warn, breach, unmeasured), consecutive_breaches, limit_review_id and inputs: every figure it was computed from, with the ledgers (ledger_ids, each with its cents) and the window (start_date, end_date) behind it, so a tripped value is traced through the money-flow lineage of those ledgers.

A warn or breach night emits credit.covenant_warning or credit.covenant_breach (once per covenant and night) and leaves the borrower a notification; a breach also alerts the operator. The third consecutive breached night files one limit review with source: covenant, status: proposed and recommended_limit_cents equal to the current limit, so a person decides what, if anything, to do, through the same Apply / Dismiss path as any proposal; it is never filed again until the covenant passes and breaches three nights afresh, and it does not count as the program's cadence review. Error codes: CREDIT_850 (404, no such covenant), CREDIT_851 (400, a custom_ratio without both selectors), CREDIT_852 (400, reserved for a line with no merchant books).

Cards

Cards are issued through the program's issuer (issuing_provider: Ramp by default, or Stripe Issuing, see Stripe Issuing); DayZero orchestrates and mirrors, and card credentials never transit DayZero. POST /credit/cards/{id}/embed-token mints a short-lived issuer token so the issuer renders the number inside its own component; each disclosure is audited (credit.card.credentials_requested, at most one per card per minute). The card must be active (400 otherwise). When the issuer answers without a token the call is 503 CREDIT_700 rather than an empty token that would render an empty component; nothing was disclosed, so no event is recorded. Try again shortly.

A card can also be issued in the call that opens the line: send card with POST /credit/lines (see Open a credit line); it goes through this same path, keyed line-open:<line id>.

POST /credit/cards with an idempotency_key issues one card per key per business. A repeat returns the card already issued under the key, on whichever line it was issued (the issuer deduplicates the key the same way), and a repeat that arrives while the first is still at the issuer waits for it; neither calls the issuer again. A failed attempt does not hold its key: sending it again issues. A new card is provisioned with a zero ceiling before its committed headroom is delivered. If the issuer returns a nonzero provisioning ceiling, DayZero attempts to freeze it and refuses the issue for reconciliation.

POST /credit/cards takes credit_line_id; optionally display_name (the label at the issuer: the merchant's legal name, else its external_merchant_id), card_type (virtual, the default, or physical), spend_limit_cents, spend_interval (TOTAL only for DayZero-managed cards), transaction_limit_cents, allowed_mcc_codes (default: the program's list), blocked_mcc_codes, auto_lock_date and idempotency_key; cardholder_provider_user_id is deprecated (see Open a credit line). New periodic limits are rejected because a daily or monthly reset could restore spending independently of the line budget. An explicit positive ceiling must fit the current line/program headroom; it cannot bypass an inactive line or disabled issuing. Omit the ceiling for automatic shared-headroom allocation (requested_spend_limit_cents: null); provisioning still starts at zero. The card's allowed MCCs may narrow the program's list, never widen it, and program blocks remain enforced.

PATCH /credit/cards/{id}/limits saves requested controls and queues delivery: spend_limit_cents, spend_interval, transaction_limit_cents, allowed_mcc_codes, blocked_mcc_codes, auto_lock_date and display_name. A supplied spend_limit_cents is retained as requested_spend_limit_cents, a lifetime cap that later balance changes do not erase. Omission or null keeps that cap; reset_spend_limit_cap: true removes it and returns the card to automatic shared-headroom allocation. Do not send a reset and a new numeric cap together. A zero cap prevents new spending. Clearing transaction_limit_cents is persisted as an explicit zero restriction so an issuer that merges patches cannot retain the old cap. Partner-managed controls must be changed at the partner.

Requested versus delivered. A card response carries requested_spend_limit_cents, issuer_sync_status (queued, pushed or failed), failure_reason, the last issuer-reported spend_limit_cents, and last_synced_at. queued means saved for later delivery; pushed means the delivery pass completed; failed requires inspection of the reason. A locally active card whose reactivation is queued may still be frozen at the issuer. Display those facts separately. POST /credit/lines/{id}/cards/spend-limit-sync queues a fresh recomputation and returns per-card queued outcomes (or skipped when there are no eligible managed cards); it does not synchronously apply a limit. POST /credit/cards/sync reads issuer state and reports reconciliation results; it is not a substitute for the delivery worker.

One line budget across cards. The worker divides the line's spendable headroom using a deterministic max-min fair allocation across eligible DayZero-managed cards, subject to each card's remaining requested lifetime cap. It never intentionally grants the full line headroom independently to each card. A lifetime (TOTAL) ceiling is cleared spend to date plus that card's allocation; a card with no allocation receives zero and stays frozen. A card's spend_limit_cents is the last reported ceiling, not its allocated headroom. GET /credit/lines/{id}/cards/monitor shows the reported ceiling and remaining capacity. Settlements must be attributed to the correct card, including card_last_four when pushing them, so lifetime spend is counted correctly.

Suspension and reinstatement. Explicit card suspension (POST /credit/cards/{id}/suspension) and termination (DELETE /credit/cards/{id}) still call the issuer synchronously as capacity-decreasing operations. Lifting suspension (DELETE /credit/cards/{id}/suspension) records the requested local activation and queues delivery; the worker installs the current shared budget before resuming eligible cards. Repeating a state already recorded returns the card without a second lifecycle event; retry queued or failed delivery through spend-limit sync. Suspending a card the merchant or collections froze takes the hold over (suspended_via: operator), so only an operator lifts it. A line-level suspension follows the asynchronous line status contract.

Merchant categories. A program's allowed_mcc_codes and blocked_mcc_codes are MCCs (the four-digit codes on every card transaction). At the issuer, Ramp blocks by MCC but allows only by its own category codes, so the delivered allow list uses the Ramp categories those MCCs fall under (advertising, SaaS / software, cloud computing, and so on). An MCC with no known Ramp category is reported and left out rather than guessed. On Stripe Issuing the allow and block lists use Stripe spending-control categories; the exact four-digit MCCs are also kept on the card and enforced on real-time authorization (below).

Durable issuer-control delivery

Origination, repayment, reversal, write-off, line-limit changes and control changes write a coalesced credit_issuer_sync_requests row in the same database transaction as the local change. A rollback removes that enqueue too. Provider capacity increases run only from a dedicated worker transaction after commit; an old request never replays an old numeric limit.

The Temporal credit-issuer-sync-poller runs every minute. Each delivery opens a fresh tenant-bound session, takes the line advisory lock and locks the current line, program, request and card rows before provider calls. It recomputes from committed balances and controls, then:

1. Reads and freezes every managed fund, verifying suspension before continuing.
2. Checks fund identity, legacy intervals and mixed-management capacity. Duplicate shared funds, unknown ceilings and active partner-managed funds in the reconciliation prevent increases and leave the managed funds frozen for review.
3. Applies decreases before increases, sends the full stored control set, and reads back each TOTAL ceiling.
4. Resumes only locally active cards with a positive allocation, after the complete line budget has been installed.

Legacy periodic cards are frozen and marked suspended_via: issuer_controls; they are not silently skipped or converted. Convert with PATCH /credit/cards/{id}/limits and spend_interval: TOTAL, reinstate, then set any revised lifetime cap. Review prior lifetime spend before choosing the cap. Program MCC restrictions are applied alongside card restrictions; a card whose stored allow list no longer overlaps the program fails for review.

Successful requests remain scheduled for a five-minute drift-repair pass. Failed delivery records per-card failures and the request's last_error, increments attempts, and retries with backoff from 30 seconds up to 15 minutes, subject to the one-minute poll cadence. Database/commit failures leave the durable request due. The poller processes at most 100 due lines per pass and skips overlapping workflow runs, so these cadences are not a guaranteed completion time.

Issuer-control deployment and recovery

1. Apply Alembic revision c8d4e2f6a901, following d9e4b2f8a731, before deploying code that reads the new card fields or writes the queue. It adds requested_spend_limit_cents, issuer_sync_status, and the tenant-isolated credit_issuer_sync_requests table, preserves existing ceilings conservatively as requested caps, and seeds requests for existing DayZero-managed issuer funds. Existing automatic versus explicit ceilings cannot be distinguished reliably; review before resetting a migrated cap.
2. Deploy the API and the Temporal worker with CreditIssuerSyncWorkflow and CreditIssuerSyncActivities, then deploy/run the scheduler so credit-issuer-sync-poller exists, is unpaused, and targets the worker's task queue. An API-only deployment can save changes indefinitely without delivering them. The worker needs the same owned issuer connections and server credentials as the API.
3. Check card issuer_sync_status, failure_reason, spend_limit_cents and last_synced_at, and inspect queue status, attempts, next_attempt_at, last_error and results through tenant-authorized operational access. A successful enqueue or sweep is not evidence of issuer application. Confirm that due requests are being processed and successful rows receive a new drift-repair date.
4. For a failure, fix the reported connection/ownership, duplicate fund, legacy interval, MCC or mixed-management issue before retrying. Reconcile partner-managed capacity and consolidate management before raising managed budgets on a mixed line. Queue a retry with POST /credit/lines/{id}/cards/spend-limit-sync, then verify the resulting card status and provider state. Do not mark a failed row delivered or remove the queue to hide the failure; a retry recomputes from the current book. A worker crash after remote changes is recovered by the same freeze/recompute/readback sequence.

Verification boundary. These controls are implemented and covered by local automated tests; this change has not been verified against live issuer providers or a production deployment. Retain existing audit events, review findings and failed-attempt evidence: migration and recovery do not rewrite the history or prove that a prior control was enforced.

Stripe Issuing

A program with issuing_provider: "stripe_issuing" issues its cards on Stripe Issuing. Every card call above (POST /credit/cards, card on POST /credit/lines, limits, suspension, termination, embed-token, sync, reconcile-settlements) works unchanged; this section is what differs.

Which Stripe account. The account locator is selected from the line's issuer_config.line_stripe_accounts entry, then the program's stripe_account_id / connected_account_id aliases, then a legacy acct_... in ramp_spend_program_id, then the business's canonical Stripe connection (Integrations → Stripe). Conflicting program aliases are rejected. Every selected account must be the business's canonical connection or be verified through Stripe metadata naming this business and the owned line; editable JSON is not ownership proof. Normal gateway construction and its program-and-line cache use this ownership boundary, including card controls, reconciliation, embed tokens and durable delivery.

Live operations require the server's Stripe credential and a connected account. JSON API keys and live/mock flags cannot override that choice. Explicit or implicit platform card issuance is blocked until a trusted business/program binding and resource-ownership path exist; superuser permission to inspect or configure the platform is not an issuance grant. Sandbox card operations use the credential-free mock, even when live server credentials exist. See Stripe account ownership.

issuer_config.default_cardholder_id supplies the cardholder when configured; otherwise the adapter creates one. Delivered lifetime ceilings map to Stripe spending_limits with all_time, the transaction cap to per_authorization, and MCC lists to Stripe categories plus the exact MCC metadata. The embed token is the secret of a Stripe ephemeral key for the card, for stripe.js to render the number. Issuance starts at zero capacity and controls use the durable delivery sequence above.

Approval and setup. Stripe enables card issuing per account; until the card_issuing capability is active, every issue fails with CREDIT_502 carrying Stripe's reason.

All three endpoints refuse sandbox businesses before any Stripe call. Connected-account diagnostics inspect account-scoped webhooks; a platform operator verifies the shared Connect subscriptions when those diagnostics cannot confirm them. Missing server credentials or invalid ownership on a live program fail readiness instead of silently using a mock issuer. The Stripe integration guide details account recovery and onboarding URLs.

In the console the program form shows a Stripe Issuing & Charge Card readiness panel when the issuer is Stripe Issuing, with Check Stripe account and Activate Stripe Issuing & Webhooks over these two calls.

Authorizations, settlements and disputes. Stripe's Issuing events arrive on DayZero's Stripe webhook endpoint (/api/v1/webhooks/stripe); the shared endpoint's receipt of platform events does not grant platform card access. issuing_authorization.request is answered synchronously: DayZero approves when the card is on a credit line and active, not past its auto_lock_date, the line is active, the amount is within transaction_limit_cents and the line's available_credit_cents, and the merchant's MCC is on the allow list (where there is one) and off the block list; otherwise it declines, and the reason is in the webhook acknowledgement. issuing_transaction.created and .updated originate the loan as a push would (a capture is a positive settlement, a refund a negative one tied to its original transaction), stamp the settlement source: stripe_issuing_webhook, and queue issuer-control recomputation. issuing_dispute.* open a hold on the loan and release it when the dispute is lost or cancelled (see Disputes and voids); issuing_card.updated mirrors a status or limit changed on Stripe; issuing_credit_policy.* and issuing_funding_obligation.* are recorded on the program's issuer_config. The nightly reconciliation lists the card's Stripe transactions for the window, so a missed webhook is caught (cards.ramp_webhook does not apply; see Launch readiness).

MCC allow list

The allow list is built from one of three sources, each previewed as the same table before anything changes:

Both calls are operator actions in the console (an API token gets 403); send us the export and we preview it with you. Every source returns one row per MCC, highest spend first: mcc, description, transactions, spend_cents, up to five merchants, ramp_category_code and ramp_category_name (both null and unmapped: true when Ramp has no known category for it), suggested (mapped, and seen at least min_count times; every preset code), and currently_allowed. An MCC on the current list that the source never saw is added at the end with in_source: false, so dropping it is visible. The response also carries suggested_codes, the Ramp categories they span, unmapped_codes, rows_read and rows_without_mcc, and for an upload file_sha256. A file can also be tallied from the command line with scripts/admin/credit/mcc_allowlist_from_export.py, which reads the same formats and applies through the same call with --apply.

An uploaded export is staged and scanned for malware like every other credit upload before it is read, then read in a worker thread, counted as it goes, and refused at the first cap it passes: 10 MB, 200,000 rows, 500 columns (a JSON export may name 500 different fields in all), 10,000 characters in one cell, and, for JSON, which is read whole, 2,000,000 values. An amount is read as positive cents; one no ledger can hold (9e999990, Infinity) refuses the file with CREDIT_592 naming the row and column, while text that is not a number at all counts as no spend, as it always has. The command-line script reads a local file of any length.

POST /credit/programs/{id}/mcc-allowlist/apply with {"codes": ["7311", "7372"], "source": "upload", "file_sha256": "..."} writes the list (sorted, duplicates dropped), saves it on eligible active or suspended DayZero-managed cards, and queues issuer delivery per line. source is the preview it came from, or manual; an upload's file_sha256 is required and goes into the audit entry with the source, so the exact file behind the list is on record. The response separates queued, pushed and failed counts and per-card results; a queued result is not an issuer-confirmed restriction. Inspect later delivery failures and retry after correcting their cause. Partner-managed cards are counted in partner_cards_not_pushed and never touched. To clear the list on purpose send {"codes": [], "source": "manual", "unrestricted": true}: that is recorded as a decision (mcc_allowlist_decided_at on the program), where an empty list with no date was never decided.

Off-list spend. The issuer is the control; DayZero is the alarm. When a settlement posts, by push or by the issuer's webhook, on a program with a non-empty allow list and its MCC is not on the list (or it has none), credit.settlement.off_allowlist is emitted once with the line, settlement, loan, MCC, amount and merchant, and reason (not_on_allowlist or no_mcc). The loan originates as usual. Refunds are not flagged. The nightly settlement reconciliation counts these as off_allowlist over its seven-day window.

In the console, the program form's MCC allow list section shows the current list and offers Upload card export, Learn from settlements and Use ad-spend preset; each opens the table with a checkbox per MCC (suggested ones ticked) and Apply.

Partner-managed cards

If you provision cards in the issuer yourself (card_management: partner on the program), DayZero never touches the card. Register each card once so cleared transactions can be attributed to the line:

POST /credit/cards/register
{ "credit_line_id": "...", "provider_card_id": "<issuer card id>", "provider_fund_id": "<issuer fund id>", "last_four": "4417" }

provider_fund_id lets DayZero read the card's spend controls back and is needed to move the card to DayZero later (see Switching who manages the cards). Optional fields: provider_user_id, provider (ramp, stripe_issuing, brex, lithic, external or mock; default the program's), display_name, expiration, cardholder_name, card_type, spend_limit_cents and spend_interval (TOTAL by default).

Idempotent on the issuer card id: registering it again on the same line returns the card. An issuer card id is registered once across DayZero, so one already on another line, yours or another business's, is refused (400 CREDIT_507) without saying where. From then on, every balance change emits credit.line.limit_changed with available_credit_cents; use the newest event to manage the aggregate capacity across the line's partner cards, accounting for lifetime spend where required by the issuer. Do not give every card that full headroom independently. An event is emitted whenever the figures differ from the newest one already on the feed, including when headroom returns to an amount it has held before. DayZero does not deliver controls to a registered partner-managed card.

Both managers can be recorded on one line. A registered card gets the credit.line.limit_changed event even on a dayzero program, and a DayZero-managed card still queues controls on a partner program. The program's card_management is the default for what comes next. This is not permission for two independent copies of the line budget: active partner-managed funds found during delivery block the managed-card rebudgeting pass, leaving managed funds frozen for review. Reconcile partner capacity and consolidate management before raising managed budgets.

Switching who manages the cards

POST /credit/programs/{id}/card-management with {"target": "partner"} or {"target": "dayzero"} moves the program's default safely. It is a dry run unless you send "dry_run": false, and returns the plan per line (who the line's limit goes to before and after) and per card:

Each card also says who manages it and who sets its limit after the switch (managed_by_after, limit_set_by_after). Applied, the switch writes card_management, adopts eligible cards, queues each adopting line, and emits one credit.line.limit_changed (reason: card_management_changed, with card_management and card_managers) for every line whose managers changed; it is recorded in the audit log. The switch response confirms local ownership changes, not completed issuer delivery. Applying the same target again changes, queues and emits nothing (applied: false). Moving to partner means new cards on the program are yours to provision and register; moving to dayzero means DayZero issues them.

Dropped settlement webhooks

For DayZero-managed cards, POST /credit/cards/reconcile-settlements ({"days": 14, "dispute_lookback_days": 30}) lists the issuer's cleared transactions per card and originates any it never received. It reads every active and suspended card, and a card terminated within the longer of days and dispute_lookback_days, since a late clearing, a void or a dispute can still arrive on what a card spent before it was terminated (a card the issuer terminated counts from the day DayZero's card sync first sees it so). The nightly sweep runs it over the last 7 days, plus the dispute look-back described under What runs on DayZero's schedule. A recorded settlement whose issuer state is no longer cleared is listed in voided_or_declined with the action taken: its loan goes on a void hold (hold_voided, on by default), reversed at once when nothing has been paid on it (voided) and otherwise left for an operator (held); send "hold_voided": false to only report it (reported). Disputes the issuer lists on a recorded transaction are applied the same way and listed in disputes; holds_placed counts both. days and dispute_lookback_days each take 1 to 120; credit_line_id limits the pass to one line; ingest_missing: false skips originating loans and only checks what is already recorded. A transaction the engine cannot take is named in errors and skipped, and the rest of the cards and transactions are still reconciled. See Disputes and voids. For partner-managed cards, re-push the settlement; ingest is idempotent on the settlement id.

Issuer spend

The card program runs on your own Ramp account, connected to your operator business under Integrations. DayZero syncs that account's card spend into the operator business's books, and a credit or credit:read token reads it back under /credit/issuer, so one key serves the credit book and the card spend; a credit:payments token is refused (403). These calls only read: nothing here changes Ramp or the books. A cardholder is a name; no email or address is returned.

GET /credit/issuer/card-transactions lists the card transactions the Ramp sync has stored, newest first, filtered by start and end (transaction dates, inclusive), card_holder (whole name, any case), card_last_four and state. amount_cents is signed: positive is spend on the card, negative a refund back to it. Each row carries the card (provider_card_id, card_last_four), the cardholder, Ramp's state, the Ramp coding (ramp_category), and, once DayZero has booked it, the account it is booked to (accounting_category, the expense side of the journal entry) and the entry (journal_entry_id); receipt_count is how many receipts Ramp had when the row was synced. When the card is registered to a credit line on this business, credit_line_id names the line, and loan_id the loan when a settlement of the transaction originated one. Reimbursements are left out unless include_reimbursements=true. Spend on a credit-line card is a loan on the line, not the operator's own expense, so the sync never stores it here: read it under the line. Rows synced before DayZero kept the card's last four and the cardholder fill them from the stored Ramp payload and from other rows on the same card; a row whose card nothing stored knows keeps a null last four.

GET /credit/issuer/cards lists the cards on the connection by cardholder: last four, name, cardholder, Ramp's status, the fund's spend limit and interval, how many stored transactions each has, and the credit line a card is registered to. source=live reads Ramp (cards, funds and the cardholders' names) and refuses with 409 CREDIT_740 when the business has no Ramp connection and 503 CREDIT_741 when Ramp does not answer within 20 seconds or the connection lacks cards:read. source=stored builds the list from stored transactions and registered cards without calling Ramp; status and limits are then unknown. source=auto, the default, reads Ramp and falls back to the stored list, with the reason in issuer_note and source saying which you got.

GET /credit/issuer/cardholders totals card spend per cardholder over start..end, highest first: transactions, net spend (charges less refunds), spend in the 30 days ending on end (today when end is not sent), the cards used, the newest transaction and the credit lines their cards are registered to. Declined and errored transactions are not spend. start after end is 400 CREDIT_742 on both dated lists.

Borrower portal

Before sharing a link with the payoff scope, configure at least one usable lender handoff in statement_branding: an HTTPS payment_url, non-empty remittance_text, valid support_email, or lender website. Link creation refuses an empty handoff. payment_url appears as Continue to [lender] to pay; payment execution stays with the lender. Invalid payment URLs, including embedded credentials and non-HTTPS schemes, are refused at program configuration. Older links with no instructions show an explicit missing-instructions message.

The portal labels the amount page Payoff quote. Statement downloads distinguish Issued PDF from Current reconciliation CSV. A requested card reactivation is not shown as issuer-confirmed availability before delivery completes.

If you would rather not build the merchant's account pages yourself, DayZero hosts them. Mint a link for a line and send it to the merchant; it opens a mobile-friendly page branded as you, showing what they owe and when, their statements, and a payoff figure. The page is read-mostly and takes no payments: it tells the merchant to pay through you, and DayZero never moves money.

curl -X POST https://api.ondayzero.com/api/v1/credit/lines/LINE_ID/portal-sessions \
  -H "Authorization: Bearer dz_your_token_here" \
  -H "x-business-id: YOUR_BUSINESS_ID" \
  -H "Content-Type: application/json" \
  -d '{"ttl_hours": 72, "scopes": ["schedule", "statements", "payoff", "autopay", "cards"]}'

The response is { "session_id", "credit_line_id", "url", "expires_at", "scopes" }. url (https://www.ondayzero.com/p/credit/<token>) holds a secret token and is returned once: DayZero keeps only its hash, so a lost link cannot be shown again; mint another. Anyone holding the URL can open the page until it expires or is revoked, so send it only to the merchant.

GET /credit/lines/{id}/portal-sessions lists a line's links, newest first, with created_by (the DayZero user id, api_token, or system), expires_at, revoked_at, last_seen_at, view_count, scopes and active; tokens are never returned. DELETE /credit/portal-sessions/{id} revokes a link at once (revoking twice is harmless). An unknown, expired or revoked link shows the same "this link isn't available" page, so a link cannot be probed for whether it ever existed.

Without scopes, a link minted by a signed-in operator or a credit token carries schedule, statements, payoff, autopay and cards, and also acknowledge while the line has a disclosure awaiting acknowledgement (only a compliance program ever has one, so on any other program a link carries exactly those five, as it always has). A link minted while nothing waits does not carry acknowledge, and a link never gains a scope after it is minted, so links minted before acknowledge existed cannot acknowledge. To send the merchant a link that can, mint one after credit.disclosure.issued tells you a disclosure is waiting (requires_acknowledgement: true), or name acknowledge in scopes. The response's scopes says what the link carries.

A credit:read token may mint and revoke links, because a merchant dashboard is what that scope is for, but a link it mints carries the read scopes only (schedule, statements, payoff, its default), never acknowledge. Asking a read-only token for autopay, cards or acknowledge returns 403 (CREDIT_070). A credit token or a signed-in operator may grant every scope.

What each page shows:

The two things a merchant can change, when the link allows it:

• AutoPay. Turning it on needs a linked repayment account (plaid_account_id or linked_account_mask on the line) and a line that carries debt: an active, pending or suspended line, or a closed one that still owes. Only a closed line with nothing left to collect refuses it. Turning it off always works. The change is the same as PATCH /credit/lines/{id} with autopay_enabled, so credit.autopay.due events follow as usual.
• Card freeze. The merchant can freeze any active DayZero-managed card on the line, whatever the line's status, and unfreeze only a card they froze themselves, while the line can spend (it is active) and is outside the collections ladder. A card you or the collections policy suspended stays suspended; the portal says so and points the merchant to you. A card's suspended_via is borrower_portal while the merchant's own freeze holds, collections while a collections stage holds it, and operator when a suspension made through the console or the API holds it. Partner-managed cards are shown but cannot be changed here.

Both are recorded in the audit trail against the actor borrower_portal, and each page view bumps the session's view_count and last_seen_at.

What a merchant can do on a line that cannot spend. The portal sorts its actions by what they do. What helps the merchant pay works on any line that carries debt, so a merchant whose line is suspended, or closed while it still owes, can still see what is owed and when, open statements, get a payoff figure and switch AutoPay on or off. What lets the merchant spend (unfreezing a card) needs a line that can spend. Freezing a card stops spending, so it works on any line, and acknowledging a disclosure is recorded on any line: on a line that is suspended or closed it records the merchant's receipt and changes nothing on the line (see Acknowledgement).

Acknowledging a disclosure is the third form on the portal, protected the same way (the link's token, the same-site cookie and the matching hidden field), and a write like the other two: it needs the acknowledge scope (403 page otherwise, and nothing changes). See Acknowledgement.

Branding comes from the program: display_name heads the page, legal_lending_entity sits under it, and statement_branding supplies the logo (logo_data_uri only; the page loads nothing from other hosts), accent_hex, footer_text, remittance_text, and support_email and website when they are set. The only DayZero mark is a one-line "Serviced by DayZero." footer. The pages carry no script, are never cached or indexed, and protect the two forms with a same-site cookie and a matching hidden field.

Codes marked (page) are shown to the merchant as a message on the portal rather than returned to your integration.

Events

GET /credit/events is the polled feed. Pass the last sequence_no as after; sequence numbers are unique and gapless per business.

For a screen that wants the latest events, send order=desc: the newest limit events come back newest first, and next_cursor is the lowest sequence_no on the page. Pass it as before to read the page of older events; the last page has has_next: false. The two directions do not mix: after with order=desc is 400 (CREDIT_562) and before with the default order=asc is 400 (CREDIT_563). Ascending, the default, is unchanged, so an integration that polls with after needs no change. GET /credit/event-deliveries takes the same order and before, so a delivery column lines up with the page beside it. Program event_delivery_mode is polling (default: outbox only), webhook, or both. Signed POSTs to the endpoints registered under Webhooks fire only in webhook and both; you switch between polling and both yourself (Turn the push on). Polling remains the source of truth after a missed delivery.

The feed notes who reads it: each ascending read made with an API token records the token's id, the after it sent and when, one record per token. The launch check events.feed_polled reads it (a program that polls fails when no token has read the feed in 24 hours). A signed-in console session, or a newest-first read (order=desc), records nothing. See Who reads the feed.