Define the price that should reach the customer
A price synchronisation problem may involve the wrong base value, an incorrect currency, customer-specific pricing, a promotional override or stale presentation. The first task is to define the expected price in a precise context. “The ERP says £100” is incomplete if the storefront applies a different website scope, tax display or customer-group rule.
Midoriweb begins with one product, one storefront and one customer context. We record the source value, its meaning, the expected destination field and the final customer-facing amount. This makes it possible to identify where the values diverge rather than changing the visible price without understanding the integration.
Our ecommerce integrations service covers the interface design and diagnosis. For a promotion-specific discrepancy, the coupon guide addresses cart rules separately from the upstream product-price feed.
Establish ownership and scope
Document which system owns base prices, special prices, customer-specific prices and promotional rules. Not every store should send every price type through the same feed. If both Magento administrators and an ERP can overwrite the same field, define which change wins and how exceptions are managed.
Record the website or store context supported by the installed configuration. A value applied to one scope should not be assumed to update every storefront. Multi-currency presentation also needs a clear distinction between a source price, a converted amount and a manually maintained market price.
The integration specification should state whether values include or exclude tax and which system performs each calculation. The technical team should implement the business’s agreed treatment rather than infer it from a column name. Questions about the business’s tax obligations belong with its adviser; the integration still needs an unambiguous field definition.
Trace one product through the feed
Capture a redacted source record and the corresponding destination update for an affected SKU. Include the batch or event reference and timestamps. Check the actual payload rather than relying on what a dashboard displays after formatting.
Follow selection, transformation, delivery and application. A product may be omitted by an export filter, transformed incorrectly, rejected by validation or updated in an unintended scope. Each stage requires a different repair. A successful connection test proves very little about those data rules.
Compare a working product with a failing one. Differences in product type, price precision, attribute set or mapping can reveal why only part of the catalogue is affected. Keep the comparison small enough to explain every transformation.
Check decimal, currency and unit handling
Price values can be altered by formatting and data-type assumptions. A decimal separator intended for human display may not match the receiving API’s expected representation. A spreadsheet may round or reformat a value before the integration reads it. Record the machine-readable value at each boundary.
Confirm currency explicitly where the interface supports it, and document where conversion occurs. Applying conversion twice or omitting it entirely can produce a consistent but wrong result. Do not diagnose that solely from the displayed currency symbol; inspect the underlying values and transformation rules.
Unit pricing also matters. A source price for a pack, case or measured quantity needs an agreed relationship to the product sold online. The same SKU label does not guarantee the same unit of sale across every system.
Review effective dates and competing price sources
Scheduled or promotional prices can override a base price during a particular period. Record the intended start and end conditions and compare them with the store’s time context. A correct base-price update may appear ineffective because another valid rule still determines the customer-facing amount.
Customer groups, tier quantities and catalogue promotions can create legitimate differences. Test the exact customer and quantity context before concluding that the feed failed. A guest product page is not sufficient verification for a B2B customer-specific price.
If the integration clears fields when the source is blank, establish whether blank means “remove the override”, “leave unchanged” or “unknown”. Those meanings must not be conflated. A missing source value should not silently erase a deliberate Magento setting unless that behaviour is explicitly agreed.
Distinguish applied data from stale presentation
After confirming the destination data, inspect the relevant indexing and cache path. An update may be stored correctly but not yet reflected in a listing or product page. Conversely, a cached display may look correct while checkout evaluates a different effective value.
Use the indexer guide when processing is delayed and the cache guide when presentation evidence points there. Avoid repeated broad reindexing or cache flushing before establishing which layer is wrong.
Verification should include the product page, cart and relevant checkout totals. A repair that changes only the label while the order uses another amount does not meet the business requirement. Preserve the distinction between displayed price and final transaction values throughout the investigation.
Handle delayed and repeated updates safely
Price feeds may arrive out of order after outages or retries. Establish whether the integration can identify the effective version of a value and prevent an older update from replacing a newer one. A timestamp should have a documented meaning: source creation, effective date and delivery time are not interchangeable.
For partial batches, record per-product outcomes and identify the safe retry set. A broad rerun can overwrite legitimate later edits if the interface lacks version or ownership controls. Recovery needs to consider what happened after the original failed batch, not merely replay it unchanged.
Manual workarounds should be documented with a plan for the next scheduled feed. Otherwise an urgent price correction can disappear overnight, leaving the team to repeat the same intervention without addressing the source logic.
Verify boundaries and operational exceptions
Build a test set covering normal prices, special prices, different websites, relevant customer groups and the product types involved. Include empty or invalid input, rounding boundaries and a repeated update. Confirm that rejected data creates a visible exception instead of an unnoticed partial catalogue.
Use an authorised environment and agreed sample values. Do not publish unrealistic live prices simply to exercise the integration. If a production check is necessary, scope it carefully and verify the customer-facing state immediately afterwards.
After the correction, observe the next normal update cycle and compare the reconciled sample again. Monitoring should identify missing feeds, rejected records and unexpected changes without requiring staff to inspect every product manually.
Midoriweb’s approach to pricing integrations
A useful outcome is a documented mapping, a reproducible failure example and a correction that preserves the agreed ownership and price rules. We would separate transport reliability from pricing semantics so that a technically successful API call is not mistaken for a correct commercial result.
Our ERP integration work can help align finance, merchandising and ecommerce requirements. Provide the source system, affected price type, example SKU, storefront context and recent changes in the initial brief. Sensitive price files and access credentials can then be handled through the agreed private process.
Price-sync questions
Why does the product page differ from the cart?
Compare customer context, quantity, effective price rules and processing state. The two displays may be using different conditions or one may be stale.
Should a feed overwrite manual edits?
Only according to the agreed ownership rule. The integration should make that behaviour explicit and provide a controlled exception process.
Does resending the latest file fix the cause?
It may repair selected values temporarily, but mapping, ordering and processing faults can recreate the discrepancy on the next cycle.