Network tokens

Network tokenization is a process where card networks replace a consumer's Primary Account Number (PAN) with a unique digital identifier called a network token. When a consumer registers their card on a device, or saves it during checkout on your website, the card network automatically generates a network token in real-time. This token is used for transactions instead of the actual card number.

What are network tokens?

Network tokens are domain-restricted, meaning they can only be used by a specific business, device, or payment channel. Even if a token is intercepted, it cannot be used elsewhere because only the card network and card issuers can unlock it. The underlying account information remains protected. Network tokens are also dynamically updated when the underlying card details change, such as expiration or reissuance. This means you can continue using the same token without disruption, reducing failed transactions caused by expired or replaced cards. Because network tokens are used instead of actual card numbers, card exposure during payment processing is reduced, which significantly minimizes fraud risk and unauthorized transactions.

Consumer's card details will be replaced securely with payment tokens. Cardholder authentication works in the same way for card payments. This provides an additional authentication layer for online transactions.

Where are network tokens used?

• Card-on-File transactions: When you store consumer payment details for future transactions, network tokens eliminate the risk of storing sensitive card data. Unlike traditional card-on-file storage, tokens improve authorization rates and reduce fraud-related chargebacks.
• Subscription and recurring payments: When you offer subscription-based services (e.g., streaming platforms, SaaS providers), network tokens ensure uninterrupted payments. Since tokens automatically update when the underlying card changes (e.g., expiration, reissuance), they prevent transaction failures and reduce consumer churn.
• Digital wallets & mobile payments: Digital wallets like Apple Pay, Google Pay, and Samsung Pay use network tokens to securely store and process payments. Transactions are authorized only within the designated wallet and device, preventing use outside the intended environment.

• One-Click checkout: You can use network tokens to enable fast checkout experiences. With tokenized credentials, consumers can complete purchases without repeatedly entering card details, reducing friction in the checkout process.

Key benefits of network tokens

Network tokens provide a multitude of advantages for payment processing:

Higher authorization rates: The issuer is responsible for keeping card data current and becomes part of the risk assessment when the token is created. This increases issuer confidence and eliminates declines due to expired credentials. 

Reduced fraud risk: Network tokens replace sensitive card data with unique, domain-restricted tokens that can only be used with a specific business, device, or payment channel. Even if intercepted, a token cannot be used elsewhere. In addition, each tokenized transaction includes a unique cryptogram, which is a one-time cryptographic value that helps verify the authenticity of the transaction and the token being used. This makes it significantly more difficult for fraudsters to reuse stolen payment credentials. As a result, network tokens can reduce fraud-related declines and chargebacks, lowering fraud costs for both you and payment providers.

Improved consumer experience: When a consumer's card expires, is lost, stolen, or replaced, the card network can automatically update the underlying card information associated with the network token. This allows you to continue processing recurring payments and subscriptions without requiring consumers to update their payment details, reducing payment interruptions and providing a smoother checkout experience.

Lower compliance burden: By eliminating the need to store actual card details, you reduce your PCI DSS compliance burden and associated data breach risks.

What we offer

When you already use our tokenization service, your tokens are dynamically linked to network tokens at the time of transaction. When you use a stored token in your payment request, we exchange it with a network token at the time of transaction. This happens automatically in the background, with no changes required on your side. By combining stored credentials with network tokenization, you benefit from a more secure and efficient payment setup. Sensitive card data is further removed from your systems, reducing your PCI scope, while network-level optimization helps improve authorization rates. This approach allows you to enhance both security and performance without adding complexity to your integration. 

Here's how it works: 
We manage the onboarding process with card networks on your behalf. Once a provisioning request is made, network tokens become available within 2–3 seconds. For the initial transaction, we process the payment using the PAN, while tokenization occurs asynchronously. Network tokens are then available for all subsequent transactions.

Self-managed network tokens

You can also submit network tokens provisioned outside of our platform in your payment requests. These are the tokens provisioned and managed by you, your orchestration platforms, or your subscription partners.

