SuiteCommerce supports native tokenized Payment Instruments and external gateway integrations side by side. Use the native approach when you only need card tokenization through a single gateway. Use a payment connector like Sensepass when you need multiple payment methods, more than one processor, merchant-owned tokens, or faster global expansion.

Before any design work starts, confirm three things with your NetSuite admin:

  • Credit Card Payments and Payment Instruments features are both enabled on the account.
  • Your instance runs SuiteCommerce or SuiteCommerce Advanced 2019.1 or later, since tokenized payment instruments require that version baseline.
  • You know which gateway partners your merchant account already supports, and whether any require a separate SuiteApp installation.

Skip these checks and you will find out the hard way, mid-build, that your theme or account tier can’t do what the project plan assumes.

Key Takeaways

SuiteCommerce payments work best when native tokenization handles simple card flows and a connector like Sensepass handles method and processor breadth.

Point Details
Check your version first Native tokenized Payment Instruments require SuiteCommerce or SuiteCommerce Advanced 2019.1 or later.
Enable features in order Turn on Credit Card Payments, then Payment Instruments, before configuring any payment method.
Match profiles to currency Set up a separate Payment Processing Profile for each settlement currency and merchant bank account.
Test edge cases before launch Verify partial captures, voids, split-shipment refunds, and declined transactions to avoid orphaned authorizations.
Scale with a connector when needed Sensepass links NetSuite and SuiteCommerce to a broad range of payment methods and processors when native gateways run out of room.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Table of Contents

What NetSuite Payment Instruments Provide Natively in SuiteCommerce

Payment Instruments and their associated Payment Card Token records live on the Financial subtab of the customer record. Once enabled, they let a returning shopper check out with a saved card without re-entering card data or leaving your checkout flow. That’s the entire value proposition of native tokenization: no shopper friction, no card data touching your servers.

Tokenized payment templates only render correctly on SuiteCommerce or SuiteCommerce Advanced 2019.1 or later, and only with Base Theme templates. SiteBuilder sites simply can’t use this feature, which catches a surprising number of teams still running legacy themes off guard.

Turning it on takes two admin steps:

  • Enable the Credit Card Payments feature under Setup, then enable Payment Instruments on the Transactions subtab.
  • Review the Payment Instruments & Methods tab and confirm which payment methods carry the tokenized flag, since a method must have that flag set to true before it can be saved as a token instrument.

Pro Tip: Native instruments work well for straightforward card-on-file scenarios, like a B2B account that always pays with the same corporate card. The moment you need wallets, BNPL, or a second gateway for redundancy, native starts to feel like a wall you keep running into.

What Payment Methods and Gateways Does SuiteCommerce Support?

SuiteCommerce’s native and gateway-extended payment support falls into a few clear categories:

  • Card tokenization through native Payment Instruments, covering Visa, Mastercard, and other major networks.
  • Digital wallets, typically layered on through a connected gateway rather than out of the box.
  • BNPL and financing options, which almost always arrive through a redirect flow rather than a native template.
  • ACH and pay-by-bank methods, usually gateway dependent.
  • Hosted redirect flows for alternative payment methods, where the shopper leaves your site for third-party authentication and returns to the Order Confirmation page on approval.

NetSuite documentation references a defined set of preferred gateway partners, and some regional gateways require installing a dedicated Payment Gateway SuiteApp from a SuiteBundle rather than arriving pre-provisioned.

Before you pick a gateway, confirm the commercial side too: you need an active acquiring relationship, a merchant account for each settlement currency you plan to run, and, for some regional integrations, the correct SuiteApp already installed. Check your acquiring terms directly. Some gateway partners are processor-agnostic while others lock you into a specific acquiring agreement, which determines how easily you can switch later.

How Do You Set Up Payment Processing Profiles?

Payment Processing Profiles are where the technical gateway connection meets your actual checkout behavior. Here’s the sequence:

  1. Navigate to Setup > Accounting > Payment Processing Profiles > New.
  2. Select your gateway partner and install its integration or SuiteApp if it isn’t already provisioned.
  3. Configure the request types you need: Authentications, Authorizations, Captures, Sales, Credits, Refunds, and Voids.
  4. Create a separate profile for each settlement currency and merchant bank account, since profiles are generally scoped one-to-one with currency and bank relationship.
  5. Assign the profile to the appropriate web store or subsidiary.

The request types you enable directly shape checkout behavior:

  • A Sales request type charges the card immediately, appropriate for straightforward digital goods or immediate fulfillment.
  • Authorization plus Capture separates the reservation of funds from the charge, useful for B2B orders with partial fulfillment or split shipments.
  • Refunds and Voids need explicit support checks, since not every gateway partner implements both the same way.

Before switching gateways, test void support and payer authentication behavior specifically. Those two features vary the most between partners, and a gap there tends to surface only after go-live.

