Tokens are used to securely process payments without exposing sensitive card data.

However, token usage depends on whom issued the token and the payment flow in which it is used.

Tokenization

Tokenization is a process that replaces sensitive payment credentials with an algorithmically generated payment token. It is a fraud-prevention measure designed to protect sensitive payment data, such as:

  • Card number
  • Cardholder name
  • Card expiration date

Payment tokens are issued in real time during payment processing by Solidgate Vault or card network tokenization services. Tokens issued by card networks (Visa Token Service, Mastercard Secure Card) are also known as network tokens.

Solidgate vault is a PCI-compliant token vault that securely stores payment instruments, including cards, network tokens, Apple Pay, Google Pay, and other payment methods.

Payment tokens can be used in future payments to represent sensitive payment credentials in transaction processing without exposing the actual payment card details.

When migrating from another processor, securely export stored card data and transfer it to Solidgate for tokenization. Solidgate issues new tokens, and you map them to your customers.


Solidgate tokens

When Solidgate handles tokenization, a payment token is returned in the payment response that can be used for follow-up payments:

  • one-click when your customer uses previously stored credentials to initiate a payment
  • unscheduled or regular subscription-based payments

Token usage flow

To use Solidgate tokens

  1. A customer provides payment credentials during the checkout process on the merchant's side.
  2. Payment credentials are sent to the Solidgate vault without ever hitting the merchant's server in one of the following ways:
  3. Solidgate securely saves payment credentials and links them to a token generated by Solidgate vault.
  4. The response includes a token that represents the stored payment method.
    • If the payment fails due to a network error or a decline from the issuing bank, the token is returned, allowing merchants to use the retry logic on their end without re-collecting card data.
  5. Save the token and use it for follow-up payments via the Recurring API request.

Run test to validate recurring token payments in the sandbox environment before production.

The token received after Apple Pay and Google Pay payments can be used only for merchant-initiated payments (MIT).

If a customer is present during checkout, the Apple Pay or Google Pay buttons must be displayed.

Network tokens

Payment network tokens replace real card details during transactions to enhance security. Visa and Mastercard support various types of tokens:

  • Device-based tokens work only on the device they were issued to, for example, Apple Pay, Google Pay
  • Non-device-based tokens can be used from any device, typically by e-commerce merchants or apps where customers buy subscriptions

Solidgate acts as:

  • Visa and Mastercard tokenization services provider. On behalf of the merchant (OBO Merchant), Solidgate opens access to these services without any extra effort on the merchant’s side to integrate with card schemes’ tokenization services
  • Network token processor without acting on behalf of the merchant card schemes’ tokenization services provider.

Merchant’s service provider

To use network tokens on behalf of the (OBO) Merchant service provider

  1. A customer provides payment credentials and PAN during the checkout process on the merchant's side.
  2. Payment credentials are sent to the Solidgate vault without ever hitting the merchant's server with Charge API request with PAN.
  3. Solidgate securely saves payment credentials and links them to a token generated by Solidgate's tokenization service.
  4. If a merchant is involved in VTS and SCOF, the payment credentials are tokenized in the VTS or SCOF as soon as the issuing bank approves the tokenization request, and the network token is stored in the Solidgate vault linked to the Solidgate token.
  5. Notifications are sent when a created network token Webhook or an updated network token Webhook by Visa or Mastercard.
  6. The Digital Primary Account Number (DPAN) of the network token is used in payment processing.
  7. The payment response includes a token that represents the stored payment method (card, Apple Pay, or Google Pay).
  8. The merchant saves the token and uses it for follow-up payments via the Recurring API request.

Recurring API requests from merchants using VTS and SCOF services are automatically processed with network tokens through the connector account for the same websites and mobile apps where the initial charge, Apple Pay, or Google Pay transaction occurred.

Processing network tokens

If you or your provider receives network tokens directly from Visa or Mastercard, you can process them through Solidgate. The same applies if you have your own integration with Apple Pay and Google Pay, and if you decrypt payloads on your end, storing device-based network tokens for subscription-based payments.

Solidgate lets you process payments with these network tokens, so you can continue processing seamlessly when switching providers without generating new network tokens. Key benefits:

  • Keep tokens with your provider or in your vault while using Solidgate for payment processing
  • Maintain uninterrupted service during provider transitions
  • Retain full Apple Pay and Google Pay token support for recurring payments
  • Preserve your current setup while Solidgate handles processing in the background

However, as in this case, Solidgate does not act in the OBO Merchants’ role. It does not manage the lifecycle of these network tokens. For this reason, Solidgate does not generate or provide a token in any of the following scenarios. If you need to process one-click or recurring payments, use one of the following:

  • MIT with DPAN from Apple Pay or Google Pay
  • MIT with DPAN from Visa or Mastercard
  • CIT with DPAN from Visa or Mastercard

Network token payment flow

Charge API request supports two types of one-time payments:

  • pan Primary Account Number (PAN) original card number
  • dpan Digital Primary Account Number (DPAN) replacement card number