Network tokens are not considered sensitive data, because they contain no personally identifiable information or financial data (no card numbers, expiration dates, or CVV codes). They're unique identifiers that represent the original payment card securely. This allows you to collect and store network tokens with greater flexibility and control over payment routing. 

When you submit an external network token, include token PAN, token expiry date and token cryptogram. We process the payment request and forward it to the appropriate financial institutions for authorization and settlement. We do not validate the correctness of the token details you submit.  No configuration is needed in your merchant account.

Pricing and costs

Network tokenization is enabled for your account at no additional cost. Authorization rates typically improve with network tokens, which can positively impact your transaction approval rates and revenue.

Network tokens and Worldline tokens

Network tokens and Worldline tokens are two distinct token types used in digital payments. Each token type has different capabilities and lifecycle management requirements.

Network tokens

Network tokens are issued by card networks and replace a cardholder's Primary Account Number (PAN). A network token is dynamically linked to the actual card but restricted to a specific merchant domain It cannot be used outside its intended context. Network tokens are interoperable across the entire payment ecosystem.

When the underlying card expires, is reissued, or is lost or stolen, the issuer automatically updates the associated token. You can continue using the same token without requesting updated information from consumers or performing manual updates.

Worldline tokens

Worldline tokens are payment tokens created and managed by Worldline. When card details are tokenized, the original card information is securely stored within Worldline's systems and replaced with a unique token that can be used for future transactions.

Using a Worldline token means you do not need to store sensitive card data in your own systems. Instead, you store the token and use it to process future payments through Worldline. Worldline Tokens are specific to the Worldline platform and can only be used to process payments through Worldline.

Unlike network tokens, they are not issued by the card networks and do not automatically receive card lifecycle updates from the card issuers unless you opt in Account Updater services.  If a consumer's card is replaced or expires, a new token or updated payment details may be required. 

Operational differences

Both network tokens and Worldline tokens replace sensitive card details with a secure token for future payments. The key difference is who creates and manages the token. Network tokens are issued by the card networks and represent a network-managed payment credential. Worldline tokens are issued and managed by Worldline and are used to securely reference card details stored within the Worldline platform.

When a card is renewed or replaced, both token types can benefit from card information updates. Network tokens receive lifecycle updates as part of the network tokenization service. Worldline tokens can be kept up to date through Account Updater, which uses the card networks' account update services to retrieve updated card information when available.

How do network tokens work?

After a consumer completes their first successful payment on your website, we replace their card number with a unique identifier called a network token. On subsequent purchases, when the consumer returns to your site, the network token is submitted instead of their actual card details. This means the sensitive payment credentials are not transmitted or stored with each transaction.

The below flow shows the process of creating a network token:

Each time a consumer initiates a transaction using a saved card, the card scheme generates a unique cryptogram specific to that transaction. This cryptogram is tied to the specific token, merchant, and transaction context. The cryptogram remains valid until it is used.

Get network token data

When network tokenization is used, additional data can be returned in your payment responses to give you more visibility and control over your transactions. These data points give you deeper insight into how your payments perform and how your customers transact. By leveraging network token data, you can improve reporting, optimize payment performance, and gain a more complete view of your customers while maintaining a secure and compliant payment environment.

• networkToken: It is a secure alternative to the full card number (PAN). It represents the consumer’s card in a tokenized format and is used for processing transactions without exposing sensitive card data. By default, the token may be obfuscated. If you require access to the full (non-obfuscated) network token, please contact your account manager.
• tokenExpiryDate: The expiry date of the network token, indicates the validity of the network token.
• tokenReferenceId: A unique identifier associated with the network token. It can be used with services such as Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) to retrieve additional token details. The reference remains valid for as long as the token is active. Note: A prefix "V:" is added to show that this is a network token for a Visa product and "M:" to show that this is a network token for a Mastercard product.
• networkTokenUsed: Shows if a network token was used during the payment. This enables you to monitor adoption of network tokenization, to compare performance between tokenized and non-tokenized transactions and to measure improvements in approval rates.
• paymentAccountReference: A unique reference to the primary account number. Payment Account Reference provides a consolidated view of transactions associated with a PAN and its affiliated tokens, making it easier to identify customers and their associated transactions across payment channels.

