Operate
Go-live checklist
A practical checklist before routing production transaction protection through TxnShield.
Required runtime setup
- Use a production environment for live traffic. Do not reuse development or staging keys in production deployments.
- Create at least one active secret key for backend evaluation and one active publishable key if the browser SDK collects continuity or human-signal context.
- Store secret keys only in server-side deployment secrets. Publishable keys may be used in client code, but should still come from the same production environment.
- Label active keys by deployment surface, owner, or service so last-used timestamps and future rotation are understandable.
- Open the Setup page, select the integration path your app uses, and confirm the framework-specific guide has been reviewed.
Protected operations and policies
- Declare the concrete protected operations that production will evaluate, such as invoice.export, customer.read_pii, bank_account.update, or payment_transaction.create.
- Keep operation keys stable and make sure the app sends operationKey values that exactly match the configured protected operations.
- Every enabled protected operation that can receive production traffic should have an active policy assigned through ProtectedOperation.policyId.
- Publish policy versions with notes, especially for threshold, challenge, redaction, deny, or role changes.
- Verify challenge type choices match implemented app behavior. Today the usable policy options are proof_token and passkey; hosted interactive challenges are not exposed yet.
Decision rehearsal
- Run at least one production-key test transaction before real users depend on the integration.
- Confirm Event Stream shows the expected operation key, actor, resource, request summary, normalized signals, and telemetryId.
- Confirm a Decision Log is created with the expected policy version, score, risk band, decision, and reasons.
- Exercise allow, step_up_required, deny, throttle, and allow_redacted paths where the assigned policies can produce them.
- For step-up, verify the app pauses the protected action, completes proof token or passkey verification, retries with challengeResult, and only then commits the action.
- For redaction, verify the app or SDK masks or drops the exact redaction.fields before returning sensitive data.
Operational controls
- Enable 2FA for owner/admin accounts that can manage production keys, policies, billing, or team roles.
- Confirm owners, admins, developers, analysts, billing_admins, and viewers have the narrowest roles that match their launch responsibilities.
- Review the current plan, trial/subscription state, production-environment entitlement, evaluated transaction limits, redaction entitlement, passkey step-up entitlement, and webhook entitlement.
- Enable alerts for usage nearing/exceeded, high-risk allows, repeated step-up failures, policy changes, first production traffic, key lifecycle, and webhook delivery failures.
- Configure webhook endpoints only after receivers validate txnshield-signature and can tolerate retry delivery.
- Confirm audit logs show recent setup activity so policy publishes, key changes, traffic mode changes, and readiness changes are attributable.
Launch switch
- Use the environment readiness panel as the source of truth for required checks: secret key, publishable key, assigned operations, telemetry, decision log, setup guide, and admin 2FA for production.
- Mark the environment production-ready only after the required checks pass and the launch owner understands remaining warnings.
- Keep traffic mode active for normal enforcement. Do not leave production in paused or bypass mode unless that is an intentional incident response decision.
- If bypass is enabled for emergency continuity, treat it as temporary because policy enforcement is not applied normally.
- Mark the environment live after production-ready status is acknowledged and deployment traffic is pointed at the production keys.
After first live traffic
- Watch Event Stream, Decision Logs, active alerts, webhook delivery attempts, usage counters, and application error rates during the first rollout window.
- Confirm production events are using production environment ids and production keys, not staging or development credentials.
- Review denied, throttled, step-up, and redacted decisions with support and security so legitimate users are not blocked unexpectedly.
- Rotate any keys that were copied into temporary launch tooling, local shells, or shared setup notes.
- Record the policy owner, operational owner, key rotation owner, and support escalation path for future changes.
Next steps