Billing and licenses

Before you begin

Identify the purchaser, the workspace owner and the expected managed-device count. Agree the pilot terms before any enrollment; the published terms are still a draft.

1. Count physical managed devices, not browser profiles or people.
2. Check the current offer and payment method with RedactWall.

Supported scope and current status

The published guided pilot is free for up to 30 days and 50 managed devices; check the workspace’s recorded expiry rather than assuming whether approval or provisioning started the clock. Paid use is priced per managed device per month on /pricing. The planned self-service cart, checkout and recurring lifecycle require current release proof.

1. Use /pricing as the price and legacy pilot device-allowance authority.
2. Keep module availability, verified commercial standing and actual device enrollment as three separate readbacks.

Compare this path with the published coverage table and the coverage guide.

Set up the path

For a pilot, request and receive an approved workspace. For conversion, use the Overview request when offered and let a RedactWall employee confirm seats and terms before a bill is issued.

1. Provide a non-sensitive billing contact through the authorized channel.
2. Use an invoice by default; card is offered only where configured and currently operates in test mode.

Use the workflow

Review managed-device admission against the agreed ceiling. A seat is a managed device. A browser sensor and an endpoint agent on the same machine share one seat. Replacing a device requires its actual release and new admission. Future purchased quantity and allocation must be read separately from the legacy pilot device allowance.

1. Check the console’s commercial standing, allocation and admitted-device readbacks separately.
2. Request a seat or term change through the supported commercial path before adding devices.

Verify the result

After conversion, verify the confirmed plan and paid standing, then allocated capacity and the actual enrollment of the next authorized device. Finally verify protection on that device. A payment request, checkout redirect or visible module alone establishes none of those downstream results.

1. Compare the invoice or confirmed order with independently read commercial standing.
2. Confirm pilot expiry changed only after payment was recorded, then run a synthetic protected action on the admitted device.

See the public verification overview and the documentation coverage guide.

Denials and recovery

If a pilot expires without conversion, new enrollments stop; already enrolled devices retain their policy. An unpaid or stale order must not add capacity. Ask support to reconcile a payment or seat dispute.

1. Stop further device rollout while standing is uncertain.
2. Keep the invoice or order reference; do not send card details to support.

For customer-side next steps, read Recovery and support.

Billing and integration handoffs

Manual invoicing is the default in every deployment. Stripe Checkout is a configured test-mode option, not a universal production payment route. The marketing site itself has no payment form.

1. Ask the purchaser which payment route is available for this workspace.
2. Coordinate new seat capacity with the device administrator before deployment.

Limits to keep in view

The published per-device price and pilot bounds do not establish a currently approved live recurring offer. Administrative module availability is not paid entitlement; a purchased quantity is not an enrolled or protected device. No self-service purchase, discount or term is promised beyond /pricing.

1. Review current commercial terms with RedactWall before conversion.
2. Use independently verified workspace standing and device evidence, not this static guide, for entitlement and protection decisions.

Review the current Disclosures before relying on a capability.