Skip to main content
This guide walks through the end-to-end implementation of Ecommerce network tokenization using Secure Credential Services by PayPal.

Prerequisites

To integrate with Secure Credential Services, you need:
  • A PayPal account with a Client ID provisioned for Ecommerce tokenization
  • OAuth 2.0 credentials (Client ID and Client Secret)
  • Required API scopes provisioned by the PayPal team for your use case
  • A decision on your TRID model
Note: Contact your PayPal account representative to obtain sandbox OAuth credentials and confirm your TRID model before starting. Configure sandbox and production environments separately: never share credentials between environments.

API reference

Use the following base URLs and endpoints for all Payment Tokenization requests.

Base URLs

All paths are prefixed /v1/payment-tokenization/. All PayPal REST API requests target one of two base URLs:

List of APIs

Authentication

All API calls require an OAuth 2.0 Bearer token obtained from the PayPal token endpoint.
Bearer tokens expire after approximately 8-9 hours. Implement token caching and refresh logic in your client. Do not request a new token on every API call.
Note: The required API scopes for Ecommerce tokenization must be provisioned by the PayPal team before you begin. Work with your PayPal account representative to confirm the correct scopes for your integration.

Steps for integration

Complete the following steps in order to set up your environment, onboard your TRID, and enroll cards for Ecommerce tokenization. Depending on your use case, enrollment uses either real-time provisioning, where a cardholder adds or updates a card in an interactive flow, or bulk provisioning, which tokenizes existing cards-on-file at scale.

1. Set up PayPal sandbox environment

The sandbox is where you test end-to-end using simulators and mocked data — no real authorizations or settlements occur. What you need from PayPal’s integration team:
  • OAuth client credentials (Client ID and Secret)
  • One or more sandbox TRIDs aligned to your business model
  • Required authorization scopes
Environment configuration:
  • PayPal sandbox base URL: api-m.sandbox.paypal.com
  • Production base URL: api-m.paypal.com
  • API calls follow the pattern: https://{base-url}/v1/payment-tokenization/{resource}
Keep sandbox and live environment credentials completely separate — never share them between environments.

2. Onboard your Token Requestor ID (TRID)

To enable tokenization across supported card networks, merchants must first complete onboarding for tokenization. A TRID is a unique identifier issued to a token requestor that enables them to securely request network tokens from card networks.
Provide your merchant name, partner name, client credentials, and product template. The response returns your paypal_token_requestor_id along with per-network sub-product TRIDs for Visa VTS, Mastercard MDES, American Express AETS, and Discover DDX.
Once registered, verify your TRID with these two calls before proceeding:
  • GET …/token-requestors/{tokenRequestorId}: confirm your config and supported networks
  • POST …/search-token-requestors: useful in multi-TRID setups to discover TRIDs by name or status

3. Determine minimum API implementation for your business model

4. Implement real-time token enrollment

Choosing between real-time and bulk provisioning

You can use a combination of both real-time and bulk provisioning methods depending on your use cases. The general guideline for partners is as follows:
  • If the card is being added or updated by a Cardholder in an interactive flow, use real-time provisioning.
  • If the card already exists in a secure vault and needs to be upgraded to a network token at scale, use bulk provisioning.
Use the following interactive flows when a cardholder adds or updates a payment method.
  • Collect card details: PAN, expiration date, CVV, and cardholder name. Then pass these values in your enrollment request using the payment_data object. Use the base64-encode option.
  • Call: Send a POST request to /v1/payment-tokenization/enrollments with the card details. A 201 response returns the enrollment_id and network_token.
  • Persist: Keep the enrollment_id and network_token in your card vault. You’ll need both for all subsequent lifecycle and payment credential calls.
Run this full flow end-to-end in the sandbox first with PayPal-provided test cards before moving to a live environment. PayPal sandbox test cards:
  • Visa: 4622943127025676 (success), 4622943127025673 (ineligible)
  • Mastercard: 5204731530000000 (success), 5204731530000007 (ineligible)
  • American Express (Amex): 3717073691911199 (success), 371707369199999 (ineligible)
  • Discover: Cards starting with 6011000000 (success), Cards starting with 601101000 (PAN ineligible)
Use the content_id values returned in the enrollment response’s contents array to retrieve display assets such as card art:

5. Implement bulk enrollment - optional

Use this to asynchronously tokenize large volumes of existing cards-on-file (up to 1,000 for batch).
  • Submit batch: Send a POST request to /v1/payment-tokenization/batch-requests with a file containing the card details. PP TSP returns a batch_request_id to track the batch.
  • Listen: PP TSP sends a PAYMENT-TOKENIZATION.BATCH-REQUEST.STATUS-CHANGED webhook when the batch completes or fails.
  • Retrieve results: Send a GET request to /v1/payment-tokenization/batch-requests/{id}. Append ?fields=ALL only after the batch reaches COMPLETED status to avoid loading partial data.
Retrieve the batch tokenization results by sending the following request:
After the batch status is COMPLETED, request full item-level details by sending the following request:

6. Integrate payment credentials into your auth flow

For card-not-present authorizations, call the payment-credentials API to retrieve the network token and cryptogram before constructing the authorization request, then pass these values to your payment processor.
  • Call: Send a POST request to /v1/payment-tokenization/payment-credentials with token details and transaction data. payment-credentials endpoint supports two modes, fetch and pre-fetch, which you can select through the Prefer: respond-async header. Call just-in-time for Cardholder-Initiated Transaction (CIT) transactions. Cryptograms are single-use and have a limited validity window.
  • The response returns the network token, cryptogram, and Electronic Commerce Indicator (ECI) needed for authorization. Use these values instead of the original card data when processing the payment.
  • Pass these fields unchanged into the authorization message to your payment processor. This replaces the raw card number entirely.

7. Handle token lifecycle changes

Lifecycle changes must be mirrored in your vault immediately. A suspension only pauses the enrollment. A close is permanent and cannot be undone. It cascades to the underlying network token, which is closed asynchronously. For issuer-initiated changes, such as card reissue, expiration date update, and fraud replacement, PP TSP automatically propagates them and notifies you using PAYMENT-TOKENIZATION.TOKEN-STATUS.CHANGED or PAYMENT-TOKENIZATION.TOKEN-METADATA.CHANGED webhooks. Process these events to keep your vault in sync.

8. Register and test the webhooks

Subscribe to these webhook events to keep your systems current:

Sample webhook payloads

Each event is delivered to your registered endpoint in this envelope:
PAYMENT-TOKENIZATION.TOKEN-STATUS.CHANGED
PAYMENT-TOKENIZATION.PAYMENT-CREDENTIAL.UPDATED
PAYMENT-TOKENIZATION.TOKEN-METADATA.CHANGED
PAYMENT-TOKENIZATION.BATCH-REQUEST.STATUS-CHANGED
PAYMENT-TOKENIZATION.TOKEN-REQUESTOR.UPDATED
Note: Looking for detailed documentation? A comprehensive Ecommerce Solution Guide, Integration Guide, and API Specification Document are available upon request. The API Specification Document includes sample reference payloads and end-to-end use case examples specific to Ecommerce network tokenization, covering all APIs and common integration scenarios. Reach out to your PayPal Account Representative for the latest documentation.