When a fraud check times out: design the fallback

A customer submits a payout change. Your server asks Maskbreak for a visitor check, waits until its deadline, then gets no answer. The exception handler returns allow because someone wanted the integration to fail open. An infrastructure failure has just become permission to move money.

A timeout tells you that an answer did not arrive in time. It says nothing about the visitor. Design the fallback around the action your customer is attempting, and keep that missing evidence visible.

Keep unknown separate from the verdict

Record two things independently: whether the check completed, and what your application decided to do. A completed check can return allow, review, or block. A timeout, connection failure, or unusable response leaves your application without a usable verdict. Give that condition an explicit local state such as unknown; it is not an additional Maskbreak API decision.

Keep HTTP errors distinct too. A rejected credential needs an integration fix, and a rate limit needs load control. Neither is evidence of customer fraud. Validate the response shape before using its decision; a successful HTTP status alone is insufficient.

Budget the whole action

Start with the time your application can spend completing this particular action. Reserve time for its own database work and response, then give the visitor check a bounded share. Measure from your backend, including connection setup and response reading. A timeout copied from a fast development laptop is not a production budget.

MDN documents AbortSignal.timeout() as a way to abort an operation after a specified duration, with a TimeoutError reason (accessed 2026-09-06). Use cancellation supported by your runtime and HTTP client. A browser timer is not the enforcement boundary; the server must own the deadline and fallback.

Stopping your wait does not undo remote work. Also stop accepting late results into an action that has already reached its final state. Otherwise two asynchronous paths can try to complete the same customer operation.

Choose a fallback for each action

The following are starting points for your own policy, not Maskbreak defaults. Existing authentication, authorization, and abuse limits still apply.

Define who can release a hold, when it expires, and what the customer sees. A pending label needs an actual pending state behind it. If your system cannot safely hold an operation, refuse that operation temporarily and offer a clear retry path.

OWASP’s transaction authorization guidance calls for server-side enforcement and a final authorization gate tied to execution (accessed 2026-09-06). Apply that principle when releasing a held action: check current authorization and the exact operation details again. A change to the destination or amount requires a new decision about that operation.

Separate retries from business mutations

Do not wrap “check visitor, create order, charge customer” in a generic retry. Retrying that sequence can repeat an operation that already succeeded. Use your application’s durable operation identifier and concurrency controls to reconcile existing state before attempting the business mutation again. Disabling a submit button alone does not prevent duplicate processing.

AWS guidance on controlling retries recommends bounded attempts, backoff with jitter, and avoiding retries at multiple layers; it also warns about duplicated side effects (accessed 2026-09-06). Inspect any retries already performed by your HTTP client. A further attempt must fit the remaining deadline. Honor a returned Retry-After; if it exceeds that deadline, take the fallback.

A repeated Maskbreak visitor check may create another event or consume additional quota. Do not assume it has deduplication semantics. Authentication and validation failures should not enter an automatic retry loop.

Handle partial evidence without erasing it

A returned response with degraded: true differs from receiving no response. Maskbreak can mark the network layer unavailable while another signal or a customer rule still produces review or block. Preserve the returned evidence. Conversely, allow with degraded network evidence does not establish that every layer checked the visitor successfully. See the response reference.

Switching to a bare-IP lookup does not restore a live browser check. In the current production setup, bare-IP screening covers Tor exits and cloud-server ranges; VPN and proxy tunnel detection requires a live visit. A VPN by itself produces an engine decision of review, before customer overrides.

Keep secret API keys on your backend. If a fallback uses a visitor IP, derive it through your framework’s trusted-proxy configuration. Accept forwarded headers only from proxies you control and trust; never use an arbitrary client-supplied IP as authoritative.

Make fallbacks operable

If you add a circuit breaker, it belongs to your integration: it can temporarily stop new checks and select the same endpoint-specific fallback. This article does not assume Maskbreak provides one. Define how limited recovery probes reopen normal checking and who owns an extended incident.

Count eligible actions, attempted checks, unknown outcomes, degraded responses, and actual fallback actions by endpoint. Track pending age as well as pending count. Log an internal operation reference and policy version, not secret keys or raw browser tokens. Alert when missing evidence or waiting customers exceed the limits your team agreed to support.

Before releasing the timeout policy

• Force a timeout, connection failure, malformed response, and rate limit in staging.
• Confirm unknown outcomes remain distinct from returned verdicts.
• Verify sensitive mutations cannot bypass their final authorization gate.
• Test duplicate submissions and a response arriving after the deadline.
• Check degraded responses with both permissive and restrictive decisions.
• Walk through hold release, expiry, customer messaging, and incident recovery.