When a customer sees a higher price crossed out beside a lower price, they assume the difference represents a real, available saving. In SuiteCommerce, strike-through pricing should display a valid reference price, the active selling price, and the pricing rule that produced the difference. The reference price should come from an approved NetSuite price source, while the sale price should reflect the authenticated customer, quantity, currency, promotions, and effective dates. The cart and checkout must validate the same pricing logic before an order is submitted. A front-end-only comparison is not enough because it can show a discount that NetSuite will not honor.
A reliable implementation separates price presentation from price authority. SuiteCommerce can present the original and current prices through a storefront extension, but NetSuite should remain the system of record for item pricing, customer-specific prices, quantity breaks, promotions, and transaction totals. This prevents a crossed-out price from becoming a decorative label that does not match the actual sales order.
What is SuiteCommerce strike-through pricing?
SuiteCommerce strike-through pricing is the storefront pattern that displays a reference price with a line through it next to a lower active price. It is also called sale pricing, compare-at pricing, was-now pricing, or promotional price display.
A typical product card might show:
Original price: $120.00
Current price: $99.00
Saving: $21.00
The visual treatment is simple, but the underlying decision is not. SuiteCommerce must determine which price qualifies as the reference price and which price represents the amount the customer can actually pay.
The reference price could be a standard item price, a list price, a customer price before promotion, or another approved commercial baseline. Those options are not interchangeable. A customer-specific contract price should not automatically be crossed out as if it were a public list price. Likewise, a quantity break should not be presented as an unconditional sale price when the customer must purchase a specific quantity to qualify.
The most important rule is this: only show a strike-through price when the two prices are comparable, valid for the same customer context, and supported by a real pricing rule.
How should SuiteCommerce calculate the original and sale prices?
SuiteCommerce should calculate the active price first, identify its source, and then select a reference price under an explicit business policy. Do not calculate the crossed-out amount by simply adding a percentage to the displayed selling price.
For example, if a customer receives a 10% contract discount, the pre-discount price might be a valid reference price. If the customer receives a negotiated unit price that is already below the standard price, the storefront needs a defined policy for whether that standard price may be displayed. The answer depends on the commercial agreement and how the business communicates pricing to that customer group.
A sound pricing model records or derives the following attributes:
| Pricing attribute | Why it matters |
|---|---|
| Active price | The amount the current customer is eligible to pay |
| Reference price | The approved amount used for comparison |
| Price source | Standard price, customer price, quantity break, promotion, or custom rule |
| Currency | Prevents comparisons between values from different currencies |
| Quantity threshold | Shows whether the lower amount requires a specific purchase quantity |
| Effective dates | Prevents expired or future prices from appearing as current |
| Eligibility | Determines whether the customer, segment, or account qualifies |
| Display policy | Controls whether the reference price may be shown publicly or privately |
This structure is particularly important in B2B catalogs. A logged-in account may receive a customer-specific price that should not be compared with a public list price. Another account may have a contract with fixed pricing and no promotional eligibility. The storefront needs to distinguish those cases rather than applying one universal strike-through rule.
For more complex rules, we recommend storing the pricing inputs in governed NetSuite records rather than embedding every condition in a front-end script. Custom records can hold customer or customer-group eligibility, item or item-group scope, currency, quantity minimums, unit prices, validity periods, priority, and approval state. This gives administrators a way to audit and expire pricing rules without editing storefront code.
Our guide on SuiteCommerce dynamic pricing with SuiteScript for B2B catalogs covers the broader pricing authority and server-side rule model. The distinction is important here: that guide addresses how dynamic prices are determined, while this article focuses on how an approved price comparison should be exposed without misleading the shopper.
Which NetSuite price should appear as the crossed-out price?
The correct reference price depends on the pricing policy, but the choice must be deliberate. NetSuite's standard pricing features should be the first place to look because they provide a more maintainable foundation than duplicated custom values.
Common reference-price policies include:
Standard price compared with an active promotion. This is the clearest model for a general sale. The standard price is the baseline, and a valid promotion lowers the current price for eligible shoppers.
Standard price compared with a customer-specific discount. This approach works when the business wants logged-in customers to see the value of their account pricing. The display must make clear that the lower price is account-specific if anonymous shoppers see a different amount.
Higher quantity price compared with the current unit price. This should only appear when the quantity requirement is visible and enforceable. Showing a lower unit price at quantity one creates an inaccurate expectation.
Previous approved price compared with a new temporary price. This approach requires effective dates and a reliable record of the prior price. It should not rely on a stale value cached in a product template.
Manufacturer suggested retail price compared with the selling price. This is appropriate only when the business has the right to use that reference and the value is maintained accurately. It should not be confused with the seller's own former price.
NetSuite promotions introduce additional complexity because the discount might apply to a price level, a quantity break, a customer-specific rate, or a combination of conditions. A promotion that discounts a customer-specific price does not necessarily produce the same saving as a promotion applied to the standard item price. SuiteCommerce must know which base amount the promotion uses before displaying a comparison.
When the pricing source is ambiguous, suppress the strike-through display. A single accurate current price is better than a dramatic but unsupported saving claim.
How do you implement strike-through pricing in SuiteCommerce?
A dependable implementation uses a controlled data flow from NetSuite to SuiteCommerce and back to NetSuite during transaction processing. The storefront should not invent an original price after receiving only a final selling price.
The implementation normally follows this sequence:
Define the reference-price policy. Decide whether the reference is a standard price, prior approved price, customer price before promotion, or another governed value. Define separate rules for public shoppers, logged-in accounts, quantity pricing, currencies, and promotions.
Identify the authoritative NetSuite data. Determine which price levels, promotion records, custom records, item fields, or SuiteScript calculations provide the active and reference values. Avoid creating a second pricing database that can drift from NetSuite.
Return display-ready pricing data. The SuiteCommerce data layer should return enough information for the storefront to render the price correctly. That might include the active amount, reference amount, currency, eligibility state, quantity threshold, and display label. Returning only two numbers leaves the presentation layer unable to explain why the comparison exists.
Render the comparison through a maintainable extension. A SuiteCommerce extension can add the crossed-out amount, current price, saving message, and qualifying condition to product details, search results, and other relevant views. Keep the presentation logic separate from the pricing calculation.
Validate the cart and checkout. Recalculate or validate the price when the item enters the cart, when quantity changes, when the customer signs in, and when the order proceeds through checkout. Product-page data is not proof that the final transaction will accept the same price.
Test price transitions. Test anonymous and authenticated shoppers, different currencies, quantity thresholds, expired promotions, mixed carts, unavailable items, and changes in customer context. A price display that works on the product page but changes after login is a pricing transition defect, not merely a visual issue.
The browser should receive only the information needed to present the approved result. Sensitive contract terms, internal margin data, and private pricing logic should remain protected on the server. A public shopper should not be able to inspect an endpoint and retrieve every customer segment's price schedule.
What causes incorrect sale-price displays?
Incorrect strike-through pricing usually comes from a mismatch between the reference price, the current price, and the point at which each value was calculated.
A stale reference price appears when a product page or cache preserves an old list price after NetSuite changes it. The current price may be correct while the crossed-out price is no longer valid.
A customer-context mismatch occurs when the storefront loads a public reference price and then applies a private account price without refreshing the comparison. The result suggests a public saving that may not exist for every shopper.
A quantity mismatch occurs when the lower price applies at 10 units but the storefront shows it beside the unit price at quantity one. The display needs to communicate the threshold or wait until the shopper qualifies.
A promotion stacking error happens when the storefront compares a promotional price with a base price that does not match NetSuite's promotion sequence. Percentage discounts, fixed-amount discounts, price levels, and quantity breaks can produce different results depending on the order of calculation.
A currency mismatch occurs when a reference amount is converted or formatted differently from the active amount. Currency conversion, rounding precision, and tax display settings should be consistent before the comparison is shown.
A cache segmentation failure exposes one customer's pricing result to another shopper. Personalized prices require cache controls that vary by customer identity, session state, currency, and other pricing inputs.
A front-end-only discount shows a lower number without creating a valid transaction price. This is the most serious failure because the shopper sees one offer while the sales order records another amount.
Each failure points to the same architectural lesson: strike-through pricing is not an isolated template change. It is the visible outcome of a pricing decision that must remain consistent across the product page, cart, checkout, and NetSuite transaction.
How should strike-through prices behave in the cart and checkout?
The cart and checkout should confirm the pricing result rather than blindly repeat what the product page displayed. Quantity changes, customer login, shipping destination, currency, promotion codes, and inventory conditions can all affect eligibility.
At minimum, the cart should refresh the active price when a quantity crosses a pricing threshold. If the customer moves from nine units to ten, the current unit price may change. The strike-through price should update at the same time, and the interface should make the qualification condition visible.
When a shopper signs in, SuiteCommerce should re-evaluate account-specific pricing. It should not retain an anonymous shopper's reference price while replacing only the active price. Both values need to be evaluated in the same customer context.
Checkout also needs transaction-level validation. NetSuite should reject or recalculate a price when the submitted line does not satisfy the relevant promotion, price level, quantity rule, effective date, or customer eligibility condition. If the visible saving disappears at checkout, the system should explain the reason and present the valid amount clearly.
A useful audit record captures the item, customer classification, quantity, currency, active price source, reference price source, promotion or rule identifier, pricing version, and correlation ID. A correlation ID helps connect the browser request, SuiteScript execution, and resulting sales order during troubleshooting without exposing private pricing details to the shopper.
Is SuiteScript required for SuiteCommerce strike-through pricing?
SuiteScript is not required for every strike-through display. Standard NetSuite pricing and promotion features are sufficient when the requirement fits supported price levels, customer-specific item pricing, quantity pricing, currencies, and promotions.
Custom SuiteScript becomes appropriate when the reference price depends on a rule that standard pricing does not represent cleanly. Examples include an approved contract table, a date-based entitlement, an account hierarchy, a custom minimum quantity, or a price authorization supplied by an external system.
The right implementation uses SuiteScript to fill a genuine gap, not to duplicate standard prices in a custom record. If NetSuite already maintains the value, custom code should retrieve or extend that logic rather than create a competing source of truth.
SuiteCommerce extensions are useful for presentation and interaction, while server-side SuiteScript or supported NetSuite pricing features should control sensitive decisions. This division makes the system easier to test and reduces the risk that a browser-side change creates an unauthorized discount.
If pricing depends on another platform, integration architecture also matters. The NetSuite Integration Platform can support data exchange through NetSuite APIs and integration workflows, but an external price feed still needs ownership, effective-date handling, failure behavior, and transaction validation. A synchronized price is not automatically an authorized price.
How should you test strike-through pricing before launch?
Testing should use pricing scenarios, not only visual screenshots. A page can look correct at one quantity and still fail as soon as customer context or promotion order changes.
Build a test matrix covering:
Anonymous shoppers and authenticated customers
Customers with standard, customer-specific, and contract pricing
Items with no discount, active promotions, and expired promotions
Quantities below, at, and above every break
Multiple currencies and configured rounding rules
Product pages, search results, quick views, cart, and checkout
Login, logout, customer switching, and session refresh
Promotion codes combined with quantity or account pricing
Cached pages and repeated requests from different customer contexts
Sales orders created from each qualifying and non-qualifying scenario
The acceptance test should compare the storefront result with the NetSuite result, not just confirm that a line appears through the price. Record the expected reference price, active price, qualification conditions, and final transaction amount for each scenario.
Also test failure states. If the pricing service times out, a promotion expires during checkout, or a custom record is incomplete, the system should fall back to a safe current price or display an understandable error. It should never manufacture a crossed-out price from incomplete data.
What should the strike-through display say?
The label should explain the pricing relationship without overstating the saving. “Was” and “Now” are clear when the reference price represents a genuine former price. “List price” and “Your price” are more appropriate when the comparison is between a standard amount and a private account price.
The interface should also disclose conditions that change eligibility. A quantity-based price needs a threshold such as “when you buy 10 or more.” A customer-specific amount should communicate that it applies to the signed-in account. A promotion may need an expiration date or code requirement.
Do not show a percentage saving if rounding makes the result materially different from the displayed dollar saving. Calculate the saving from the same unrounded values used by the pricing engine, then apply the storefront's approved display precision. Otherwise, the percentage and currency amounts can contradict each other.
Accessibility matters as well. Do not communicate the discount through color or a visual line alone. The accessible text should identify the original amount, current amount, currency, and any qualification condition. Search results and product cards need the same semantic information as the full product page.
How much does SuiteCommerce pricing customization cost?
The cost depends on the pricing model, not simply on adding a line through a price. A straightforward display using existing NetSuite price and promotion data requires less work than a customer-specific comparison with quantity breaks, contract records, external integrations, and transaction validation.
The main cost drivers are the number of pricing sources, the complexity of precedence rules, the number of storefront locations that need the display, cache and session requirements, integration dependencies, and the depth of testing required. Governance also matters because administrators need a way to approve, schedule, audit, and retire reference prices.
Before estimating, document the pricing authority and write representative scenarios. That reveals whether the project is a presentation change, a pricing-engine extension, a data-model change, or a combination of all three. We can help review the requirement through our contact page.
Conclusion
SuiteCommerce strike-through pricing should communicate a verified commercial comparison, not merely decorate a product card. NetSuite should remain the pricing authority, with standard price levels and promotions used wherever they fit and SuiteScript or governed custom records added only for genuine gaps.
The implementation should define the reference-price policy, preserve customer and quantity context, separate pricing decisions from storefront presentation, control personalized caching, and validate every result through checkout and the final sales order. When those controls are in place, the crossed-out price becomes a trustworthy explanation of value rather than a source of customer confusion, margin leakage, or transaction errors.
