Configuring SuiteCommerce starts with more than turning on a web store. You must enable the NetSuite features that support commerce, define company and website preferences, assign the correct roles and permissions, and test how those settings affect pricing, inventory, customer accounts, checkout, and order processing.
SuiteCommerce features and preferences should be configured in a sandbox first, documented by business purpose, and validated through real customer scenarios before production release. The safest process is to map each storefront requirement to a NetSuite feature, preference, record, permission, or SuiteCommerce configuration value. That approach prevents common failures such as missing customer data, incorrect price levels, unavailable payment methods, broken checkout behavior, or orders that do not follow the intended operational workflow.
This guide focuses on the configuration stage, including how to identify required features, set preferences, control access, and verify the result. For the broader discovery process, see our guide on SuiteCommerce requirements gathering, which covers the business questions that should be answered before configuration begins.
What are SuiteCommerce features and preferences?
SuiteCommerce features are NetSuite capabilities that provide the underlying functionality for an online storefront. Preferences are account, website, commerce, customer, transaction, and presentation settings that determine how those capabilities behave.
The exact labels and available options depend on the NetSuite account, SuiteCommerce product version, installed bundles, enabled modules, and administrator permissions. A SuiteCommerce implementation might use settings for:
Web presence and website operation
Shopping and checkout
Customer registration and login
Multiple currencies and subsidiaries
Inventory availability
Pricing and quantity pricing
Promotions and coupons
Shipping and payment methods
Tax calculation
Order management and fulfillment
Customer center access
Search, merchandising, and product presentation
A feature enables a capability, but it does not automatically define the correct business behavior. For example, enabling multiple currencies does not determine which currency a particular customer sees. That result depends on factors such as the customer record, subsidiary, website configuration, price availability, currency settings, and storefront logic.
This distinction matters because many SuiteCommerce problems appear to be design defects when the actual cause is a missing NetSuite feature, incomplete preference, role permission, or incompatible record configuration.
Before enabling SuiteCommerce features, document the dependencies
The first configuration task is not clicking an Enable checkbox. It is creating a dependency map that connects each requested storefront function to the NetSuite data and settings it requires.
A customer-specific price display, for example, may depend on:
Customer or contact authentication
Customer category or price level
Subsidiary and currency
Item pricing records
Quantity pricing rules
Contract or customer-specific pricing
Promotions and effective dates
Website visibility
Inventory location rules
The feature checklist should therefore include an owner and a validation scenario for every capability. A basic configuration matrix might look like this:
| Storefront requirement | NetSuite dependency | Preference or control to verify | Validation scenario |
|---|---|---|---|
| Customer login | Customer records and online access | Registration and account access settings | Existing customer signs in and sees the correct account |
| Account-specific pricing | Price levels, currencies, customer data | Pricing and display preferences | Two customer types see their intended prices |
| Product availability | Items, locations, inventory data | Availability and location rules | Product status matches the approved inventory rule |
| Online ordering | Sales orders and transaction permissions | Checkout and order preferences | Submitted order creates the correct transaction |
| Guest checkout | Website and customer creation behavior | Guest purchasing settings | Guest can purchase without exposing customer data |
| Shipment selection | Shipping methods and fulfillment rules | Shipping preferences | Eligible shipping methods appear accurately |
| Payment processing | Payment methods and gateway setup | Payment and checkout preferences | Approved payment option completes successfully |
This mapping produces information that a generic setup checklist often misses: the record ownership of each storefront value. If a price is controlled by a customer record, changing a website preference will not resolve an incorrect price. If inventory is controlled by location availability, changing the product page template will not make the quantity accurate.
Which NetSuite features does SuiteCommerce require?
SuiteCommerce requires a functioning NetSuite foundation for websites, commerce transactions, customers, items, pricing, inventory, and fulfillment. The precise feature set varies, but the following areas deserve review in every implementation.
Website and web presence features
The website foundation controls the storefront identity, domain, site records, web pages, and online presentation. Confirm that the relevant website records exist and that the intended domain, shopping domain, secure domain, and touchpoints are configured correctly for the environment.
A domain setup issue can look like a deployment problem when the actual issue is that the site is not associated with the expected domain or secure checkout path. Confirm the sandbox domain separately from the production domain. Do not treat a successful page load as proof that checkout, account pages, and secure transactions are correctly configured.
Shopping and transaction features
Shopping features support the core storefront journey, including viewing items, adding products to a cart, creating transactions, and completing checkout. Verify that the account supports the intended transaction types and that item records are available for web presentation.
The sales order is a particularly important entity. Confirm which customer, subsidiary, location, currency, price level, tax treatment, and sales channel values should be written to the order. If the storefront creates a valid sales order but assigns the wrong subsidiary or price level, the configuration is not complete.
Customer access and account features
Customer accounts require more than a login form. Review how customers register, authenticate, reset passwords, view orders, access invoices, manage addresses, and use company-account permissions.
For B2B commerce, the customer record and contact record often drive different views and permissions. Decide whether customer contacts can place orders, see invoices, access pricing, manage addresses, or submit orders for approval. These rules must align with NetSuite roles and permissions rather than relying only on storefront visibility.
Item, inventory, and pricing features
Item records need accurate web visibility, descriptions, images, units, pricing, and availability data. Inventory settings should reflect the business rule the storefront is expected to display. That rule might be total available inventory, location-specific availability, available-to-promise quantity, or a simpler in-stock status.
Pricing requires particular care. SuiteCommerce may display different prices based on customer identity, price level, currency, quantity breaks, promotions, or contract logic. Test pricing while logged in as representative customer types. An administrator viewing the storefront is not a valid substitute for a customer-specific pricing test.
Shipping, payment, and tax features
Shipping and payment features must be reviewed together with checkout preferences. A shipping method that appears in NetSuite does not necessarily belong on every storefront order. Confirm geographic restrictions, delivery addresses, carrier calculations, handling charges, and fulfillment implications.
Payment configuration also requires end-to-end validation. Test authorization, declined payments, saved payment methods, purchase orders, refunds, and order status handling where those options are supported. Tax behavior should be tested with the actual combinations of customer location, shipping address, nexus, subsidiary, item taxability, and transaction type that matter to the business.
How do you enable required SuiteCommerce features?
Use a staged process rather than enabling every commerce-related option at once.
1. Start in a sandbox
Create a configuration record that identifies the sandbox account, SuiteCommerce version, installed bundles, domains, integrations, and planned release scope. Record the date and administrator responsible for each configuration change.
A sandbox is valuable because feature changes can affect existing scripts, workflows, integrations, saved searches, and transaction forms. It also provides a controlled environment for testing customer permissions and checkout scenarios without creating unnecessary production transactions.
2. Enable the minimum feature set
Review the relevant NetSuite feature areas and enable only what the documented requirements call for. In many accounts, features are managed through Setup > Company > Enable Features, although menu labels and access can differ by account configuration and role.
Do not assume that more enabled features produce a better storefront. Unused features increase the number of possible data paths, permissions, and testing conditions. A focused feature set makes it easier to understand why a customer sees a particular price, product, payment method, or account option.
After enabling a feature, save the change and verify whether NetSuite identifies a dependency or requires additional setup. Some functions also require records, bundles, permissions, or configuration values before they become useful.
3. Configure the website and commerce records
Next, review the website record, domain details, site settings, shopping configuration, and SuiteCommerce Configuration record where applicable. The SuiteCommerce Configuration record controls storefront behavior that is separate from the general NetSuite company preference layer.
Keep a clear distinction between:
NetSuite account preferences, which affect broader system behavior
Website settings, which affect a specific web presence
SuiteCommerce Configuration values, which affect storefront behavior and presentation
Extensions and scripts, which introduce custom behavior
This distinction is a practical diagnostic tool. If the issue exists across all channels, investigate account or record configuration. If it exists only on one website, investigate website settings. If it appears only in a custom storefront component, investigate the extension or script.
4. Configure permissions and roles
Give administrators, customer service users, sales representatives, and customers only the access their responsibilities require. Review permissions for customers, contacts, transactions, items, pricing, invoices, returns, and payment information.
Role testing should include both what a user can see and what they can do. A customer who can view an invoice may not be allowed to pay it. A contact who can place an order may not be authorized to approve a quote. These differences should be tested through the actual storefront workflow, not inferred from the role name.
For secure implementations, verify that restricted records are not exposed through search results, account pages, URLs, browser requests, or custom extensions.
5. Publish and test configuration changes
SuiteCommerce storefront changes may require the relevant configuration to be saved, published, deployed, or otherwise promoted according to the implementation model. Follow the account’s established release process and record the version or deployment identifier.
Clear cache where the platform requires it, then test in a private browser session. Cached content can hide changes to navigation, configuration, customer status, or pricing. A successful administrator session does not prove that an anonymous shopper or logged-in B2B customer receives the same result.
Which SuiteCommerce preferences deserve the most attention?
The most important preferences are the ones that change customer eligibility, transaction accuracy, or operational workload.
Customer and registration preferences
Decide whether the storefront allows guest checkout, customer registration, account approval, password reset, and contact-based access. Define what happens when a new customer submits registration. Does the request create a customer record immediately, enter an approval queue, or require manual review?
Customer registration also affects duplicate records. If email addresses, company names, and contact records are not governed consistently, online registration can create duplicate customer data and inaccurate credit or pricing relationships.
Pricing and currency preferences
Confirm the default currency, customer currency behavior, price display format, tax-inclusive or tax-exclusive display, quantity pricing, and promotional precedence. For a multi-subsidiary account, verify whether the storefront uses the customer’s subsidiary, the website’s subsidiary, or another defined rule.
Test boundary conditions such as quantity breaks, expired promotions, conflicting discounts, and customers without an assigned price level. These tests reveal whether the storefront has a defined fallback or simply exposes a blank, default, or incorrect price.
Inventory and availability preferences
Define what “available” means. It might mean on-hand quantity, committed quantity excluded, future supply included, or availability at a particular location. The preference should match fulfillment policy, not merely the value that is easiest to display.
If the storefront accepts orders when inventory is low, test the sequence between product display, cart validation, checkout, and sales order creation. Inventory can change between those events. The order process needs a final validation point when overselling creates financial or service risk.
Checkout and order preferences
Review required fields, billing and shipping addresses, purchase order fields, terms, order notes, shipping selection, payment selection, tax calculation, and confirmation messaging. Confirm that every required checkout value maps to a valid NetSuite transaction field or approved custom field.
Checkout is also where front-end expectations meet back-office rules. A customer might be permitted to request a purchase order number, while the account’s credit policy still requires approval. Configure the workflow so that the storefront does not imply an immediately accepted order when NetSuite still needs to approve it.
Search and product presentation preferences
Search settings affect how customers find items, not just how products look. Review searchable fields, item visibility, facets, sorting, synonyms, category relationships, and handling for inactive or unavailable items.
Product data quality is part of configuration. If unit of measure, pack size, minimum order quantity, or lead time matters to purchasing decisions, expose it consistently and validate it against the item record. A visually polished product page that omits the sellable unit can still generate incorrect orders.
How should you test SuiteCommerce configuration?
Testing should follow customer journeys and operational outcomes rather than a list of isolated settings. At minimum, test anonymous browsing, customer login, registration, account access, product search, item detail, pricing, cart behavior, shipping, tax, payment, order confirmation, order visibility, and fulfillment status.
Use representative test records with deliberately different conditions. For example, test a customer with account-specific pricing, a customer in another currency, a customer without a price level, an item with limited inventory, and an item that is not available to the web store.
Record four results for every scenario:
What the customer should see
What the customer actually sees
Which NetSuite record or preference controls the result
Whether the resulting transaction is operationally correct
This method creates an audit trail that helps distinguish configuration defects from data defects. It also makes regression testing more efficient when a feature, bundle, script, or SuiteCommerce extension changes.
For custom behavior, use the supported extension architecture and follow the account’s SuiteScript standards. Our guide to SuiteCommerce development for secure NetSuite storefronts explains why configuration should remain the first choice when standard behavior meets the requirement, while extensions and SuiteScript should address clearly defined gaps.
Common configuration mistakes to avoid
The most damaging mistake is treating SuiteCommerce configuration as a visual storefront task. The storefront is an interface to customer, item, inventory, pricing, transaction, tax, payment, and fulfillment data. A setting that appears minor can alter the transaction created in NetSuite.
Avoid enabling features without documenting their business purpose. Avoid testing only with an administrator account. Avoid validating only the happy path. Avoid changing production preferences without a rollback plan. Also avoid using custom code to compensate for inaccurate item, customer, pricing, or inventory records.
Quote purchasing provides a useful example of why a preference needs a policy behind it. If quotes become purchasable, define who qualifies, how pricing is protected, whether inventory is revalidated, and when an approval step is required. Our article on safer controls for purchasable SuiteCommerce quotes covers that narrower decision in more detail.
When the configuration touches integrations, also confirm the transaction and status flow across systems. NetSuite integrations may use SuiteTalk REST or SOAP APIs, middleware, payment services, tax services, shipping platforms, or warehouse applications. A storefront preference is not complete until the downstream system handles the resulting value correctly. We provide more detail about NetSuite integration architecture and platform options for connected environments.
When should we get help with SuiteCommerce configuration?
Professional help is justified when feature dependencies are unclear, the account uses multiple subsidiaries or currencies, pricing is customer-specific, checkout includes approval logic, or custom extensions and integrations affect order processing.
The right engagement should begin with a configuration inventory and test plan, not an immediate request for custom development. A qualified team should be able to identify which requirement belongs in a native feature, website preference, SuiteCommerce Configuration record, workflow, SuiteScript extension, integration, data correction, or operating procedure.
If your SuiteCommerce setup needs a structured review, contact Versich to discuss the account’s features, preferences, dependencies, and release risks.
Conclusion
Enabling SuiteCommerce features and setting preferences is a dependency and governance exercise, not a collection of isolated checkboxes. Start with the business requirement, identify the NetSuite record and feature responsible for the behavior, configure the smallest suitable set of options, and test the result through the complete customer and transaction journey.
The most dependable setup uses a sandbox, documented feature dependencies, controlled permissions, explicit pricing and inventory rules, realistic checkout tests, and a repeatable release process. When native configuration does not meet a defined requirement, use supported extensions, workflows, SuiteScript, or integrations selectively. This keeps the storefront easier to maintain while ensuring that SuiteCommerce and NetSuite continue to represent the same commercial rules.
