Hi everyone,

I want to share a more robust, maintainable approach for applying custom prices (like Floor Sample pricing) in Optimizely Commerce.

Why directly setting PlacedPrice is fragile

Previous code:

lineItem.PlacedPrice = floorSamplePrice;
_cartRepository.SaveCart(cart);

It works - but I found few drawbacks:

• If the cart is recalculated (promotions applied, taxes, shipping, quantities changed), the overridden price may be overwritten or ignored.

• Promotion engine, discounts, price adjustments expect pricing to come from the catalog/price service, so customizing price this way can lead to unexpected results.

• Future upgrades or changes to pricing logic might break your custom override.

Recommended Pattern: Use a Custom Price Processor

Instead of manually setting PlacedPrice, a better pattern is:

• Store your custom price in a custom line-item property (e.g. FloorSamplePrice)

• Implement a custom IPlacedPriceProcessor that inspects that property and, when present, applies it as the placed price.

• Let the rest of the Commerce pricing pipelines (promotions, taxes, recalculation) work as normal — now they will operate with your custom price as the base.

Example Implementation:

[ServiceConfiguration(typeof(IPlacedPriceProcessor))]
public class FloorSamplePriceProcessor : DefaultPlacedPriceProcessor
{
    public override void ApplyPlacedPrice(
        IOrderGroup orderGroup,
        IOrderForm orderForm,
        ILineItem lineItem,
        IMarket market)
    {
        // If our custom price is provided, use it
        if (lineItem.Properties["FloorSamplePrice"] is string custom &&
            decimal.TryParse(custom, out var floorPrice))
        {
            lineItem.PlacedPrice = floorPrice;
        }
        else
        {
            // fallback to standard pricing logic
            base.ApplyPlacedPrice(orderGroup, orderForm, lineItem, market);
        }
    }
}

When adding to cart:

lineItem.Properties["FloorSamplePrice"] = floorSamplePrice.ToString();
_cartRepository.SaveCart(cart);

With that:

• Custom price becomes part of the standard pricing pipeline — so discounts, promotions, taxes, shipping, and all calculations respect it.
• If a line item doesn’t need custom pricing, default behavior remains unchanged.

This pattern aligns with how Optimizely Commerce expects custom pricing to be handled (via custom pricing providers / price processors).

If anyone else has implemented a similar pattern (customer-specific pricing, ERP-driven price feeds, display-sample pricing, etc.), I’d love to hear your feedback or lessons learned.