---
title: "Update a business"
description: "Settings — only provided fields change."
canonical_url: "https://twominutebilling.com/help/developers/api-reference/businesses/update-a-business"
---
# Update a business

> Settings — only provided fields change.

<api-operation method="PATCH" path="/v1/businesses/{biz}">
<template v-slot:docs="">

## Path parameters

<table>
<thead>
  <tr>
    <th>
      Parameter
    </th>
    
    <th>
      Type
    </th>
    
    <th>
      Required
    </th>
    
    <th>
      Description
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        biz
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      <strong>
        yes
      </strong>
    </td>
    
    <td>
      Business id (biz_…)
    </td>
  </tr>
</tbody>
</table>

## Headers

<table>
<thead>
  <tr>
    <th>
      Parameter
    </th>
    
    <th>
      Type
    </th>
    
    <th>
      Required
    </th>
    
    <th>
      Description
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        Idempotency-Key
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Safely retry writes — repeats return the original response. If a write FAILED after it had already taken effect, that failure is what repeats: the key is spent, and a new attempt needs a new key.
    </td>
  </tr>
</tbody>
</table>

## Body

The request body is **required**.

<table>
<thead>
  <tr>
    <th>
      Field
    </th>
    
    <th>
      Type
    </th>
    
    <th>
      Required
    </th>
    
    <th>
      Description
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        name
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's name.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_currency
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's default currency (ISO-4217 code).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        currencies
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The currencies the business accepts (ISO-4217 codes).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        exchange_rates
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Manual reporting FX rates keyed by currency: 1 default_currency = rate × key. Used only to convert report roll-ups to the default currency.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        address
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's postal address.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        contact_email
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's contact email.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        support_email
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The email address customers write to for support.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        phone
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's phone number.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        website
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's website URL.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        logo_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The URL of the business's logo.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        icon_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The URL of the business's icon.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        favicon_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The URL of the business's favicon.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        brand_color
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      #RRGGBB. Accent on the hosted portal/checkout and the button fill in billing email.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        allow_customer_coupons
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a BUYER type a coupon code on the hosted checkout and the self-serve portal? Off by default. It gates the SURFACE only — a code a buyer enters is still subject to the coupon's own validity, redemption cap and item constraints.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        max_customer_coupon_codes
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How many coupon codes a buyer can enter on one checkout or one subscription in the portal. Default 1. Discounts that you apply through the dashboard or the API do not count, but at 1 the portal accepts no code while the subscription has any discount.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        timezone
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's IANA time zone, e.g. <code>
        Asia/Kolkata
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        week_start
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The first day of this business's reporting week. Analytics weekly buckets, "this week" ranges and stored weekly figures are cut on it. Changing it re-computes the stored weekly figures in the background. One of <code>
        sunday
      </code>
      
      , <code>
        monday
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        fiscal_year_start_month
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The month (1–12) this business's fiscal year starts in; 1 is the calendar year. Analytics quarters, years, <code>
        this_quarter
      </code>
      
       and <code>
        this_year
      </code>
      
       follow it, and a fiscal year is named by the calendar year it ends in (April 2026 – March 2027 is FY2027, its first quarter "Q1 FY2027"). Changing it re-computes the stored quarterly and yearly figures in the background.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        tax_registration_number
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's tax registration number.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_tax_code
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Default HSN/SAC for this business's supplies (India GST); products may override it.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_prefix
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A prefix for invoice numbers.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_next_number
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The number the next invoice gets.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_invoice_notes
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A note printed on invoices by default.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_due_days
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days from the invoice date until payment is due, by default.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        usage_close_delay_minutes
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Extra minutes before a period's usage closes, for apps that buffer events. Usage closes about 6 minutes after the period ends plus this wait, never more than 30 minutes.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_retry_days
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days after a failed charge on which to retry it.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        create_pending_invoices
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether new invoices are created in <code>
        pending
      </code>
      
       status.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        auto_close_pending_after_days
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days after which a pending invoice closes by itself.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_rounding
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How invoice totals are rounded. One of <code>
        none
      </code>
      
      , <code>
        nearest_unit
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        card_payment_limits
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Card limit per currency, in minor units, keyed by ISO-4217 code. An invoice whose amount due is above the limit for its currency is not paid by card: automatic and manual collection charge only the customer's other payment methods, and the customer portal offers no Pay now for it. With no other method the attempt fails as <code>
        card_limit_exceeded
      </code>
      
       and the invoice stays open for the customer to pay another way. An absent currency or <code>
        null
      </code>
      
       means no limit.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        credits_flexibility
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Credits Flexibility — whether refundable credits and excess payments are AUTO-applied to an invoice, configured per credit kind and per invoice class. Every slot is optional: an absent one means auto-apply with no ceiling, which is the engine default and the behaviour of every business that has never set this. <code>
        null
      </code>
      
       resets the whole setting. Promotional credit is not covered (it is applied pre-tax and is already capped at the discounted subtotal).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        credits_flexibility.refundable
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The two invoice classes, configured separately. An absent class means auto-apply with no ceiling. A recurring invoice is one raised for a subscription (renewal, proration, mid-term item add); a one-time invoice is one with no subscription behind it.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        credits_flexibility.excess
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The two invoice classes, configured separately. An absent class means auto-apply with no ceiling. A recurring invoice is one raised for a subscription (renewal, proration, mid-term item add); a one-time invoice is one with no subscription behind it.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Dunning settings for failed payments. Every member is optional — send only what you are changing; <code>
        null
      </code>
      
       resets the whole config to the engine default. Note that a partial patch REPLACES the stored config, so carry forward any member you are not changing.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.mode
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      'fixed' retries on your own day offsets and treats hardness as a single flag. 'smart' reads the gateway's decline code: transient refusals retry, refusals only the customer or you can clear hold the invoice open without retrying, and unrecoverable ones stop immediately. Default 'fixed'. One of <code>
        fixed
      </code>
      
      , <code>
        smart
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.retries
      </code>
    </td>
    
    <td>
      <code>
        array of object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Retry offsets. Offset N is counted from the Nth failure, not from the due date.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.final_action
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Applied at the end of the dunning period (or on exhaustion when no period is set).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.retries_by_method
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A retry schedule per payment method kind, in the shape of <code>
        retries
      </code>
      
      . <code>
        card
      </code>
      
       covers cards, <code>
        bank_debit
      </code>
      
       covers ACH, SEPA, Bacs, BECS, PAD, e-mandate and NACH debits (1 to 5 retries; network caps and spacing still apply on top), <code>
        offline
      </code>
      
       sets the reminder days of auto-collection-off invoices. An absent kind uses <code>
        retries
      </code>
      
      . Other methods (UPI, wallets, PayPal) use <code>
        retries
      </code>
      
      . No retry runs while a debit is still pending.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.adaptive_cadence
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The timings <code>
        adaptive_timing
      </code>
      
       uses. An absent key keeps its default.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.plan_policies
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Business-wide. A dunning policy per plan: plan id → <code>
        dpol_…
      </code>
      
      . An invoice runs its customer's policy first, then its subscription's plan policy, then the business settings. Each key must be a plan of this business and each value a live policy.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.collect_on_payment_method_update
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Charge open dues the moment a card is added. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.require_successful_charge_on_reactivation
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether a reactivation whose charge FAILS is refused, leaving the subscription cancelled. Omitted, it inherits <code>
        collect_on_payment_method_update
      </code>
      
      , which is the field it was split out of — so a business configured before the split is unaffected.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.skip_retries_for_hard_failures
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A hard decline ends dunning immediately. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.enabled
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Master switch. False → a failed charge settles to not_paid with no automatic retries. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.dunning_period_days
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days after the invoice due date at whose end the final action applies. Null (default) = no deadline; the retry schedule alone decides.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.dun_trial_and_future_subscriptions
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Dun failed activation charges on 'future' / 'in_trial' subscriptions. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.dun_one_time_invoices
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Dun invoices with no subscription behind them. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.dun_offline_invoices
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Dun auto-collect-off (send-invoice) invoices: the invoice is enrolled in dunning when it is raised (payment_due + dunning_status in_progress) and the customer is reminded on each retry offset. No charge is ever attempted, no attempt is counted, and the invoice stays payable in the portal throughout. With dunning_period_days set, the final action applies at the end of that period; without one the reminders continue and nothing is voided. Default true — send false to opt out.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.no_payment_method_at_renewal
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What a renewal does when the customer has no payment method at all (auto-collection on). follow_final_action (default) applies final_action.subscription; cancel cancels the subscription at the renewal date with reason no_card, even when the final action is retain. Card declines are unaffected. One of <code>
        follow_final_action
      </code>
      
      , <code>
        cancel
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.adaptive_timing
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Smart mode only. Times each retry by why the payment failed instead of using the retry offsets: gateway and network faults retry within hours (4h, 1 day, 3 days), insufficient funds retries on the next likely payday (the 1st, 15th or last day of the month, up to 4 times), and generic declines retry 2, 3 and 4 days apart, then the invoice parks (park_hard_declines on) or reaches the final action. Day-based retries land at 10:00 local to the card's issuing country when it is known (the business's timezone otherwise), and every retry stays within 30 days of the due date and inside dunning_period_days. Mandate debits (UPI, e-NACH, card mandates) and other decline codes keep the retry offsets. The timings are heuristics, not card-network requirements. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.minimum_amounts
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Minimum amount still owed, per currency, before dunning chases an invoice. Keys are upper-case currency codes, values are positive integers in minor units, for example {"USD": 500}. When an invoice's amount due (what is left after payments) is below the minimum for its currency, dunning does not start and dunning makes no retry or reminder for it. A currency with no entry has no minimum. Default {} (no minimum).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        dunning_config.park_hard_declines
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Smart mode, plus fixed mode's mandate and gateway-limit refusals. true parks a hard-recoverable decline (expired or invalid card, authentication required, mandate refusals, and a generic decline after 4 failed attempts): no automatic retries, reminder emails, then one last attempt and the final action at the end of the dunning period (30 days after it parks when none is set). false (default) retries those declines on the schedule like any other and applies the final action when it runs out; with no dunning_period_days, card declines keep a 30-day window. Lost, stolen and seized cards are held for a new card either way (smart mode); fraudulent charges and revoked authorisations end dunning at once. NPCI's per-rail caps shorten the retry schedule in both cases.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_prorate_on_change
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether subscription changes are prorated by default.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_invoice_immediately
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether charges are invoiced immediately by default.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        inherit_subscription_po_number
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether invoices inherit their subscription's po_number. New businesses default to true; every business that existed before this setting was introduced is false, so its printed documents did not change. An invoice's own po_number always wins.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_cancel_option
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When a cancellation takes effect by default. One of <code>
        immediately
      </code>
      
      , <code>
        end_of_term
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_credit_option_for_cancel
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How the current term's charges are credited on cancellation by default. One of <code>
        prorate
      </code>
      
      , <code>
        full
      </code>
      
      , <code>
        none
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_unbilled_on_cancel
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to unbilled charges on cancellation by default. One of <code>
        no_action
      </code>
      
      , <code>
        invoice
      </code>
      
      , <code>
        delete
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_ar_handling_on_cancel
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Business default for POST …/cancel <code>
        account_receivables_handling
      </code>
      
       when the call omits it One of <code>
        no_action
      </code>
      
      , <code>
        schedule_payment_collection
      </code>
      
      , <code>
        write_off
      </code>
      
      , <code>
        void
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_refundable_credits_on_cancel
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Business default for POST …/cancel <code>
        refundable_credits_handling
      </code>
      
       when the call omits it One of <code>
        no_action
      </code>
      
      , <code>
        schedule_refund
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        unbilled_charges_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Invoice-now vs retain-as-unbilled per lifecycle event. Absent keys resolve to the behaviour before this field existed, which is not uniform: on_change and on_one_time_charge inherit default_invoice_immediately (column default false, i.e. defer), the rest default to invoice_immediately. Cancel and resume are governed by default_unbilled_on_cancel and the resume call's own option, not here.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        unbilled_charges_config.on_create
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to charges when a subscription is created. One of <code>
        invoice_immediately
      </code>
      
      , <code>
        add_to_unbilled
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        unbilled_charges_config.on_change
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to charges when a subscription is changed. One of <code>
        invoice_immediately
      </code>
      
      , <code>
        add_to_unbilled
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        unbilled_charges_config.on_one_time_charge
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to a one-time charge. One of <code>
        invoice_immediately
      </code>
      
      , <code>
        add_to_unbilled
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Defaults the pause and resume operations fall back to when the call omits them; every default is the value that means "pass no argument". <code>
        locked
      </code>
      
       lists the keys a pause or resume request cannot override: the pause and resume operations return 400 when the request sets a locked key to a different value.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config.pause_option
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When a pause starts by default. One of <code>
        immediately
      </code>
      
      , <code>
        end_of_term
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config.unbilled_on_pause
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to unbilled charges when a subscription pauses. One of <code>
        retain
      </code>
      
      , <code>
        invoice
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config.dunning_on_pause
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether dunning continues while a subscription is paused. One of <code>
        continue
      </code>
      
      , <code>
        stop
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config.charges_on_resume
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How a resume AFTER the paid term ended bills the new term that starts at the resume (an in-term resume charges nothing). <code>
        invoice_immediately
      </code>
      
       (the default) invoices and collects it; <code>
        add_to_unbilled_charges
      </code>
      
       parks the full recurring amount for the next invoice. <code>
        next_renewal
      </code>
      
       is deprecated: accepted as an alias of <code>
        add_to_unbilled_charges
      </code>
      
      , stored and returned as that. One of <code>
        invoice_immediately
      </code>
      
      , <code>
        add_to_unbilled_charges
      </code>
      
      , <code>
        next_renewal
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config.unpaid_invoices_on_resume
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to unpaid invoices when a subscription resumes. One of <code>
        no_action
      </code>
      
      , <code>
        schedule_payment_collection
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        pause_config.locked
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The pause settings a pause or resume request cannot override. A request that sets one to a different value returns 400.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Billing rules. Keys left out keep their stored value; <code>
        null
      </code>
      
       resets every key. The business read returns the resolved value of every key. Each default is the behaviour before this field existed.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.trial_end_action
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What a trial does at its end when the plan price sets no <code>
        trial_end_action
      </code>
      
      . <code>
        activate
      </code>
      
       (default) converts and bills; <code>
        cancel
      </code>
      
       cancels with reason <code>
        trial_ended
      </code>
      
      ; <code>
        pause
      </code>
      
       pauses the subscription without billing, and a resume starts and bills the first paid term. The price's own value wins. One of <code>
        activate
      </code>
      
      , <code>
        cancel
      </code>
      
      , <code>
        pause
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.specific_date_cancel_final_period
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What a <code>
        specific_date
      </code>
      
       cancel bills for the term it ends. <code>
        full_period
      </code>
      
       keeps the term's invoice; <code>
        prorated
      </code>
      
       credits the time after the cancel date; <code>
        nothing
      </code>
      
       credits the whole term. A <code>
        credit_option_for_current_term_charges
      </code>
      
       on the call wins. Absent, it follows <code>
        default_credit_option_for_cancel
      </code>
      
      . One of <code>
        full_period
      </code>
      
      , <code>
        prorated
      </code>
      
      , <code>
        nothing
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.required_reasons
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Actions the API refuses (400) without a reason: <code>
        cancel_subscription
      </code>
      
       needs <code>
        cancel_reason_code
      </code>
      
      , <code>
        void_invoice
      </code>
      
       needs <code>
        void_reason_code
      </code>
      
      , <code>
        create_credit_note
      </code>
      
       needs <code>
        reason_code
      </code>
      
      , and <code>
        refund
      </code>
      
       needs <code>
        reason
      </code>
      
       on a payment or credit note refund. Default all false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.failed_change_charge
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When the invoice a subscription change raises and collects at once fails. <code>
        start_dunning
      </code>
      
       (default) retries it on the dunning schedule; <code>
        next_renewal
      </code>
      
       holds the first retry until the current term ends, also when the gateway reports the failure later; a change that resets the term (for example monthly to yearly) starts dunning at once. The change stays in place either way. One of <code>
        start_dunning
      </code>
      
      , <code>
        next_renewal
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.upgrade_proration
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How an upgrade bills the rest of the term for the items whose price or quantity changes. <code>
        prorated
      </code>
      
       (default) charges the new price and credits the old one for the time left; <code>
        none
      </code>
      
       changes the items and books no money for the current term (a change of billing period still charges the full new term). An item added or removed is always prorated. A <code>
        prorate
      </code>
      
       on the call wins. A longer billing period is an upgrade. One of <code>
        prorated
      </code>
      
      , <code>
        none
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.downgrade_proration
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How a downgrade bills the rest of the term: <code>
        prorated
      </code>
      
       (default) or <code>
        none
      </code>
      
      , as for <code>
        upgrade_proration
      </code>
      
      . A shorter billing period is a downgrade. One of <code>
        prorated
      </code>
      
      , <code>
        none
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.upgrade_gate
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      <code>
        invoices_paid
      </code>
      
       refuses an upgrade (409, <code>
        invoices_unpaid
      </code>
      
      ) while the customer has an unpaid invoice in this business. Applies to every plan change: the customer portal, a hosted checkout in change mode, the dashboard, the HubSpot app and the API (<code>
        …/change
      </code>
      
      , <code>
        …/schedule
      </code>
      
      , <code>
        …/items
      </code>
      
      , <code>
        DELETE …/items/{item}
      </code>
      
      , <code>
        …/update_for_items
      </code>
      
      ), when the change is made or scheduled. Default <code>
        off
      </code>
      
      . One of <code>
        off
      </code>
      
      , <code>
        invoices_paid
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.downgrade_gate
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The same gate for a downgrade. Default <code>
        off
      </code>
      
      . One of <code>
        off
      </code>
      
      , <code>
        invoices_paid
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.upgrade_timing
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When an upgrade takes effect. <code>
        now
      </code>
      
       or <code>
        end_of_term
      </code>
      
       is the only timing every source accepts; <code>
        customer_chooses
      </code>
      
       lets the portal customer, or the API caller through <code>
        timing
      </code>
      
      , pick (omitted = now). Routes that can only apply now (<code>
        …/items
      </code>
      
      , <code>
        DELETE …/items/{item}
      </code>
      
      , <code>
        …/update_for_items
      </code>
      
      , a hosted checkout, the HubSpot app) refuse a change the rule sends to the term end. In a trial every change applies now. <code>
        null
      </code>
      
       (default) = not saved: the portal applies an upgrade now, and the dashboard and the API apply it now unless the caller schedules it. One of <code>
        now
      </code>
      
      , <code>
        end_of_term
      </code>
      
      , <code>
        customer_chooses
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.downgrade_timing
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When a downgrade takes effect, as for <code>
        upgrade_timing
      </code>
      
      ; with <code>
        customer_chooses
      </code>
      
      , an omitted <code>
        timing
      </code>
      
       means the end of the term. <code>
        null
      </code>
      
       (default) = not saved: the portal applies a downgrade at the end of the term, and the dashboard and the API apply it now unless the caller schedules it. One of <code>
        now
      </code>
      
      , <code>
        end_of_term
      </code>
      
      , <code>
        customer_chooses
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.new_customer_auto_collection
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      <code>
        auto_collection
      </code>
      
       for a customer created through <code>
        POST /customers
      </code>
      
       without one. Default <code>
        on
      </code>
      
      . Customers from the hosted checkout are always <code>
        on
      </code>
      
      . One of <code>
        on
      </code>
      
      , <code>
        off
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.partial_payment_write_off
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The largest shortfall written off, per currency, when a recorded payment leaves an invoice almost paid. Keys are upper-case currency codes, values are integers in minor units from 1 to 100000, for example {"USD": 100}. The shortfall must also be at most <code>
        partial_payment_write_off_max_percent
      </code>
      
       of the invoice total. It is written off with an adjustment credit note and the invoice is paid. Credit purchase invoices are never written off. A currency with no entry writes off nothing. Default {} (off).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.partial_payment_write_off_max_percent
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The largest shortfall written off, as a percent of the invoice total. Both limits apply. Default 2.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.declined_refund
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When the gateway accepts a refund of an invoice payment and later declines or returns it. <code>
        block
      </code>
      
       (default for existing businesses) reverses the refund: the money stays with the business. <code>
        issue_credit
      </code>
      
       (default for new businesses) reopens the refund's credit note as refundable credit: it pays the customer's next invoices, and the next refund of that payment pays it out first. A refund the gateway refuses at once is not changed. One of <code>
        block
      </code>
      
      , <code>
        issue_credit
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.mandate_revoked
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When a payment fails because the payer revoked the mandate (<code>
        revocation_of_authorization
      </code>
      
       or <code>
        debit_not_authorized
      </code>
      
      ). <code>
        follow_dunning
      </code>
      
       (default) ends dunning and runs the dunning end action. <code>
        cancel_now
      </code>
      
      , <code>
        cancel_at_term_end
      </code>
      
       and <code>
        pause
      </code>
      
       end dunning and do that to the subscription; the invoice still gets the end action. <code>
        request_new_mandate
      </code>
      
       holds the invoice for a new payment method and emails the customer a payment method request. With any value other than <code>
        follow_dunning
      </code>
      
      , we never present a revoked mandate again (renewals and manual collection included) until a later success or a re-vault. One of <code>
        follow_dunning
      </code>
      
      , <code>
        cancel_now
      </code>
      
      , <code>
        cancel_at_term_end
      </code>
      
      , <code>
        pause
      </code>
      
      , <code>
        request_new_mandate
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.plan_change_term
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether a change that moves the plan's price restarts the term (credits all unused time and charges the full new term from today). <code>
        keep_anchor
      </code>
      
       (default) keeps the term; <code>
        reset_on_upgrade
      </code>
      
       resets on an upgrade; <code>
        reset_on_any_change
      </code>
      
       on every plan change. A change of billing period always resets. <code>
        reset_term
      </code>
      
       on the call wins. Applies to <code>
        …/change
      </code>
      
      , <code>
        …/estimate
      </code>
      
      , <code>
        …/update_for_items
      </code>
      
      , the customer portal, a hosted checkout in change mode and the HubSpot app; a scheduled change keeps the term. One of <code>
        keep_anchor
      </code>
      
      , <code>
        reset_on_upgrade
      </code>
      
      , <code>
        reset_on_any_change
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.plan_change_coupons
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What a change that moves the plan's price does with the subscription's coupons, before the change bills (manual discounts always stay). <code>
        keep
      </code>
      
       (default) keeps them; <code>
        drop
      </code>
      
       removes every coupon; <code>
        keep_if_valid
      </code>
      
       removes a coupon limited to specific plans that does not include the new plan. A business created in the dashboard starts on <code>
        keep_if_valid
      </code>
      
      . Estimates price the same result. One of <code>
        keep
      </code>
      
      , <code>
        drop
      </code>
      
      , <code>
        keep_if_valid
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.downgrade_credit
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Where the credit a change gives goes. <code>
        credit_balance
      </code>
      
       (default) keeps it as account credit. <code>
        refund
      </code>
      
       refunds what is left of the change's credit note to the card or bank payments that funded the customer's invoices, one payment per refund (bank-debit money goes back to the bank debit). The refund can be partial: credit that no gateway payment backs (offline or credit-settled money), and anything left after a refund that is still in progress, stays on the account. <code>
        /change
      </code>
      
       returns <code>
        credit_refunds
      </code>
      
       with <code>
        refunded_minor
      </code>
      
       and <code>
        kept_minor
      </code>
      
      . <code>
        customer_chooses
      </code>
      
       lets the customer select in the portal (<code>
        credit_handling
      </code>
      
       on the portal change); other sources keep the credit. One of <code>
        credit_balance
      </code>
      
      , <code>
        refund
      </code>
      
      , <code>
        customer_chooses
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.reactivation_charges
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How the reactivation of a cancelled subscription bills its new term when the request sends no <code>
        charges_handling
      </code>
      
      . <code>
        invoice_immediately
      </code>
      
       (default) invoices and collects it; <code>
        add_to_unbilled_charges
      </code>
      
       adds the full recurring amount to the next invoice. One of <code>
        invoice_immediately
      </code>
      
      , <code>
        add_to_unbilled_charges
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.payment_application
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How payments meet open invoices. Keys left out keep their stored value. Each default is the behaviour before this field existed.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.plan_credits
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How plan credits that renew on their own clock behave around plan changes, the first window, pauses and a cancel at period end. Keys left out keep their stored value. Each default is the recommended option.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        billing_rules_config.allowances
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How allowances that renew on their own clock behave. Keys left out keep their stored value.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_rules_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Invoice rules. Keys left out keep their stored value; <code>
        null
      </code>
      
       resets every key. The business read returns the resolved value of every key. Each default is the behaviour before this field existed.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_rules_config.small_invoice_action
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What a renewal does with an auto-collected invoice whose amount due is above zero and below <code>
        small_invoice_thresholds
      </code>
      
       for its currency. <code>
        charge
      </code>
      
       (default) charges it; <code>
        write_off
      </code>
      
       writes it off as bad debt with an adjustment credit note. One of <code>
        charge
      </code>
      
      , <code>
        write_off
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_rules_config.small_invoice_thresholds
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Per currency (ISO-4217 code), the amount due in minor units below which <code>
        write_off
      </code>
      
       applies. A PATCH replaces the whole map.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        invoice_rules_config.charge_timing
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When we charge an auto-collected renewal invoice that has net terms. <code>
        at_creation
      </code>
      
       (default) charges it when it is created; <code>
        on_due_date
      </code>
      
       charges it on its due date. An invoice with no net terms is charged at once either way. One of <code>
        at_creation
      </code>
      
      , <code>
        on_due_date
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        backdating_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How far back a subscription or invoice may be dated. Absent resolves to fully permissive, which is the behaviour before this field existed; cutoff_day_of_month null means no restriction.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        backdating_config.enabled
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether backdating limits apply.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        backdating_config.allowed_actions
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The operations that accept a past-dated instant (<code>
        reactivate
      </code>
      
       is a checkout's <code>
        reactivate_from
      </code>
      
      ). Absent resolves to all four; an explicit empty array permits none.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        backdating_config.cutoff_day_of_month
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The day of the month used as the backdating cutoff.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        backdating_config.allow_past_invoice_date_on_create
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether an invoice can be dated in the past when it is created.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        backdating_config.allow_past_invoice_date_on_change
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether an invoice can be dated in the past when a subscription changes.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When the reminder events (and their emails) are sent: per kind, a list of whole days before the date, 1 to 90, at most 5 different values (3 for <code>
        card_expiring
      </code>
      
      , <code>
        payment_due
      </code>
      
      , <code>
        pause
      </code>
      
       and <code>
        resume
      </code>
      
      ). Each (record, kind, date, lead day) is sent once, with <code>
        lead_days
      </code>
      
       on the event. A kind you leave out keeps its list; null resets every kind to the default (<code>
        trial_ending
      </code>
      
       <span>
        3
      </span>
      
      , <code>
        renewal
      </code>
      
       <span>
        5
      </span>
      
      , <code>
        renewal_yearly
      </code>
      
       <span>
        30
      </span>
      
      , <code>
        cancellation
      </code>
      
       <span>
        5
      </span>
      
      , <code>
        card_expiring
      </code>
      
       "expiry_month", <code>
        payment_due
      </code>
      
       <span>
        
      </span>
      
      , <code>
        pause
      </code>
      
       <span>
        
      </span>
      
      , <code>
        resume
      </code>
      
       <span>
        
      </span>
      
      ). <code>
        []
      </code>
      
       turns <code>
        payment_due
      </code>
      
      , <code>
        pause
      </code>
      
       or <code>
        resume
      </code>
      
       off. The business returns every kind, resolved. A lead day already passed when you change a list is not sent late. Mandate pre-debit notices are not configurable.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.trial_ending
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before a trial ends on which to send the trial ending reminder.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.renewal
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before a renewal on which to send the renewal reminder, for terms shorter than a year.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.renewal_yearly
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before a renewal on which to send the renewal reminder, for yearly or longer terms.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.cancellation
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before a scheduled cancellation on which to send the cancellation reminder.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.card_expiring
      </code>
    </td>
    
    <td>
      `string
    </td>
    
    <td>
      array of integer`
    </td>
    
    <td>
      no
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.payment_due
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before the due date of an open invoice that is not collected automatically: <code>
        invoice_payment_due_reminder
      </code>
      
      . <span>
        
      </span>
      
       (default) is off.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.pause
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before a scheduled pause: <code>
        subscription_pause_reminder
      </code>
      
      . <span>
        
      </span>
      
       (default) is off.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        reminder_config.resume
      </code>
    </td>
    
    <td>
      <code>
        array of integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Days before a scheduled resume: <code>
        subscription_resume_reminder
      </code>
      
      . <span>
        
      </span>
      
       (default) is off.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Which checkout fields show, hide, or are required. Absent keys resolve to defaults that are not uniform: billing.line1, billing.city, billing.state_code, billing.postal_code and billing.country are mandatory, everything else shows, and invoice.po_number is hidden (and still gated by storefront_config.collect_po_number). A mandatory region or postal code applies only where the country has one. billing.country cannot be hide (400). While the business has a live tax region, billing.country must stay mandatory, and while it has a GST region billing.state_code must too (400 otherwise; see <code>
        address_field_locks
      </code>
      
      ). Making billing.postal_code mandatory is also the AVS/ZIP-verification control, since AVS is checked gateway-side.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.customer.first_name
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the customer's first name. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.customer.last_name
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the customer's last name. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.customer.email
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the customer's email. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.customer.phone
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's phone number. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.customer.company
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the customer's company. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.customer.tax_registration_number
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's tax registration number. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.line1
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires address line 1. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.line2
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires address line 2. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.line3
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires address line 3. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.city
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the city. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.state
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the state name. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.state_code
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the state code. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.postal_code
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires the postal code. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.billing.country
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows or requires the country. One of <code>
        show
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.invoice.po_number
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout shows, hides or requires a purchase order number. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        checkout_field_config.shipping.address
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout collects a shipping address. hide (the default) collects none; show lets the buyer add one; mandatory requires one. The address goes into the customer's shipping address book as the default, and a new subscription ships to it. Tax still uses the billing address. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Which billing-detail fields the buyer portal shows, hides, requires, or shows read-only. Absent keys resolve to defaults: customer.first_name, customer.phone, billing.line1, billing.city, billing.state_code, billing.postal_code and billing.country are mandatory, everything else shows. A portal save keeps the stored value of every hide or read_only key; billing.state and billing.state_code are one region, kept only when both are hide or read_only. billing.country cannot be hide (400). The tax rules of checkout_field_config apply here too.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.customer.first_name
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the customer's first name. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.customer.last_name
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the customer's last name. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.customer.phone
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's phone number. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.customer.company
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the customer's company. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.customer.tax_registration_number
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business's tax registration number. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.line1
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks address line 1. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.line2
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks address line 2. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.line3
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks address line 3. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.city
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the city. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.state
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the state name. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.state_code
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the state code. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.postal_code
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, hides, requires or locks the postal code. One of <code>
        show
      </code>
      
      , <code>
        hide
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config.billing.country
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the portal shows, requires or locks the country. One of <code>
        show
      </code>
      
      , <code>
        mandatory
      </code>
      
      , <code>
        read_only
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        chargeback_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What a chargeback does to the invoice and the subscription. Absent keys resolve to record-only, which is the behaviour before this field existed. The invoice action applies to a LOST dispute only and its one value raises a DOCUMENTARY credit note (no ledger entries — the dispute's own dispute_losses posting remains the accounting treatment). A "mark invoice Not Paid" action is not offered: it would resurrect accounts_receivable with no matching ledger entry.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        chargeback_config.on_lost_invoice
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to the invoice when a dispute is lost. One of <code>
        credit_note
      </code>
      
      , <code>
        no_action
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        chargeback_config.on_initiated_subscription
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to the subscription when a dispute starts. One of <code>
        cancel_immediately
      </code>
      
      , <code>
        cancel_end_of_term
      </code>
      
      , <code>
        pause_indefinitely
      </code>
      
      , <code>
        pause_end_of_term
      </code>
      
      , <code>
        no_action
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        chargeback_config.on_lost_subscription
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What happens to the subscription when a dispute is lost. One of <code>
        cancel_immediately
      </code>
      
      , <code>
        cancel_end_of_term
      </code>
      
      , <code>
        pause_indefinitely
      </code>
      
      , <code>
        pause_end_of_term
      </code>
      
      , <code>
        no_action
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        chargeback_config.cascade_to_other_subscriptions
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the subscription action also applies to the customer's other subscriptions.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        chargeback_config.stop_collecting_all
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether to stop collecting on all the customer's invoices.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        vies_validation_enabled
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Validate customer VAT numbers against VIES. TRUE means validate — stated positively so the field reads correctly at its call sites. The switch exists because VIES is third-party and goes down.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      What the checkout and self-serve portal do. Absent keys resolve to today's behaviour. The two URLs are the fallback for the checkout mint, which requires them per call when no default is set; a call with neither is still refused.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.hide_zero_value_lines
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether lines with a zero value are hidden.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.collect_po_number
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether checkout asks for a purchase order number.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.default_return_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The URL checkout returns to after a payment, when the request has none.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.default_cancel_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The URL checkout returns to after a cancel, when the request has none.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_invoice_download
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer download an invoice PDF from the portal? Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_invoice_payment
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer pay an unpaid invoice from the portal? Default true. Turning it off removes the buyer's own payment path only — the engine still collects on its schedule and dunning still runs.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_remove_payment_method
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer remove a stored payment method? Default true. Turn it off where a live mandate depends on the instrument.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_cancel_subscription
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer cancel their own subscription from the portal? Default FALSE — the route is new, so granting it is the change.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_pause_resume
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer pause AND resume their own subscription? Default false. One key for both directions — offering pause without resume would trap a buyer. Pause uses the business's own pause defaults.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_skip_renewal
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer skip an upcoming renewal from the portal? Default false. Capped by <code>
        skip_renewal_limit
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.skip_renewal_limit
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Most renewals a buyer may skip in 12 months. Default 3. Operators are not capped.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_show_usage
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Show the buyer the usage so far on each metered subscription in the portal. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_show_usage_projection
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Also show the projected usage at the end of the billing window. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_reactivate
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      May a buyer undo a pending cancellation? Default false. Covers a subscription still active with cancel_at_period_end; an already-cancelled one is refused, because restarting it bills a new period.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.cancel_timing
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When a buyer-initiated cancellation takes effect. Default <code>
        end_of_term
      </code>
      
      . The merchant's choice, not the buyer's — it is not accepted as a request parameter. Money handling comes from the business's own cancellation defaults, so a buyer cancel settles identically to an operator cancel. One of <code>
        immediately
      </code>
      
      , <code>
        end_of_term
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_link_error_html
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Rich text the customer portal shows when a buyer cannot get in — an expired, used, revoked or unknown link, or an ended session. Allowed markup: p, br, b, strong, i, em, u, h1, h2, ul, ol, li and a (http, https or mailto); anything else is stripped on read. Null keeps the default copy.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.one_time_save_payment_method
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether a one-time purchase keeps the buyer's payment method for later purchases. <code>
        ask
      </code>
      
       (the default) lets the buyer decide. One of <code>
        never
      </code>
      
      , <code>
        always
      </code>
      
      , <code>
        ask
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.checkout_layout
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Hosted checkout layout. <code>
        one_page
      </code>
      
       shows details and payment together; <code>
        steps
      </code>
      
       shows them one after another. Default <code>
        steps
      </code>
      
      ; new businesses start with <code>
        one_page
      </code>
      
      . One of <code>
        steps
      </code>
      
      , <code>
        one_page
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.wallets_first
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Show Apple Pay and Google Pay above the form when the buyer's device and the payment gateway support them. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.recurring_consent
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The buyer must agree to the recurring charge (amount and period) before paying. Default false. The agreement is recorded.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.require_terms
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The buyer must accept the terms (and the privacy policy when set). Has no effect until terms_url is set. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.terms_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Terms of service link shown at checkout (http or https).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.privacy_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Privacy policy link shown at checkout (http or https).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.marketing_consent
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Offer an optional marketing opt-in at checkout. The answer is stored on the customer. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.bot_check_after_failures
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Ask for a bot check after this many failed payments from one IP address in 24 hours. Null (the default) turns it off.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_plan_changes
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Customers can change plan, seats and add-ons in the portal. Which plans and add-ons they see is each product's enabled_in_portal. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.seat_changes
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Seat (per-unit plan quantity) changes in the portal. Default <code>
        off
      </code>
      
      . One of <code>
        off
      </code>
      
      , <code>
        increase
      </code>
      
      , <code>
        both
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.seat_min
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The seat min.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.seat_max
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The seat max.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_addon_changes
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Customers can add or remove add-ons in the portal. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.shorter_period
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A move to a shorter billing period (yearly to monthly) in the portal. Default <code>
        always
      </code>
      
      . One of <code>
        always
      </code>
      
      , <code>
        never
      </code>
      
      , <code>
        after_12_months
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.charge_upgrade
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      When a portal upgrade is invoiced. <code>
        business_default
      </code>
      
       (the default) follows unbilled_charges_config.on_change. One of <code>
        business_default
      </code>
      
      , <code>
        now
      </code>
      
      , <code>
        next_invoice
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.change_statuses
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Subscription statuses that may change in the portal. Default active and in_trial.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.allow_cancel_scheduled_change
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Customers can withdraw a plan change scheduled for the end of the term. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.cancel_reason
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Ask for a cancel reason in the portal (the business's cancel reason codes). Default <code>
        optional
      </code>
      
      . One of <code>
        off
      </code>
      
      , <code>
        optional
      </code>
      
      , <code>
        required
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_pause
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Offer a pause before the customer cancels. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_pause_months
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Length of the offered pause in months; null = no end date. Default 3.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_pause_choice
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The customer picks 1 to retention_pause_months months. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_downgrade_price
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Offer a move to this cheaper plan price (price id) before the customer cancels. Null = no offer.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_coupon
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Offer this coupon code before the customer cancels. Null = no offer.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_contact_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Offer a link to contact you before the customer cancels. Null = no offer.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.retention_offer_once
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A customer who took an offer before is not offered one again. Default true.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_email_code
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The signed-out portal lets a customer sign in with a code sent to their email. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_link_hours
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How long a portal link minted through the API can be opened, in hours. Null = 1 hour.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_email_link_days
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How long a portal link in an email can be opened, in days. Null = 5 days.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_session_hours
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How long a customer stays signed in to the portal, in hours. Null = 72 hours.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_hide_cancelled_subscriptions
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The portal does not list cancelled subscriptions. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_hide_zero_invoices
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The portal does not list invoices with a zero total. An invoice with an amount due always shows. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_hide_voided_invoices
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The portal does not list voided invoices. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_actions
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Which tasks a portal link may open on. Each defaults to true; false makes such a link open the portal home.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        storefront_config.portal_return_url
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      https only. Where the portal's back link goes. Null = default_return_url. A portal link's own redirect_url wins.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_tax_behavior
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Default price type new prices inherit One of <code>
        exclusive
      </code>
      
      , <code>
        inclusive
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        tax_behavior_by_currency
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Price type per currency, as <code>
        {"INR": "inclusive"}
      </code>
      
      . A new price created without <code>
        tax_behavior
      </code>
      
       takes its currency's value. Sent whole; null removes every value.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        seller_tax_ids
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Your tax registration per destination country, keyed by ISO 3166-1 code (GB, not UK; GR, not EL), as <code>
        {"DE": "DE123456789"}
      </code>
      
      . An invoice to a customer in that country prints it in place of the business tax ID. Sent whole; null removes every value.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        tax_rounding
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      <code>
        per_invoice_total
      </code>
      
       (default) rounds each tax once on the invoice total. <code>
        per_line
      </code>
      
       rounds the tax on each line and adds the lines. One of <code>
        per_invoice_total
      </code>
      
      , <code>
        per_line
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        anchor_granularity
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Where a term starts: the exact creation instant, or floored to start-of-day in the business timezone (day-anchored businesses also report term ends inclusively, …T23:59:59) One of <code>
        instant
      </code>
      
      , <code>
        day
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        proration_granularity
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      How mid-term credits/charges are measured: by elapsed time, or by whole billing days. Legal pairs are instant+exact (millisecond-based), instant+whole_day (day-based) and day+whole_day (day-based with midnight-aligned terms) One of <code>
        exact
      </code>
      
      , <code>
        whole_day
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Customer-facing billing emails; null disables all sending
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.enabled
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Whether the business sends billing emails.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.fromName
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The From name on billing emails.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.fromAddress
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Envelope From; null uses the deployment default.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.replyTo
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Null sends NO Reply-To header, so replies go to the From address. There is no fallback to the business support email.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.cc
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Copied on every send and VISIBLE to the customer. Max 10.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.bcc
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Copied on every send and hidden from the customer — the usual place for an internal archive box. Max 10.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.subjectPrefix
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Prepended to every rendered subject, e.g. "<span>
        Fernhill
      </span>
      
      ". Applied at send time, so email_messages.subject keeps the unprefixed rendered subject.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.footerNote
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The business footer: ends every email that has no footer of its own. Template syntax, limited to the variables every email has (businessName, customerName, portalUrl). Null uses the built-in footer.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.attachments
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Per-email attachment rules, keyed by email type. Only types about a document take effect: invoice_issued, invoice_overdue, invoice_sent, payment_receipt, payment_failed, payment_authentication_required (the invoice PDF) and credit_note_issued, credit_note_applied, credit_note_sent (the credit note PDF). An absent type attaches the PDF and skips nothing. <code>
        skipZeroPdf
      </code>
      
       applies to invoice_issued and invoice_sent only; <code>
        skipZeroSend
      </code>
      
       to invoice_issued only. The PDF is rendered when the email is sent.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.types
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Per-email-type override; absent type inherits <code>
        enabled
      </code>
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.attachReceiptPdf
      </code>
    </td>
    
    <td>
      <code>
        boolean
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Attach the numbered receipt PDF to the payment confirmation email. Default false.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.linkTarget
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Where the links and the button in billing emails go. <code>
        portal
      </code>
      
       (default): a signed-in link to the hosted billing portal. <code>
        merchant_url
      </code>
      
      : <code>
        merchantUrl
      </code>
      
      , as it is, with no portal session. One of <code>
        portal
      </code>
      
      , <code>
        merchant_url
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        email_config.merchantUrl
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      An http(s) URL. Required when <code>
        linkTarget
      </code>
      
       is <code>
        merchant_url
      </code>
      
      . Kept when you change the target back to <code>
        portal
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Mail to your own team: overdue high-value invoices, failed webhooks and a daily summary. Replaces the stored value. <code>
        null
      </code>
      
       turns every alert off.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config.recipients
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      <strong>
        yes
      </strong>
    </td>
    
    <td>
      Who gets the alerts. Max 10. Required when an alert is enabled. An address that is not a team member gets a confirmation email and no alert until it is confirmed.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config.overdue
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      An alert when an unpaid invoice passes its due date and the amount due is at or above the limit for its currency. Checked every hour. An invoice in a currency with no limit gets no alert.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config.webhook_failures
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      An hourly alert that lists the webhook endpoints with deliveries we stopped trying to send in the last hour.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config.daily_digest
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A summary at 08:00 business time of the day before: payments collected, payments that failed, invoices in dunning and cards that expire this month or next month.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config.large_grants
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      An alert at the time someone gives free credit above <code>
        credit_config.grant_limits.<currency>.alert_above_minor
      </code>
      
      : a wallet top-up of type <code>
        granted
      </code>
      
      , promotional credit or a promotional credit grant.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        credit_note_prefix
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      A prefix for credit note numbers.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        credit_note_next_number
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The number the next credit note gets.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        receipt_prefix
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      The prefix of receipt numbers. Default RCPT.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        expected_version
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      no
    </td>
    
    <td>
      Optimistic concurrency: current resource_version; 409 on mismatch
    </td>
  </tr>
</tbody>
</table>

## Response

<table>
<thead>
  <tr>
    <th>
      Field
    </th>
    
    <th>
      Type
    </th>
    
    <th>
      Description
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        usage_close_delay_minutes
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      Extra minutes before a period's usage closes, for apps that buffer events. Usage closes about 6 minutes after the period ends plus this wait, never more than 30 minutes.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      The object type.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        id
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      The business's id (biz_…).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        name
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      The business's name.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        livemode
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      <code>
        live
      </code>
      
       for a live business, <code>
        test
      </code>
      
       for a test business. One of <code>
        live
      </code>
      
      , <code>
        test
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        live_business_id
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      On a test business: the id of its live mode. Null on a live business.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        test_business_id
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      On a live business: the id of its test mode. Null until test mode is first opened for a business created before test modes existed — POST /v1/businesses/{biz}/test_mode creates it.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        default_currency
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      The business's default currency (ISO-4217 code).
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        currencies
      </code>
    </td>
    
    <td>
      <code>
        array of string
      </code>
    </td>
    
    <td>
      Currencies this business transacts in; null = unrestricted.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        exchange_rates
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      The raw rate map: 1 default_currency = rate × key currency. Kept as numbers for the consumers that already read it; <code>
        currency_rates
      </code>
      
       below is the same rates with their provenance and is the one to prefer.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        currency_rates
      </code>
    </td>
    
    <td>
      <code>
        array of object
      </code>
    </td>
    
    <td>
      Per-currency rate + provenance (one row per configured currency, excluding the business's own default, which is 1 by definition). This is what a currency-settings screen needs: whether the rate is maintained by hand or refreshed from a provider, when the rate being held was PUBLISHED, and why the last refresh failed if it did.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        week_start
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      First day of the reporting week. Default <code>
        sunday
      </code>
      
      . One of <code>
        sunday
      </code>
      
      , <code>
        monday
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        fiscal_year_start_month
      </code>
    </td>
    
    <td>
      <code>
        integer
      </code>
    </td>
    
    <td>
      Month (1–12) the fiscal year starts in; default 1 (the calendar year). Fiscal years are named by the year they end in.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        status
      </code>
    </td>
    
    <td>
      <code>
        string
      </code>
    </td>
    
    <td>
      The business's status.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        portal_field_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      The buyer portal's field matrix, resolved: every key present, tax-locked keys already mandatory.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        address_field_locks
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      Address keys the business's live tax setup forces to mandatory on checkout and portal. The settings refuse any other state for them.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        team_alerts_config
      </code>
    </td>
    
    <td>
      <code>
        object
      </code>
    </td>
    
    <td>
      Team alerts. Each alert sends only when it is enabled and <code>
        recipients
      </code>
      
       has at least one address. Mail comes from the platform sender, not from the business mail settings.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        created_at
      </code>
    </td>
    
    <td>
      <code>
        string · ISO-8601
      </code>
    </td>
    
    <td>
      When the business was created (ISO-8601 UTC).
    </td>
  </tr>
</tbody>
</table>

## Status codes

<table>
<thead>
  <tr>
    <th>
      Status
    </th>
    
    <th>
      Meaning
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        200
      </code>
    </td>
    
    <td>
      Success
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        400
      </code>
    </td>
    
    <td>
      Invalid request body
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        404
      </code>
    </td>
    
    <td>
      No such business
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        409
      </code>
    </td>
    
    <td>
      resource_version mismatch
    </td>
  </tr>
</tbody>
</table>
</template>

<template v-slot:request="">

```bash [Request]
curl -X PATCH "$TMBILLING_URL/v1/businesses/biz_XXXXXXXXXXXX01" \
  -H "Authorization: Bearer $TMBILLING_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Brightwater Analytics"
  }'
```

</template>

<template v-slot:response="">
<code-group>

```json [200 OK]
{
  "usage_close_delay_minutes": 1,
  "object": "business",
  "id": "biz_XXXXXXXXXXXX01",
  "name": "Brightwater Analytics",
  "livemode": "live",
  "live_business_id": "biz_XXXXXXXXXXXX01",
  "test_business_id": "biz_XXXXXXXXXXXX01",
  "default_currency": "USD",
  "currencies": [
    "USD"
  ],
  "exchange_rates": {
    "EUR": 0.92
  },
  "currency_rates": [
    {
      "object": "currency_rate",
      "currency": "INR",
      "rate": "0.920000",
      "source": "manual",
      "updated_at": "2026-03-14T09:30:00Z",
      "provider": "ecb"
    }
  ],
  "week_start": "sunday",
  "fiscal_year_start_month": 1,
  "status": "active",
  "portal_field_config": {},
  "address_field_locks": {
    "country": false,
    "state_code": false
  },
  "team_alerts_config": {
    "recipients": [
      "maya@example.com"
    ],
    "overdue": {
      "enabled": false,
      "thresholds": {}
    },
    "webhook_failures": {
      "enabled": false
    },
    "daily_digest": {
      "enabled": false
    },
    "large_grants": {
      "enabled": false
    }
  },
  "created_at": "2026-03-14T09:30:00Z"
}
```

```json [400 Bad Request]
{
  "error": {
    "type": "invalid_request_error",
    "message": "Invalid request body"
  }
}
```

```json [404 Not Found]
{
  "error": {
    "type": "invalid_request_error",
    "message": "No such business"
  }
}
```

```json [409 Conflict]
{
  "error": {
    "type": "conflict_error",
    "message": "resource_version mismatch"
  }
}
```

</code-group>
</template>
</api-operation>


## Sitemap

See the full [sitemap](https://twominutebilling.com/sitemap.md) for all pages.