Maximizing authorization success

By refreshing the dynamic security verification for every individual attempt, we minimize unnecessary rejections and maximize the number of successful payments for your business. For every authorization request, including retries across different banks, we generate a new, unique, and time-sensitive security code. This ensures that even if a previous attempt was declined, the bank receives a new, distinct verification for the retry.

Sharing tokens across your accounts

If you operate on multiple websites or apps, network tokenization allows you to create a unified payment experience across all of them.

When a consumer saves their card on one of your platforms, that same token can be recognized and reused across your other accounts. This makes repeat purchases faster and more convenient no matter where they interact with your brand. This provides a consistent checkout experience across all channels, higher conversion and repeat purchase rates.

To enable network token sharing across your accounts, enabled merchant accounts (Contact IDs) should be part of the same merchant group. 

Boarding

To prepare for network token enablement and go through a full boarding process, contact your Account Manager.

Integration

You have two options when it comes to processing network token payments. You can either use our tokens, or directly initiate payments on our platform and use your own tokenization provider. Both options are available to you, so you can choose the one that best suits your needs.

Using tokens

If you're looking for the quickest way to process payments with network tokens, tokenization is the optimal solution for an easy implementation. You can submit your payment using MyCheckout hosted payment pages or Create Payment endpoint depending on your current implementation with us.

Submit the payment as you do today for card payments, including the Card On File or Recurring objects. 

Using Mycheckout hosted payment pages

1. Make a POST /v1/{merchantId}/hostedcheckouts API call.
2. Additionally add the unscheduledCardOnFileRequestor and unscheduledCardOnFileSequenceIndicator or recurring properties. The unscheduledCardOnFileRequestor indicates which party initiated the unscheduled recurring transaction. Allowed properties are the following:
   • merchantInitiated - merchant initiated transaction.
   • cardholderInitiated - cardholder initiated transaction.

• unscheduledCardOnFileSequenceIndicator:
  • first transaction = this transaction is the first of a series of unscheduled recurring transactions.
  • subsequent transaction = this transaction is a subsequent transaction in a series of unscheduled recurring transactions

• recurringPaymentSequenceIndicator:
  • first = This transaction is the first of a series of recurring transactions
  • recurring = This transaction is a subsequent transaction in a series of recurring transactions for payments that are processed by the WL Online Payment Acceptance platform

Below, you'll find an example request containing the essential data. For more information, please refer to our API Reference.

{
  "cardPaymentMethodSpecificInput": {
    "unscheduledCardOnFileRequestor": "cardholderInitiated",
    "unscheduledCardOnFileSequenceIndicator": "first",
    "card": {
      "cvv": "123",
      "cardNumber": "5186151650005081",
      "expiryDate": "1230",
      "cardholderName": "John Doe"
    },
    "tokenize": true,
    "paymentProductId": 3,
    "transactionChannel": "ECOMMERCE",
    "threeDSecure": {
      "skipAuthentication": true,
      "redirectionData": {
        "returnUrl": "https://hostname.myownwebsite.url"
      }
    }
  },
  "order": {
    "amountOfMoney": {
      "currencyCode": "USD",
      "amount": 100
    },
    "customer": {
      "billingAddress": {
        "countryCode": "US"
      },
      "merchantCustomerId": "1234"
    }
  }
}

The following API response will look like this:

• If the same card was network tokenized before the first payment, network token data will be included in the response, otherwise, it will be returned in the next CIT (customer initiated transaction) or MIT (merchant initiated transaction) payment with the same card.
• In this example, response already has a network token, as the card was already tokenized, that's why it's returned.