You can specify the token type using the optional card_data_type parameter with values like dpan , the default is pan . When processing payments with a dpan , specific parameters must be included depending on the DPAN source and payment scenario.

  • dpan_source is required where the DPAN source:
    • apple-pay token from Apple Pay
    • google-pay token from Google Pay
    • vts tokenization service provided by Visa Token Service (VTS)
    • mdes tokenization service provided by Mastercard Digital Enablement Service (MDES)
    • scof Secure Card on File (SCOF) tokenization by Mastercard
  • payment_type is required and indicates the payment initiator:
    • 1-click Customer-Initiated Transactions (CIT) customer present
    • recurring , retry , installment , rebill Merchant-Initiated Transactions (MIT) customer not present
MIT with DPAN from Apple Pay or Google Pay

If you accept Apple Pay or Google Pay payments for subscriptions and store device-based tokens, these tokens can only be used for merchant-initiated payments. This includes recurring or scheduled payments.

In Charge API request:

  • payment_type must not be 1-click , and must be one of the recurring , retry , installment , or rebill
  • scheme_transaction_id is required
  • force3ds must not be true , 3D Secure authentication should not be forced
  • card_number, card_exp_month, card_exp_year, card_holder, pass DPAN details
Apple Pay 
{
  "card_data_type": "dpan",
  "dpan_source": "apple-pay",
  "type": "auth",
  "payment_type": "recurring",
  "scheme_transaction_id": "343453453",
  "force3ds": false,
  "card_number": "4441114467564454",
  "card_exp_month": "01",
  "card_exp_year": "2027",
  "card_holder": "John Snow"
}

If you want to process CIT, Solidgate offers two options:

Google Pay 
{
  "card_data_type": "dpan",
  "dpan_source": "google-pay",
  "type": "auth",
  "payment_type": "recurring",
  "scheme_transaction_id": "343453453",
  "force3ds": false,
  "card_number": "5332345678901234",
  "card_exp_month": "12",
  "card_exp_year": "2028",
  "card_holder": "John Snow"
}

If you want to process CIT, there are two options:


MIT with DPAN from Visa or Mastercard

If you have direct integration or use a third-party provider or orchestrator that receives, stores, and manages Visa or Mastercard tokens, you can use these tokens for merchant-initiated recurring or scheduled payments.

In Charge API request:

  • payment_type must not be 1-click , and must be one of the recurring , retry , installment , or rebill
  • scheme_transaction_id is required
  • force3ds must not be true , 3D Secure authentication should not be forced
  • card_number, card_exp_month, card_exp_year, card_holder, pass DPAN details
{
  "card_data_type": "dpan",
  "dpan_source": "vts/mdes/scof",
  "type": "auth",
  "payment_type": "recurring/retry/installment/rebill",
  "scheme_transaction_id": "343453453",
  "force3ds": false,
  "card_number": "4441114467564454",
  "card_exp_month": "01",
  "card_exp_year": "2027",
  "card_holder": "John Snow"
}

CIT with DPAN from Visa or Mastercard

If you have a direct integration or an orchestrator that receives, stores, and manages Visa or Mastercard tokens, you can use these tokens for customer-initiated recurring or scheduled payments.

In Charge API request:

  • payment_type must be 1-click
  • cryptogram is required , you must obtain the cryptogram and send it
  • eci is required , you must get Electronic Commerce Indicator (ECI) from VTS/MDES/SCOF and send it

Payment authentication:

  • It is highly recommended to set force3ds true if you want Solidgate to initiate 3D Secure authentication, as this helps optimize payment success rates.
  • If the payment was already authenticated on your side, send the authentication results inside the external_mpi_data object
3DS must be processed by Solidgate 
{
  "card_data_type": "dpan",
  "dpan_source": "vts",
  "type": "auth",
  "payment_type": "1-click",
  "cryptogram": "YwAAABkAg0+NbusA",
  "eci": 5,
  "force3ds": true,
  "card_number": "4441114467564454",
  "card_exp_month": "01",
  "card_exp_year": "2027",
  "card_holder": "John Snow"
}
3DS must be processed by client MPI provider 
{
  "card_data_type": "dpan",
  "dpan_source": "vts",
  "type": "auth",
  "payment_type": "1-click",
  "cryptogram": "YwAAABkAg0+NbusA",
  "force3ds": true,
  "external_mpi_data": {
    "three_ds_version": "2.2.0",
    "eci": "01",
    "cryptogram": "QURZRU4gM0RTMiBURVNUIENBVlY=",
    "ds_transaction_id": "6edcc246-23ee-4e94-ac5d-8ae620bea7d9",
    "cryptogram_algorithm": "A",
    "three_ds_flow": "frictionless",
    "three_ds_server_transaction_id": "6edcc246-23ee-4e94-ac5d-8ae620bea7d9",
    "ds_enrollment_response": "Y",
    "acs_challenge_mandated_ind": "Y",
    "transaction_challenge_exemption": "05",
    "authentication_response": "Y",
    "authentication_timestamp": "2024-12-05T12:00:00.000Z",
    "ds_transaction_reason": "01",
    "acs_transaction_id": "6edcc246-23ee-4e94-ac5d-8ae620bea7d9",
    "authentication_method": [
      "02",
      "03"
    ],
    "challenge_cancel_ind": "01"
  },
  "card_number": "5332345678901234",
  "card_exp_month": "12",
  "card_exp_year": "2028",
  "card_holder": "John Snow"
}