Payment Card Record Now Available via SuiteTalk REST API

What changed

Oracle has exposed the paymentcard record to the SuiteTalk REST web services API. This means you can now create, read, and update tokenized payment card instruments programmatically via REST without needing SuiteScript or SOAP-based SuiteTalk calls.

The record represents a card-based funding source (Visa, Mastercard, etc.) tokenized through a payment gateway and saved against a customer record. It is not a subrecord and has no subrecords of its own, so you interact with it as a top-level record.

Endpoint

• Base path: /services/rest/record/v1/paymentCard
• Record ID: paymentcard
• POST — Create a new payment card
• PATCH — Update an existing payment card at /services/rest/record/v1/paymentCard/{id}

Key fields (from code samples)

• cardNumber — full PAN (tokenized by the gateway on save)
• entity — customer internal ID reference ({"id": "28"})
• expirationDate — format YYYY-MM
• isDefault — boolean
• nameOnCard — cardholder name string
• preserveOnFile — boolean; keeps the tokenized card stored for future transactions
• memo — free-text memo field

For the full field reference, consult the REST API Browser under the paymentCard record type.

Prerequisites

1. Enable the Payment Instruments feature (Setup > Company > Enable Features).
2. Enable the Credit Card Payments feature and configure at least one merchant account and payment processing profile.

What to do

1. Verify feature flags. Confirm both Payment Instruments and Credit Card Payments are enabled in your target account before making REST calls. Requests against the paymentCard endpoint will fail without them.
2. Review the REST API Browser. The code samples in the release notes cover only POST and PATCH. Check the browser for supported GET, DELETE, query parameters, and any sub-resource links.
3. Audit existing integrations. If you are currently creating payment cards through SuiteScript (N/record with record.Type.PAYMENT_CARD) or SOAP, evaluate whether migrating to REST simplifies your payment-onboarding flow—especially for external portals or microservices that already authenticate via OAuth 2.0 / token-based auth.
4. Handle card numbers carefully. The POST sample passes a raw PAN. Ensure your integration is PCI-DSS compliant; the card number is tokenized server-side by NetSuite’s gateway, but your calling system must still meet SAQ requirements for transmitting cardholder data.
5. Test in sandbox first. Use a sandbox account with a test payment gateway to validate create/update flows before touching production payment instruments.

Note: The source does not specify which NetSuite release introduced this capability. Check the REST API Browser version history or your account’s release notes page to confirm availability in your environment.