{
  "creationOutput": {
    "additionalReference": "00000739171000000190",
    "externalReference": "000007391710000001900000100001",
    "tokenizationSucceeded": false
  },
  "payment": {
    "id": "000007391710000001900000100001",
    "paymentOutput": {
      "amountOfMoney": {
        "amount": 100,
        "currencyCode": "USD"
      },
      "references": {
        "paymentReference": "0",
        "providerId": "6100",
        "providerReference": "000JED15ftjKC001001"
      },
      "paymentMethod": "card",
      "cardPaymentMethodSpecificOutput": {
        "paymentProductId": 3,
        "authorisationCode": "000982",
        "fraudResults": {
          "fraudServiceResult": "no-advice",
          "avsResult": "E",
          "cvvResult": "0"
        },
        "schemeTransactionId": "ATID00000982",
        "card": {
          "cardNumber": "************5081",
          "cardholderName": "John Doe",
          "expiryDate": "1230"
        },
        "clickToPayUsed": false,
        "networkTokenData": {
          "networkToken": "************6473",
          "tokenExpiryDate": "1029",
          "tokenReferenceId": "M:erHxplGeS2y2NJAKT9o_DA000000000000GB"
        },
        "networkTokenUsed": true,
        "paymentAccountReference": "500135RFLPNT3TKPFPYQGNDRYKQ4Z"
      }
    },
    "status": "CAPTURE_REQUESTED",
    "statusOutput": {
      "isCancellable": true,
      "isRetriable": false,
      "statusCategory": "PENDING_CONNECT_OR_3RD_PARTY",
      "statusCode": 800,
      "statusCodeChangeDateTime": "20260918152938",
      "isAuthorized": true,
      "isRefundable": false
    }
  }
}

Below, you'll find an example request containing the essential data for a subsequent payment. For more information, please refer to our API Reference.

{
  "cardPaymentMethodSpecificInput": {
    "unscheduledCardOnFileRequestor": "cardholderInitiated",
    "unscheduledCardOnFileSequenceIndicator": "subsequent",
    "card": {
      "cvv": "123",
      "cardNumber": "5186151650005081",
      "expiryDate": "1230",
      "cardholderName": "John Doe"
    },
    "paymentProductId": 1,
    "transactionChannel": "ECOMMERCE",
    "threeDSecure": {
      "skipAuthentication": true,
      "redirectionData": {
        "returnUrl": "https://hostname.myownwebsite.url"
      }
    }
  },
  "order": {
    "amountOfMoney": {
      "currencyCode": "USD",
      "amount": 100
    },
    "customer": {
      "billingAddress": {
        "countryCode": "US"
      },
      "merchantCustomerId": "1234"
    }
  }
}

The response will look like this:

{
  "creationOutput": {
    "additionalReference": "00000739171000000191",
    "externalReference": "000007391710000001910000100001"
  },
  "payment": {
    "id": "000007391710000001910000100001",
    "paymentOutput": {
      "amountOfMoney": {
        "amount": 100,
        "currencyCode": "USD"
      },
      "references": {
        "paymentReference": "0",
        "providerId": "6100",
        "providerReference": "000JED15ftjLC001001"
      },
      "paymentMethod": "card",
      "cardPaymentMethodSpecificOutput": {
        "paymentProductId": 3,
        "authorisationCode": "000983",
        "fraudResults": {
          "fraudServiceResult": "no-advice",
          "avsResult": "E",
          "cvvResult": "0"
        },
        "schemeTransactionId": "ATID00000983",
        "card": {
          "cardNumber": "************5081",
          "cardholderName": "John Doe",
          "expiryDate": "1230"
        },
        "clickToPayUsed": false,
        "networkTokenData": {
          "networkToken": "************6473",
          "tokenExpiryDate": "1029",
          "tokenReferenceId": "S:erHxplGeS2y2NJAKT9o_DA000000000000GB"
        },
        "networkTokenUsed": true,
        "paymentAccountReference": "500135RFLPNT3TKPFPYQGNDRYKQ4Z"
      }
    },
    "status": "CAPTURE_REQUESTED",
    "statusOutput": {
      "isCancellable": true,
      "isRetriable": false,
      "statusCategory": "PENDING_CONNECT_OR_3RD_PARTY",
      "statusCode": 800,
      "statusCodeChangeDateTime": "20260918153115",
      "isAuthorized": true,
      "isRefundable": false
    }
  }
}