Developer Hooks: SuiteScript, Request Handlers, and Token Flows

Third-party checkout integrations route through request handlers, files with a .ss extension that your frontend .ssp templates call using proceedToCheckout(). That function passes a checkoutsettings JSON object from the frontend to the handler, which is where most custom payment logic actually lives. SuiteScript 2.0 carries specific integration constraints for SSP applications that you should confirm against your NetSuite version before scoping the build.

Tokenized instruments get stored on the customer record once a payment method’s tokenized flag is set to true. That flag is not automatic. It has to be explicitly configured on the payment method record before any token flow works end to end.

A practical implementation checklist looks like this:

  • Build server-side SuiteScript hooks for each request type your business needs, not just the default Sale.
  • Use hosted fields or an iframe approach so raw card data never touches your own servers.
  • Install any required SuiteApp before writing custom code that assumes it’s already there.
  • Confirm your proceedToCheckout() payload matches what the request handler expects, field for field.

Pro Tip: Test partial captures, split-shipment refunds, voids, guest checkout versus logged-in flows, and declined transactions before launch. Orphaned authorizations from untested edge cases are one of the most common post-launch support tickets, and they’re painful to trace after the fact because the shopper already thinks the order went through.

Does SuiteCommerce Support 3D Secure and Tokenized Security?

Tokenization does real work for PCI compliance, not just convenience. When card data flows through hosted fields into a tokenized Payment Instrument, it never touches your SuiteCommerce front-end, which can bring your compliance scope down toward SAQ A-EP territory.

3D Secure support runs through the Enable 3D Secure Payments setting. This is not optional housekeeping: 3DS1 support has ended, and sites need to migrate to 3DS2 wherever their gateway partner offers it to keep payer authentication working reliably.

Before launch, confirm:

  • The 3D Secure toggle is active and tested against a live card that triggers step-up authentication.
  • Your gateway partner has confirmed 3DS2 support, not just legacy 3DS1.
  • Hosted field or iframe implementation is verified so card data genuinely bypasses your servers.

When Should You Use a Payment Connector Instead of a Native Integration?

Native Payment Instruments handle single-gateway, card-only scenarios well. They start to strain the moment your business needs more: multiple regional processors, wallets, BNPL, or the ability to renegotiate rates without a re-integration project. That’s the operational gap Sensepass is built to close, as a payment connector linking NetSuite and SuiteCommerce to more than 100 payment methods and 50-plus card processors through a single integration, with a payment gateway, surcharging, tap-and-pay, and pay-by-link running on top of it.

The practical benefits stack up:

  • One connector handles NetSuite, POS, and eCommerce checkout instead of separate integrations for each channel.
  • You keep ownership of your payment tokens, so switching or adding a processor doesn’t mean rebuilding your integration.
  • Surcharging and pay-by-link ship as add-ons rather than separate projects.
Decision factor Native SuiteCommerce integration Connector approach (Sensepass)
Number of gateways supported Typically one per profile, added manually Many processors through one connection
Global payment method breadth Limited to what your gateway partner offers Cards, wallets, BNPL, pay-by-bank, crypto
Token ownership Held by the gateway partner Owned by the merchant
Switching cost Re-integration project per gateway change Add or swap processors without rebuilding

If your roadmap includes more than one or two gateways, regional wallets, BNPL, or expansion into new markets, a connector approach scales better than stacking native profiles one at a time.

When Should You Use a Payment Connector Instead of a Native Integration? — overview diagram

A Practical Note From the Field

My honest recommendation: use NetSuite’s native Payment Instruments for simple card flows, and layer a connector on top the moment you need method or processor breadth. Loop in finance, security, and platform engineering before you commit to either path.

Get Enterprise Payment Coverage Without the Re-Integration Headache

Rebuilding your gateway integration every time you add a payment method or switch processors is exactly the operational drag Sensepass exists to remove. As a payment connector, Sensepass links your NetSuite and SuiteCommerce environment to more than 100 payment methods and 50-plus card processors through one integration, with a payment gateway, surcharging, tap-and-pay, and pay-by-link running on top.

Sensepass

What that means in practice for your team:

  • Processor-agnostic architecture, so you can add or replace a processor without touching checkout code.
  • Merchant-owned tokens, which keep you in control if you ever renegotiate processing rates.
  • Multi-channel transaction data that reconciles automatically back into NetSuite.
  • Fast enablement of digital wallets, BNPL, pay-by-bank, and crypto methods as your market expands.

If you’re evaluating how token creation actually works inside NetSuite, see how Sensepass builds tokenization links directly in NetSuite to get a concrete sense of the integration effort involved.

Sources

  • NetSuite Applications Suite – SuiteCommerce Payment Instruments Integration