CSV Close CheckFree CSV toolExisting plans

BILLING ACCESS CHECK · EXPERIMENTAL

Your customer paid.
Can they use what they bought?

A payment can succeed while product access stays broken. See the mismatch before your customer has to explain it.

Try an example below — no signup or upload

ONE FIX. ONE HIDDEN PROBLEM.

Would these billing checks pass?

INTERACTIVE EXAMPLE

Three invented customer cases. Simulate the correct access after a plan upgrade, then see why another case still needs attention.

Keep failures visible. One passing case cannot hide a missing, stale or failing case. Export the findings for an engineer, or make your existing build reject a non-passing result.

Checks supplied payment, subscription and access observations. No Stripe account is connected and no customer access is changed. A pass does not prove a whole release is safe.

Try the free staging kit → · Node.js 24+ · developer setup required

Check your own sandbox evidence or export these results

Download the input as a template. Declare every required case ID and include its version 1 evidence. Missing cases stay visible. Maximum 20 cases, 256 KiB total. Use pseudonyms, never credentials or real customer data.

Imports default to recent evidence. Timestamps are checked against your device clock; their source is not authenticated. Replay is for historical debugging and examples.

Included in the starter kit: node billing-suite-runner.mjs suite-synthetic.json --replay. Expected exit: 1, with one mismatch and one inconclusive case. For your own fresh evidence, omit --replay. Add --junit to print XML. Only all-passing cases return exit 0; every other outcome blocks.

Get the complete kit →

Inspect a single case and its three checkpoints

TRY A FAILURE

One customer. Three checkpoints.

SYNTHETIC DEMO

Invented records, no connected Stripe account. This checks supplied observations; it does not test a protected page in your app. The example expects an active paid plan at the checkpoint. An old payment alone does not establish current paid coverage.

Example policy: active Pro and Pro access within 60 seconds of payment. Observations must be no more than 30 seconds old.

REPEAT THE CHECK

Give an engineer something reproducible.

Download the complete starter kit below, or use these individual modules with your replay input. Run the same checker locally or in your own test workflow with Node.js 24 or later.

Checker moduleLocal runner
node billing-access-runner.mjs evidence.json

Rename the downloaded replay input to evidence.json. Exit codes: 0 pass, 1 mismatch, 2 incomplete or invalid evidence, 3 still provisioning, 4 no successful payment. A pass concerns the supplied checkpoint only.

Try your own sandbox observations

Use the downloaded input as the schema. Set mode to sandbox-evidence, use pseudonymous customer references, and replace every observation and timestamp with your test data. Keep the expected plan and timing policy explicit.

Read locally in this tab. Maximum 32 KiB. Do not include keys, real customer data or raw provider payloads.

The mode is your declaration, not verified sandbox provenance. No connector, scheduler or customer account is created. Clear the page by reloading.

FROM DEMO TO YOUR RELEASE WORKFLOW

Check your staging app. Keep a failing check out of your release.

Run an explicit local request against an access-check endpoint you control. The tool combines its response with your sandbox billing evidence and returns a process exit code your build can enforce.

Developer setup required. The endpoint must use the same identity and authorization policy as your protected feature. An endpoint that echoes the expected result proves nothing about customer access.

Download complete starter kit (.zip)

Requires Node.js 24+. No packages or credentials needed for the example.

  1. Extract all files into one folder.
  2. Open a terminal in that folder.
  3. Run node billing-access-example.mjs.

Expected: broken fixture = fail, then corrected fixture = pass. Exactly two local requests, no external requests. Instructions, sample evidence and file fingerprints are included.

Individual files for manual setup
Staging probe moduleRunnable local example

These individual files need the checker and runner above in the same folder. The ZIP includes these modules and the suite runner.

Starts a temporary loopback-only fixture, makes two local GETs, shows a broken access result followed by a corrected result, then closes. Invented data; no Stripe account or external request.

Connect your own authorized staging endpoint
  1. Prepare fresh version 1 billing evidence with mode sandbox-evidence. Set access to null; the probe supplies that observation.
  2. Confirm you own or are authorized to test the endpoint, that GET has no side effects, and that it is a sandbox. Configure the dedicated environment variables below in your local shell or CI secret manager.
  3. Run the command. The output advances the checkpoint to the probe completion time, preserves the original checkpoint and evidence fingerprint, and rechecks freshness. A stale subscription observation stays inconclusive.
  4. Fail the release step on any nonzero exit code. A match is an endpoint assertion at this checkpoint; it is not independent verification of payment, a protected action or complete lifecycle coverage.
CSV_ACCESS_PROBE_SANDBOX=YES
CSV_ACCESS_PROBE_ORIGIN=https://staging.example.com
CSV_ACCESS_PROBE_TOKEN=(optional app sandbox bearer token; secret manager only)

node billing-access-runner.mjs --probe evidence.json https://staging.example.com/access-check

The lines above name environment settings; use your shell or CI system's environment editor. Never put the token in the command, URL, evidence file or chat. Do not use a Stripe key. Origin must exactly match the endpoint. HTTPS is required except literal loopback fixtures. The browser page never runs the probe.

Endpoint response contract

One GET includes a random X-CSV-Probe-Nonce. Return strict JSON like this using actual application state, with the same nonce and a fresh UTC timestamp. Return 200 for an allowed result; 200 or 403 may contain a valid denial. Authentication failure, generic error pages, redirects and unbound responses are inconclusive.

{
  "schema_version": 1,
  "environment": "sandbox",
  "nonce": "the received X-CSV-Probe-Nonce",
  "customer_ref": "pseudonymous_customer",
  "plan_ref": "pro",
  "allowed": true,
  "checked_at": "2026-09-25T12:00:00.000Z"
}

Use null for plan_ref when no plan applies. Timestamp above is illustrative: generate a current one. Response limit 8 KiB, request deadline 10 seconds, no redirects or retries. Clock skew more than five seconds into the past is rejected; future timestamps are rejected. Environment and policy correctness remain your responsibility. This optional developer probe sends its bearer token only to the exact explicitly configured endpoint; no probe traffic passes through CSV Close Check.

FOR SMALL SAAS ENGINEERING TEAMS

Would this belong in your release checks?

We are evaluating a $99/month billing-test pilot: one staging app, one supported integration, up to 30 runs a month covering signup, plan changes, failed renewal and cancellation.

That connected service is not available for purchase yet. Tell us which billing change you need to verify. We will confirm support and scope before offering a paid pilot.

Request a $99/month pilot

Opens your email app. Nonbinding, no payment, no credentials. You send the request yourself. Privacy · Support.