Using self-managed tokens

You can send us the network tokens provisioned by your token provider directly in payment request.

• Make a POST /v1/{merchantId}/payments API call.
• If you use a third party authentication provider, make sure to include necessary 3DS data in externalCardholderAuthenticationData, please refer to our API Reference for more information.

Below, you'll find an example request, the provided network token would be authenticated by us.

{
  "cardPaymentMethodSpecificInput": {
    "unscheduledCardOnFileRequestor": "cardholderInitiated",
    "unscheduledCardOnFileSequenceIndicator": "subsequent",
        "networkTokenData": {
            "cardholderName": "John Doe",
            "cryptogram": "APBNBAOZhwKGAAL6ngQmAAADFA==",
            "networkToken": "5555555555554444",
            "tokenExpiryDate": "0529"
        },
    "paymentProductId": 1,
    "threeDSecure": {
      "skipAuthentication": true,
      "redirectionData": {
        "returnUrl": "https://hostname.myownwebsite.url"
      }
    }
  },
  "order": {
    "amountOfMoney": {
      "currencyCode": "USD",
      "amount": 100
    },
    "customer": {
      "billingAddress": {
        "countryCode": "US"
      },
      "merchantCustomerId": "1234"
    }
  }
}

This will return a response like this:

{
  "creationOutput": {
    "additionalReference": "00000739171000000192",
    "externalReference": "000007391710000001920000100001"
  },
  "payment": {
    "id": "000007391710000001920000100001",
    "paymentOutput": {
      "amountOfMoney": {
        "amount": 100,
        "currencyCode": "USD"
      },
      "references": {
        "paymentReference": "0",
        "providerId": "6100",
        "providerReference": "000JED15ftjMC001001"
      },
      "paymentMethod": "card",
      "cardPaymentMethodSpecificOutput": {
        "paymentProductId": 3,
        "authorisationCode": "000984",
        "fraudResults": {
          "fraudServiceResult": "no-advice",
          "avsResult": "E",
          "cvvResult": "0"
        },
        "schemeTransactionId": "ATID00000984",
        "clickToPayUsed": false,
        "networkTokenData": {
          "networkToken": "************4444",
          "tokenExpiryDate": "0529"
        },
        "networkTokenUsed": true
      }
    },
    "status": "CAPTURE_REQUESTED",
    "statusOutput": {
      "isCancellable": true,
      "isRetriable": false,
      "statusCategory": "PENDING_CONNECT_OR_3RD_PARTY",
      "statusCode": 800,
      "statusCodeChangeDateTime": "20260918153204",
      "isAuthorized": true,
      "isRefundable": false
    }
  }
}

Process flows

Below, you'll find a detailed explanation on how network tokens are integrated into your initial flow and payment flow.

1. Consumer places an order with you.
2. You send card details to us.
3. We send authorization request to Card acquirer (optional: token creation, 3-D Secure, and fraud screening).
4. Card acquirer sends authorization request to Card issuer.
5. Card issuer returns authorization result to Card acquirer.
6. Card acquirer returns authorization result to us.
7. We return authorization result to you.
8. We send settlement request to Card acquirer.
9. Card acquirer sends settlement to Card issuer.
10. Card issuer sends funds to Card acquirer.
11. Card acquirer sends funds to us.
12. We send reporting and funds to you.

