CAPABILITIES

Reroute

In development

A narrower path
to a protected action.

Reroute explores scoped request paths for an existing protected browser action, while keeping application authority and request verification together.

REQUEST PATHIllustrative

Conceptual request flow

  1. Existing protected action
  2. Scoped request path
  3. Hosted admission
  4. Application outcome

Browser evidence. Application authority.

01 — THE PROBLEM

A lost response is not a failed order.A blind retry can make two.

Transport and business completion are different things. Reroute is designed so a retry is reconciled with the outcome your application already stored.

ACTION 1

Submit order – the request reaches your server

ACTION 2

Response lost – the network drops before the customer sees it

ACTION 3

Customer retries – same intent, a new request

RESULT

Two orders for one intent

VerifiedRecordedRECONCILE with the stored outcome
Reroute is designed to reconcile with an application-owned outcomewithout reconciliation

In development. Implemented locally and default-off; runtime and release validation are pending.

02 — DESIGN

Designed around separation. A scoped path changes where a request travels. It never decides whether the action is allowed; that stays with your application.

A path is not permission

The application still authenticates the account, validates the requested action and decides whether it can proceed.

Protect an existing operation

The starting point is one action that already has browser verification and clear application rules.

Keep retries consistent

A lost response should not turn a retry into a second purchase or reservation.

What is available today

Implemented locally and default-off. Not a generally available service, published SDK or customer deployment path.