> ## Documentation Index
> Fetch the complete documentation index at: https://docs.revolv3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Network Token Fallback Flow

> How Revolv3 uses network tokens, processor tokens, and PAN as fallbacks to maximize approval rates and resilience when processing card payments.

Revolv3 stores multiple token types for each payment method and chooses the best one for each transaction. If a network token is missing or a given token fails, Revolv3 can **fall back** to another type so more payments succeed.

## Flow Overview

When you send a payment (sale, auth, or reuse of a stored payment method), Revolv3:

1. Prefers a **network token** when available (card-network tokens from Visa, Mastercard, etc.).
2. If no network token or the attempt with it fails, uses a **processor token** (e.g. WorldPay, Adyen).
3. If needed, can fall back to the **PAN** (primary account number) where the processor supports it and it is stored.

You do not choose the token in the request; Revolv3 selects it internally to optimize approval rates and resilience.

## Sequence: Token Selection and Fallback

```mermaid theme={null}
sequenceDiagram
  participant App as Your app
  participant Revolv3 as Revolv3 API
  participant Processor as Payment processor

  App->>Revolv3: Payment (paymentMethodId or raw card)
  Revolv3->>Revolv3: Resolve stored tokens (network, processor, PAN)

  alt Network token available
    Revolv3->>Processor: Attempt with network token
    Processor-->>Revolv3: Success or decline
  end

  alt Failed or no network token
    Revolv3->>Processor: Fallback: processor token or PAN
    Processor-->>Revolv3: Success or decline
  end

  Revolv3-->>App: 200 + payment details or error
```

**When fallback happens**: Revolv3 may retry with a different token on the same request (or on a retry) depending on configuration and processor behavior. The exact order and conditions are managed by Revolv3; your integration stays the same regardless of which token is used.

## Why This Matters

* **Higher approval rates**: Card networks often favor network tokens; having them and falling back when they fail keeps more transactions successful.
* **Resilience**: If one processor or token type fails, using another token or processor reduces failed payments.
* **Less work for you**: You send a `paymentMethodId` or card details once; Revolv3 handles token storage and selection.

## Enabling Network Tokenization

Network tokenization is controlled in [Merchant Settings](/docs/core-concepts/merchants/merchant-setting) (e.g. under feature toggles). When it’s enabled, Revolv3 can request and store network tokens and use them first, then fall back as above.

## Where to Go Next

* [Token FAQ](/docs/authentication-security/token-faq) — Network tokens, processor tokens, and Revolv3 payment method IDs
* [Merchant Settings](/docs/core-concepts/merchants/merchant-setting) — Enabling network tokenization and related options