Payment Card Token Record Now Exposed via SuiteTalk REST API

What changed

NetSuite has exposed the paymentcardtoken record to the REST web services API. This record represents a tokenized payment card — a reference created by a payment gateway integration that stands in for the actual card number (PAN). Previously, interacting with payment card tokens programmatically required SuiteScript or SOAP; this change adds full REST API support.

Key details about the record:

• Record ID: paymentcardtoken
• Record type: Top-level record (not a subrecord); has no subrecords of its own.
• Supported HTTP methods: At minimum POST (create) and PATCH (update). Check the REST API Browser for the full list (GET, DELETE, etc.).
• Endpoint: /services/rest/record/v1/paymentCardToken

Notable fields

• cardBrand — reference ({"id": "1"})
• paymentMethod — reference to the payment method record
• cardExpirationDate — format YYYY-MM
• cardIssuerIdNumber — BIN / IIN (string)
• cardLastFourDigits — last four of the PAN
• cardNameOnCard — cardholder name
• cardType — e.g. {"id": "CREDIT"}
• entity — reference to the customer record
• isDefault — boolean
• preserveOnFile — boolean, controls whether the token persists
• token — the actual token string from the gateway
• tokenExpirationDate — format YYYY-MM
• tokenFamily — reference
• tokenNamespace — string identifier for the token namespace

Code samples from Oracle

Create a token (POST):

POST /services/rest/record/v1/paymentCardToken

Body includes cardBrand, paymentMethod, entity, token, and related fields. See the source page for the full JSON payload.

Update a token (PATCH):

PATCH /services/rest/record/v1/paymentCardToken/<id>

Body example: {"memo": "Updated MEMO"}

Prerequisites

1. Enable the Payment Instruments feature (Setup > Company > Enable Features).
2. Enable the Credit Card Payments feature for customer credit card processing.

What to do

1. If you manage payment tokens via custom SuiteScript or SOAP integrations — evaluate whether migrating to the REST endpoint simplifies your architecture. The REST record is a first-class citizen, not a subrecord, so standard REST patterns (query, CRUD) apply directly.
2. If you are building a new gateway integration — use POST /services/rest/record/v1/paymentCardToken to create tokens and PATCH to update them after gateway callbacks, rather than relying on SuiteScript record.create/record.load.
3. Review the REST API Browser for the complete schema — Oracle's documentation does not enumerate every supported HTTP method or query parameter here. Confirm whether GET and DELETE are available for your use case.
4. Check role permissions — ensure the integration role or token-based authentication (TBA) credentials you use have access to the paymentcardtoken record type. REST record access is governed by the same permission model as the UI.
5. PCI note: While the token itself is not a PAN, the cardIssuerIdNumber (BIN) and cardLastFourDigits fields are still cardholder data elements under PCI DSS. Ensure your integration's logging and storage practices account for this.

Gaps in the source

Oracle does not specify which NetSuite release introduced this REST support. The version is not stated in the URL, title, or body. If you need to confirm availability in your account, check the REST API Browser in your target environment or contact NetSuite support to verify the record is live for your account's release.