> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/settings/billing-catalog/billing-integration-cache.md). # Billing Integration Cache **Settings → Billing Integration Cache** shows the data PeakCommerce caches from your billing provider so the storefront, journeys, and admin screens stay fast and resilient even when the upstream provider — whether Zuora, Stripe, or Metronome — is slow or briefly unreachable. Rather than calling the provider on every plan lookup or price resolve, PeakCommerce serves catalog and pricing data from this cache and refreshes it in the background. The console has two tabs: **Overview**, the read-heavy health view of the cache itself, and **Scheduled sweeps**, where you manage the background jobs that keep account data warm without spending live billing-provider calls. ## Why it matters Every product, plan, and charge a buyer sees is resolved through this cache. A healthy cache means low latency and no hard dependency on the provider being up at checkout time. A degraded cache (slow resolves, rising failures) is an early warning that something upstream is off. The sweeps, meanwhile, are what feed the CSR workspace's nightly signals — the "No usage reported" and "Trials ending soon" tiles in [Finding Accounts](/product/customer-success-portal/finding-accounts.md) — and the billing events (invoices, payments, failed payments) on the CSR account Timeline. ## The Overview tab Auto-refreshing cache metrics (the page re-polls every 30 seconds — no manual refresh needed): * **Hit ratio and cache size** — how often resolves are served from cache versus going upstream, and how many account entries are currently cached. * **Resolve latency** — average time to resolve, split by cache hit versus miss. * **Slowest integrations** — per-integration probe latency, sample counts, and probe-error rate, to pinpoint which provider connection is degraded. Rows currently breaching a threshold carry an **Alert** badge. * **Integration alerts and thresholds** — configurable thresholds (average latency, failure rate, minimum samples, rolling window) that fire an alert when an integration crosses them. The threshold fields are edited here but saved from the page-level save bar, alongside any sweep edits. ## The Scheduled sweeps tab All background jobs appear in **one table** — one row per sweep, each showing its status switch, schedule, per-run call cap, last run, and estimated calls per day: * **Account metrics refresh** — refreshes the snapshot rows behind the CSR account list's sort and filter. It refreshes local data only, so it spends **no** billing-provider calls. * **No-usage signal sweep** — scans subscriptions for reported usage so the CSR "No usage reported" tile can flag idle accounts. * **Trial signal sweep** — scans for pending paid charges so the CSR "Trials ending soon" tile can flag trials about to convert. * **Account timeline billing-events sweep** — syncs each account's invoices and payments (including failed payments) into the local cache so the CSR account Timeline shows billing history at zero live-call cost. Working the table: * The **status switch** on each row enables or disables that sweep (the change is staged until you save). * The row's **⋯ menu** offers **Configure** (expands the row's editor inline — several rows can be open at once), **Run now**, and **Disable sweep**. * **Run now** starts the sweep **in the background** and returns immediately — you can leave the page; the result is there when you come back. It works whether or not the daily schedule is switched on. ### The scheduled call ceiling The strip above the table shows the **maximum daily calls to your billing provider** that the currently **enabled** sweeps can make, with a composition bar showing how the ceiling splits across sweeps. This is a **ceiling, not an estimate**: a sweep with a per-run cap of *N* running once a day can spend at most *N* calls, whatever it actually finds to do. A sweep configured without a cap has no ceiling at all — it's called out separately as *uncapped* rather than folded into a misleading number. Check this readout before enabling a sweep: today's sweeps spend against a Zuora API budget shared with everything else your tenant does, which is why they all default **off**. ## Saving changes One **save bar** docks to the top of the page and covers **every** edit — alert thresholds and all sweep configurations, across both tabs. It lists exactly which sections have unsaved changes, and on save it reports **per section** what saved and what didn't: a partial failure never reads as a blanket "Saved". Failed sections stay marked dirty so you know precisely what to retry. **Discard** resets everything staged. ## Gotchas * Disabling a sweep keeps its configuration and run history — it's paused, not reset. * A sweep refresh keeps cached data warm, but a full catalog reconciliation (adding or deactivating products) flows through catalog sync — see the pages below if products look stale. * The signal and timeline sweeps currently apply to Zuora-backed billing integrations. ## Related * [Finding Accounts](/product/customer-success-portal/finding-accounts.md) — the CSR workspace tiles these sweeps feed. * [The Account Timeline](/product/customer-success-portal/account-timeline.md) — the feed the billing-events sweep populates. * [Catalog Drift](/product/settings/billing-catalog/catalog-drift.md) — nightly checks that re-sync when local and upstream diverge. * [Catalog Sync History](/product/settings/billing-catalog/catalog-sync-history.md) — log of catalog sync runs. * [Products overview](/product/using-peakcommerce/products-and-bundles/products-overview.md) * [Zuora billing integration](https://gitlab.com/peak-hercules/peak-help-docs/-/tree/main/integrations/zuora-integration/zuora-billing-integration.md) * [Stripe integration](https://gitlab.com/peak-hercules/peak-help-docs/-/tree/main/integrations/stripe/stripe-payments.md) * [Metronome integration](https://gitlab.com/peak-hercules/peak-help-docs/-/tree/main/integrations/metronome/metronome-usage-based-billing.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/product/settings/billing-catalog/billing-integration-cache.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.