Authenticated activity and prompt integration

Observe product use independently

Install the separate activity script with the same site key and same-origin server session endpoint as your banner. Call it after a meaningful authenticated product action. A login uses a separate kind and is never counted as observed product usage. Do not trigger product activity from a banner view, billing page, heartbeat, background tab or failed authentication.

<script defer src="https://YOUR_RESCUE_ORIGIN/snippets/activity.js"
  data-site-key="YOUR_SITE_KEY" data-session-url="/api/rescue-session"></script>

// After a meaningful, successfully authenticated product action:
await window.RescueDunningActivity?.observe("authenticated_activity", crypto.randomUUID());
// Separately, after login succeeds:
await window.RescueDunningActivity?.observe("login", crypto.randomUUID());

The optional opaque event ID is 16–80 letters, digits, underscores or hyphens. Reuse the same ID for retries of one event; never use a user identifier or meaningful text. If omitted, the script creates a random ID. The endpoint accepts exactly {eventId, kind}; all identity is bound server-side. It stores only last-use and last-login timestamps and hashed IDs needed for seven-day deduplication. No URL, page content, IP, device, token or arbitrary properties are stored by this feature.

The report uses a fixed trailing 168-hour UTC window and only matching, fresh checked outstanding amounts. Currency totals remain separate. No observation means missing coverage, not inactivity. Expired data is excluded immediately; scheduled maintenance physically deletes it. Opt-out creates a new collection generation: earlier observations and already-authenticated ingestion requests stay invalid after re-enabling, and delayed cleanup preserves only fresh observations from the new opt-in. A Stripe customer marked deleted cannot submit activity or remain in the report; a customer with no email can still be observed. Supply the required user notice before opting in.

Prompts and billing roles

Your server must sign billingAuthority: true only for an account owner or billing administrator authorized to see and pay this customer's invoices. Missing or false authority produces only a generic contact-admin notice. Every payment click fetches a fresh session and rechecks the invoice in Stripe. Sessions expire in at most five minutes.

Escalation is disabled by default and does not enable the banner. Configured stages use server-recorded failure time. Paid, void, uncollectible and ended-subscription cases disappear; unknown or incomplete billing cannot open a modal. Treatment controls are suppressed before any billing details are returned. An invoice page request and a prompt delivery are availability observations, not views, payments or product use.

All prompts have visible dismissal and Escape handling. Modal and softwall prompts retain focus within their own dialog and restore the previous focus after dismissal. The softwall is a wider, emphasized billing review with Continue above the invoice details. The host page is never made inert, hidden or permission-restricted.

Every presentation declares enforcement: "advisory_only". This integration displays reminders; it does not implement host entitlement enforcement or an access-denial API. Keep existing product permissions unchanged. Do not convert a prompt mode, failed or stale request, expired session, or holdout suppression into a product lock. Unknown payment status must leave access available, and dismissal, support, billing, export, cancellation and account recovery remain reachable.

Protected access and session changes

Billing, support, emergency, logout, cancellation, account recovery and data export paths are protected. Add your custom route equivalents in prompt settings. Mark sensitive screens and client-side routes explicitly with RescueDunning.setProtected(true); set false after leaving them. A protected screen removes the prompt immediately and has no overlay. No path is sent to RescueDunning.

// Before logout, account/customer switch or changing membership:
window.RescueDunning?.clear();
window.RescueDunningActivity?.clear();
// Change the authenticated server session; only then:
window.RescueDunning?.refresh();

// Before rendering protected/sensitive SPA screens:
window.RescueDunning?.setProtected(true);
// After leaving that protected screen:
window.RescueDunning?.setProtected(false);

Clear before changing customer context so delayed requests cannot render or navigate for the previous customer. The session endpoint must check current authentication on every call, use no-store caching, return 401 after logout, and never redirect. Dismissals exist only in memory for the current signed session; no customer or invoice state is written to browser storage. Remove both scripts with their destroy() methods when unloading the integration.