This article reflects Amazon's SP-API (the old MWS is retired) and PrestaShop 8/9 back-office paths. Disclosure: we build PrestaShop modules at mypresta.rocks.
You have already decided to sell on Amazon. That is the harder strategic question. Whether a marketplace is worth the fees and the loss of the customer relationship at all, and we work through it in marketplace vs own store. This guide is the part that comes after: the mechanics of running Amazon alongside a PrestaShop store without the two fighting each other. Most multi-channel pain is not strategic, it is plumbing. Stock that drifts out of sync, orders that live in two places, prices that contradict each other. Get the plumbing right and Amazon becomes a second storefront feeding the same catalogue. Get it wrong and you oversell, your Amazon account health drops, and you spend your evenings reconciling spreadsheets.
So the question this guide answers is narrow and concrete: how do you wire Amazon and PrestaShop together so one catalogue drives both, orders land in one back office, and stock never lies?
The one decision that shapes everything: where the catalogue lives
Before any sync, decide which system is the source of truth for products and stock. For a merchant who already runs PrestaShop, the answer is almost always PrestaShop is the master: your catalogue, your combinations, your stock quantities managed on the Catalog → Stocks page (or the per-product quantity field on each product) drive Amazon, and Amazon orders flow back to deduct from the same pool. The alternative, managing each channel by hand, only holds up at a tiny scale, and the moment it breaks it breaks expensively.
So what does "PrestaShop is master" buy you? One place to change a price, one place to read true stock, and one warehouse workflow for your team regardless of where the order came from. That single rule removes most of the contradictions that make multi-channel painful.
Three ways to connect the two, and where each breaks
| Approach | How stock stays in sync | Effort | Holds up until… |
|---|---|---|---|
| Manual | You update both Seller Central and PrestaShop by hand | Low to set up, high forever after | ~50 SKUs / low order volume, then you oversell |
| Feed / CSV upload | Scheduled export from PrestaShop, transformed to Amazon's flat-file template, uploaded via SP-API | Medium. Needs a cron job and a transform script | Stock latency between runs becomes the bottleneck |
| Integration module | A PrestaShop module talks to the SP-API directly: pushes listings/stock, pulls orders | Install and configure | Scales with you; the right long-term answer for most stores |
The dividing line is latency. Manual sync has a latency of "whenever you remember." A feed has the latency of your cron interval, fine for slow movers, dangerous for anything that sells several units an hour, because every minute between the real sale and the stock update is a window where the other channel can sell something you no longer have.
The thing every integration is built on: the SP-API
Whatever route you pick beyond manual, it talks to Amazon through the Selling Partner API (SP-API). This matters even if you never touch code, because it is the single most important compatibility question when you evaluate any Amazon module or service:
- Amazon retired the old MWS (Marketplace Web Services) in favour of SP-API. Any module or script still built on MWS is dead weight. It will not authenticate. When you shortlist a module, "SP-API native" is a hard requirement, not a nice-to-have.
- SP-API uses LWA (Login with Amazon) OAuth authorisation rather than the old static keys. In practice you authorise the app once from your Seller Central account and the integration holds a refresh token, so when a tool asks you to "connect your Amazon account" and bounces you through an Amazon consent screen, that is SP-API doing its job correctly.
- SP-API is rate-limited per endpoint. This is why no honest integration offers truly instant, per-second stock pushes for thousands of SKUs, it batches updates within Amazon's quotas. A vendor promising "real-time everything, unlimited" is either misusing the word or about to get your calls throttled.
You do not need to implement any of this yourself. You need to recognise it, so that when you compare options you are comparing the same modern foundation rather than paying for a tool quietly running on a deprecated one.
Getting Amazon orders into the PrestaShop back office
This is the half of multi-channel that pays off daily, and it is worth understanding mechanically because it is also where a sloppy integration shows. The goal: an Amazon order should appear in Orders → Orders like any other, so your warehouse team picks, packs and ships from one screen and never logs into Seller Central for routine fulfilment.
How a clean order import actually works
A well-built integration polls the SP-API Orders endpoint on a short interval and, for each new Amazon order, creates a native PrestaShop Order with its associated objects, a Customer, an Address, and order rows mapped to your real products by SKU. A few details separate a good import from one that makes a mess:
- SKU mapping is the linchpin. Amazon's Seller SKU has to map to your PrestaShop product reference (or combination reference). If that mapping is loose, the order imports against the wrong product and your stock deducts from the wrong line. Decide your SKU convention up front and keep Amazon's Seller SKU identical to your PrestaShop reference wherever you can.
- A dedicated order status. Create a custom status under Shop Parameters → Order Settings → Statuses, something like "Amazon, to ship". This keeps marketplace orders visually distinct, lets you filter them, and stops them triggering your normal PrestaShop order-confirmation emails to a customer Amazon does not let you email anyway.
- Stock deducts once, from the master pool. Because PrestaShop is master, the imported order decrements the same quantity your Amazon listing reads from. That closing of the loop is the whole point. It is what prevents the channels from overselling each other.
- Tracking flows back. When you ship and enter the carrier and tracking number on the PrestaShop order, the integration pushes it to Amazon via the SP-API so the buyer sees fulfilment and your Valid Tracking Rate stays healthy. Without this, you are entering tracking twice and inviting transcription errors.
Why "send it to the back office" beats living in Seller Central
Centralising orders is not tidiness for its own sake. It gives you one stock deduction across every channel, one fulfilment workflow your staff already know, and combined reporting where Amazon revenue sits next to direct revenue instead of in a separate silo you have to mentally bolt on at month-end.
The compliance line you cannot cross: Amazon customer data
Once Amazon orders land in PrestaShop, there is a tempting button you must not press. Amazon's terms prohibit using order-derived customer data for your own marketing. Do not import Amazon buyers into your newsletter list, do not retarget them, do not email them to "come buy direct next time." Amazon monitors for exactly this and suspends sellers who do it. Practically, this means your integration should bring orders in for fulfilment but keep those customers out of any marketing segment. If you run an abandoned-cart or newsletter flow on PrestaShop, make sure Amazon-sourced customers are excluded by status or group, a small configuration step that protects your selling account.
Pricing across two channels without undercutting yourself
Your PrestaShop price and your Amazon price do not have to be identical, but the relationship between them has one hard rule and a couple of judgement calls.
The hard rule: never price Amazon below your own store. If a customer who found you directly can pay less on Amazon, you have trained them to buy through the channel that takes a cut and hides their email from you, undermining the very store you own. Amazon as the cheaper option is self-sabotage.
Beyond that, you have room to manoeuvre:
- Match prices for consistency and trust. Your Amazon margin is thinner because of the referral fee, but you avoid the channel conflict that erodes customer trust when prices disagree.
- Price Amazon slightly higher to recover the referral fee, workable for products where you face little price competition, riskier where the Buy Box is contested.
- Run channel-exclusive promotions instead of cross-channel discounts: a bundle or free-shipping offer that lives only on your PrestaShop store gives direct buyers a reason to come to you without the two channels visibly contradicting each other. PrestaShop's Catalog → Discounts (Cart Rules and Catalog Price Rules) is where you build those store-only offers.
The deeper question of whether marketplace economics work for your margins at all belongs to the strategic side, again, marketplace vs own store covers the fee math.
Fulfilment: FBA, FBM, and the hybrid most PrestaShop merchants land on
Fulfilment choice changes how stock flows, which is why it belongs in an integration guide and not just a strategy one.
- FBA (Fulfilment by Amazon): you ship inventory to Amazon, they store, pack and ship it, and it carries the Prime badge. The catch for sync is that FBA stock physically sits in Amazon's warehouses, so your PrestaShop "master" quantity has to account for units committed to Amazon separately from units in your own warehouse, or your direct store will try to sell stock it does not physically hold.
- FBM (Fulfilment by Merchant): you ship from your own warehouse. Stock is genuinely one pool, which makes sync conceptually simpler, every order, Amazon or direct, draws from the same shelf. No Prime badge unless you qualify for Seller Fulfilled Prime.
- The hybrid most merchants settle on: FBA for the top sellers that benefit most from the Prime badge and velocity, FBM for the long tail where Amazon storage fees would eat the margin. This keeps fast movers visible and slow movers cheap to hold, but it does mean your integration needs to know which products are fulfilled which way, because the two have different stock realities.
The metrics that make tight stock sync non-negotiable
Amazon scores seller performance continuously, and several of those scores are downstream of your sync quality:
- Order Defect Rate, kept under Amazon's threshold partly by not cancelling orders you cannot fulfil.
- Cancellation Rate, the one stock-sync failure hits hardest. Oversell on Amazon because PrestaShop sold the last unit and did not update the listing in time, and you are forced to cancel, directly raising this rate.
- Late Shipment Rate and Valid Tracking Rate, both protected when tracking flows back automatically from the PrestaShop order rather than being keyed in late and by hand.
The point is blunt: a stock-sync gap is not a tidiness problem, it is an account-health problem. Repeated oversell-driven cancellations can suspend a selling account. That is why "good enough most of the time" sync is a false economy on a fast-moving catalogue.
The multi-channel stack on the PrestaShop side
A working setup is a handful of pieces doing one job each. On PrestaShop, the components that matter are:
- The catalogue as the single source of truth for products, combinations and stock.
- The Amazon integration (SP-API) syncing listings and stock out, and pulling orders in.
- A multi-carrier shipping setup in Shipping → Carriers so FBM and direct orders both get correct rates and labels.
- Order status and segmentation so Amazon orders are visibly tagged and kept out of marketing flows.
- Clean accounting separation so referral fees, FBA fees and channel revenue are distinguishable at month-end.
Where we fit: at mypresta.rocks we build the PrestaShop-side modules around this stack, the SEO tooling that grows the direct channel you actually own, and the checkout work that converts the visitors who, having met your brand on Amazon, eventually search for you and land on your own store. The benefit framing is deliberate: Amazon buys you discovery and volume; the modules on your own store are what turn that borrowed audience into customers whose relationship, and full margin, belong to you.
Don't let Amazon become the whole business
One closing operational caution that is really a structural one. The deeper Amazon goes into your revenue mix, the more a single Amazon policy or fee change can knock the whole operation sideways. Keep the marketplace as a feeder for the store you own, not a replacement for it. Which is exactly why the integration questions above all bend toward keeping PrestaShop as master and your customer relationships on your side of the line. If you are weighing how much to lean on marketplaces at all, that trade-off is the subject of marketplace vs own store; and if part of the appeal of Amazon was simply "people trust it more than my unknown shop," the honest comparison of where a hosted marketplace genuinely wins is in where Shopify wins, the same trust-transfer logic, looked at squarely.
A realistic first month
- Week 1, foundation. Open an Amazon Professional seller account (the per-item Individual plan only makes sense below ~40 sales a month and locks you out of bulk tools). Confirm PrestaShop is your source of truth and that your product references line up with the Seller SKUs you will use.
- Week 2, connect and map. Stand up your SP-API integration, map a small set of best-selling SKUs, and create the "Amazon, to ship" order status. Verify stock pushes out and a test order pulls in and deducts correctly before you scale.
- Week 3, fulfilment. Decide FBA vs FBM per product. If FBA, send your first shipment and make sure your master stock accounts for the units now sitting in Amazon's warehouse.
- Week 4. Go live and watch the gauges. List the rest of your initial range and watch sync accuracy and your Amazon metrics daily for the first weeks. The infrastructure month is about proving the loop closes, orders in, stock down, tracking back, not about volume.
Multi-channel selling done well is unglamorous: one catalogue, one back office, stock that tells the truth, and a clean line between the customers Amazon lets you keep and the ones it does not. Get that right and Amazon is a second storefront on top of the store you own. Which, in the end, is the only one that is fully yours.
Common questions about Amazon and PrestaShop
Should PrestaShop or Amazon be the source of truth for stock?
For a merchant who already runs PrestaShop, PrestaShop should be the master almost every time. Your catalogue, combinations and stock quantities drive Amazon, and Amazon orders flow back to deduct from the same pool. That single rule, one place to change a price, one place to read true stock, one warehouse workflow regardless of where the order came from, removes most of the contradictions that make multi-channel painful. Managing each channel by hand only holds up at tiny scale, and it breaks expensively.
Do I still need an MWS module, or must it be SP-API?
SP-API, full stop. Amazon retired the old MWS (Marketplace Web Services), so any module or script still built on it is dead weight, it won't authenticate. When you shortlist an Amazon integration, "SP-API native" is a hard requirement, not a nice-to-have. SP-API also uses Login with Amazon OAuth rather than static keys, so when a tool bounces you through an Amazon consent screen to "connect your account," that's it working correctly.
Can a module really sync thousands of SKUs in real time?
Not truly per-second, and a vendor promising "real-time everything, unlimited" is either misusing the word or about to get throttled. SP-API is rate-limited per endpoint, so honest integrations batch updates within Amazon's quotas. What you want is low, predictable latency and event-driven pushes off PrestaShop's stock changes, fast enough that the window for overselling stays small, not a literal instant guarantee that the API won't allow anyway.
Why does stock sync matter so much for my Amazon account, not just tidiness?
Because Amazon scores seller performance continuously and several scores are downstream of sync quality. Oversell because PrestaShop sold the last unit and the listing didn't update in time, and you're forced to cancel, which directly raises your Cancellation Rate and Order Defect Rate. Tracking that flows back automatically protects your Late Shipment Rate and Valid Tracking Rate. Repeated oversell-driven cancellations can suspend a selling account, which is why "good enough most of the time" sync is a false economy on a fast catalogue.
Should my Amazon price match my PrestaShop price?
The one hard rule: never price Amazon below your own store, or you train customers to buy through the channel that takes a cut and hides their email. Above that floor you have room, match prices for trust, price Amazon slightly higher to recover the referral fee where competition is light, or run channel-exclusive promotions (a bundle or free-shipping offer built with PrestaShop's Catalog → Discounts) so direct buyers get a reason to come to you without the two channels visibly contradicting each other.
Keep reading
- Marketplace vs own store, the strategy and fee math behind whether to sell on Amazon at all.
- Why owning your code matters, why PrestaShop stays the asset and Amazon stays the feeder.
- Why we chose PrestaShop, the platform reasoning behind the modules in this stack.