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.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
- 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}
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.paypal_token_requestor_id along with per-network sub-product TRIDs for Visa VTS, Mastercard MDES, American Express AETS, and Discover DDX.
- Sample request
- Sample response (201 Created)
GET …/token-requestors/{tokenRequestorId}: confirm your config and supported networksPOST …/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.
-
Collect card details: PAN, expiration date, CVV, and cardholder name. Then pass these values in your enrollment request using the
payment_dataobject. Use thebase64-encodeoption. -
Call: Send a
POSTrequest to/v1/payment-tokenization/enrollmentswith the card details. A201response returns theenrollment_idandnetwork_token. -
Persist: Keep the
enrollment_idandnetwork_tokenin your card vault. You’ll need both for all subsequent lifecycle and payment credential calls.
- Sample request
- Sample response (201 Created)
- 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 with601101000(PAN ineligible)
- Sample request: Retrieve card art/Terms & Conditions
- Sample response (200 OK)
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
POSTrequest to/v1/payment-tokenization/batch-requestswith a file containing the card details. PP TSP returns abatch_request_idto track the batch. - Listen: PP TSP sends a
PAYMENT-TOKENIZATION.BATCH-REQUEST.STATUS-CHANGEDwebhook when the batch completes or fails. - Retrieve results: Send a
GETrequest to/v1/payment-tokenization/batch-requests/{id}. Append?fields=ALLonly after the batch reachesCOMPLETEDstatus to avoid loading partial data.
- Sample request: Submit a batch enrollment
- Sample response (202 Accepted)
- Sample request: Get batch status
- Sample response
Retrieve the batch tokenization results by sending the following request:
- Sample request: Get batch details
- Sample response
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
POSTrequest to/v1/payment-tokenization/payment-credentialswith token details and transaction data.payment-credentialsendpoint supports two modes, fetch and pre-fetch, which you can select through thePrefer: respond-asyncheader. 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.
- Sample request: Fetch, synchronous
- Sample request: Prefetch, asynchronous
- Sample response
- Sample Account Funding Transaction request
- Sample response
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.