Skip to main content
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

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 (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 — Network tokens, processor tokens, and Revolv3 payment method IDs
  • Merchant Settings — Enabling network tokenization and related options