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 — 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 — the CSR workspace tiles these sweeps feed.
The Account Timeline — the feed the billing-events sweep populates.
Catalog Drift — nightly checks that re-sync when local and upstream diverge.
Catalog Sync History — log of catalog sync runs.
Last updated
Was this helpful?