1. Consumer places an order with you.
2. You send card details to us.
3. We send authorization request to Card acquirer (optional: token data retrieval, 3-D Secure, and fraud screening).
4. Card acquirer sends authorization request to Card issuer.
5. Card issuer returns authorization result to Card acquirer.
6. Card acquirer returns authorization result to us.
7. We return authorization result to you.
8. We send settlement request to Card acquirer.
9. Card acquirer sends settlement to Card issuer.
10. Card issuer sends funds to Card acquirer.
11. Card acquirer sends funds to us.
12. We send reporting and funds to you.

Testing

You can test network token functionality in the API explorer in our Configuration Center pre-production environment.
If you want to access network token testing, please contact your account manager, who will guide you through the enablement process. We will register you within card scheme sandbox environments and configure the necessary feature flags on your behalf. 

Example testing cards you can use to test network tokens:

FAQ

Do I still need Account Updater if I am using network tokens?

In most cases, network tokens reduce the need for Account Updater because card networks automatically keep token credentials up to date when cards are replaced or expire. However, Account Updater can still provide value in edge cases such as when a transaction is processed using the original card details instead of a token, or before a token is fully provisioned. It also plays an important role when the card’s issuing BIN is not enabled for network tokenization. In these cases, network tokens cannot be generated, and Account Updater helps ensure that updated card details are still available to maintain payment continuity.

What is the best setup: profile tokens, network tokens, or both with Account Updater?

The most effective setup is typically a combination of complementary capabilities. Network tokens are the primary mechanism for enhancing security, managing credential lifecycle, and improving approval rates. Profile (card-on-file) tokens enable you to store payment details and support recurring or repeat transactions without requiring changes to your existing integration. Account Updater acts as a fallback, ensuring continuity in scenarios where tokenization is not available or in specific edge cases. Together, this layered approach delivers optimal performance, resilience, and reliability across your payment flows.

How do network tokens and profile tokens work together?

Profile tokens store the consumer’s payment method within your system, while network tokens enhance how those credentials are processed. In practice you store a profile token, and at the time of payment, it is mapped to a network token which is used for authorization. This way you get both flexibility and performance.

What should I use for recurring payments: Network tokens or Account Updater?

For recurring payments, network tokens should be your primary approach. They ensure that payment credentials remain automatically up to date, improve authorization rates through stronger issuer trust, and significantly reduce failed renewals caused by expired or replaced cards. Account Updater can complement this strategy by providing coverage in scenarios where network tokenization is not available.

What happens if network token provisioning fails or is delayed?

If a network token is not available, the transaction can still be processed using the card details. Account Updater can help keep those details up to date. This ensures no impact on checkout or transaction success.

Can I use network tokens across multiple payment service providers or acquirers?

Network tokens are generally portable across providers, particularly for recurring and merchant-initiated transactions (MIT), which allows you to maintain continuity even when working with multiple payment service providers or acquirers.

Does reusing the same token across retries cause issues?

No, the token itself remains valid across multiple attempts. What is important is that each consumer initiated transaction is supported by a fresh cryptogram and properly re-authenticated. This ensures that every authorization attempt is evaluated independently by issuers, rather than being treated as a repeat of a previous transaction, thereby improving approval outcomes. Tokens can be used without cryptograms for merchant initiated transactions. 

Does network tokenization help with Strong Customer Authentication (SCA) and authentication?

Yes, network tokenization can support a more efficient authentication experience. Tokenized transactions are often considered lower risk by issuers due to enhanced security signals, such as domain restriction and cryptographic authentication. As a result, they may reduce the likelihood of Strong Customer Authentication challenges in certain scenarios, helping improve conversion rates. At the same time, network tokenization fully supports authentication when required, ensuring compliance with regulatory frameworks such as PSD2. It is important to note that tokenized payments are not exempt from PSD2 requirements. SCA may still be applied depending on the transaction context, risk level, and issuer decision. In practice, network tokenization helps strike the right balance between security, compliance, and a seamless customer experience.