Challenges and sandbox testing
How step-up decisions work and how to test them in the control plane.
Challenge model
A step_up_required decision means the transaction is risky enough to require stronger proof but not risky enough to deny outright. Decision results can include challenge metadata with a type and id.
TxnShield currently supports proof_token challenge metadata and passkey/WebAuthn challenge type plumbing. Interactive hosted challenges are not exposed as a policy option yet.
Sandbox
Open an environment and choose Sandbox. You can trigger low-risk allow, medium-risk step_up_required, high-risk deny, and allow_redacted scenarios. Sandbox events use a sandbox telemetry prefix and are written as normal decision evidence.
For step-up scenarios, the sandbox creates a pending proof_token challenge event. You can mark it passed, failed, or expired to verify downstream UI and audit behavior.
SDK behavior
The Node SDK returns HTTP 409 with step_up_required and challenge metadata from the Express middleware. Applications should complete the challenge and retry with the proof token or passkey assertion so the SDK can publish the challenge result.
Next steps