Amazon y PrestaShop: guía de venta multicanal

Refleja la SP-API de Amazon (el antiguo MWS ya está retirado) y las rutas del back office de PrestaShop 8/9. Aviso: desarrollamos módulos de PrestaShop en mypresta.rocks.

Ya has decidido vender en Amazon. Esa es la pregunta estratégica más difícil, si un marketplace merece las comisiones y la pérdida de la relación directa con el cliente, y la analizamos en marketplace frente a tienda propia. Esta guía trata de lo que viene después: la mecánica de gestionar Amazon junto con una tienda PrestaShop sin que ambos canales se estorben. La mayor parte del dolor multicanal no es estratégico, sino operativo: existencias que dejan de estar sincronizadas, pedidos que viven en dos sitios, precios que se contradicen. Si esa base operativa está bien resuelta, Amazon se convierte en un segundo escaparate alimentado por el mismo catálogo. Si está mal resuelta, venderás por encima de tus existencias, la salud de tu cuenta de Amazon caerá y pasarás las tardes conciliando hojas de cálculo.

Así que la pregunta que responde esta guía es concreta y acotada: ¿cómo conectas Amazon y PrestaShop para que un solo catálogo alimente ambos canales, los pedidos lleguen a un único back office y el stock nunca mienta?

La decisión que lo condiciona todo: dónde vive el catálogo

Antes de cualquier sincronización, decide qué sistema será la fuente de verdad para productos y stock. Para un comerciante que ya trabaja con PrestaShop, la respuesta casi siempre es PrestaShop manda: tu catálogo, tus combinaciones y tus cantidades de stock gestionadas en la página Catálogo → Existencias (o en el campo de cantidad de cada producto) alimentan Amazon, y los pedidos de Amazon vuelven para descontarse del mismo fondo común. La alternativa, gestionar cada canal a mano, solo aguanta a una escala muy pequeña, y cuando se rompe, se rompe caro.

¿Qué te aporta entonces que "PrestaShop mande"? Un único lugar para cambiar un precio, un único lugar para consultar el stock real y un único flujo de almacén para tu equipo, venga de donde venga el pedido. Esa regla elimina la mayoría de las contradicciones que hacen dolorosa la venta multicanal.

Tres formas de conectar ambos sistemas, y dónde falla cada una

La línea divisoria es la latencia. La sincronización manual tiene una latencia de "cuando te acuerdes". Un feed tiene la latencia del intervalo de tu cron: aceptable para productos de rotación lenta, peligroso para cualquier cosa que venda varias unidades por hora, porque cada minuto entre la venta real y la actualización de stock es una ventana en la que el otro canal puede vender algo que ya no tienes.

La base de cualquier integración: la SP-API

Elijas la vía que elijas más allá de lo manual, se comunica con Amazon a través de la Selling Partner API (SP-API). Esto importa aunque nunca toques código, porque es la pregunta de compatibilidad más importante al evaluar cualquier módulo o servicio para Amazon:

• Amazon retiró el antiguo MWS (Marketplace Web Services) en favor de la SP-API. Cualquier módulo o script que siga basado en MWS es peso muerto: no se autenticará. Cuando hagas una lista corta de módulos, que sea "nativo de SP-API" es un requisito imprescindible, no un extra interesante.
• La SP-API utiliza autorización LWA (Login with Amazon) OAuth en lugar de las antiguas claves estáticas. En la práctica, autorizas la aplicación una vez desde tu cuenta de Seller Central y la integración conserva un token de actualización; por eso, cuando una herramienta te pide "conectar tu cuenta de Amazon" y te lleva a una pantalla de consentimiento de Amazon, la SP-API está haciendo correctamente su trabajo.
• La SP-API tiene límites de frecuencia por endpoint. Por eso ninguna integración honesta ofrece envíos de stock realmente instantáneos, segundo a segundo, para miles de SKU: agrupa las actualizaciones dentro de las cuotas de Amazon. Un proveedor que promete "todo en tiempo real, sin límites" está usando mal las palabras o está a punto de hacer que Amazon limite tus llamadas.

No necesitas implementar nada de esto tú mismo. Necesitas reconocerlo para que, al comparar opciones, estés comparando la misma base moderna en vez de pagar por una herramienta que funciona discretamente sobre una tecnología obsoleta.

Cómo llevar los pedidos de Amazon al back office de PrestaShop

Esta es la mitad de la venta multicanal que compensa todos los días, y merece la pena entenderla de forma mecánica porque también es donde se nota una integración descuidada. El objetivo: un pedido de Amazon debe aparecer en Pedidos → Pedidos como cualquier otro, para que tu equipo de almacén prepare, embale y envíe desde una sola pantalla y no tenga que entrar en Seller Central para la gestión rutinaria de envíos.

Cómo funciona realmente una importación de pedidos bien hecha

Una integración bien construida consulta el endpoint Orders de la SP-API a intervalos cortos y, por cada nuevo pedido de Amazon, crea un Pedido nativo de PrestaShop con sus objetos asociados: un Cliente, una Dirección y líneas de pedido asignadas a tus productos reales por SKU. Algunos detalles separan una buena importación de una que deja el sistema hecho un lío:

• El mapeo de SKU es la pieza clave. El Seller SKU de Amazon debe corresponderse con la referencia de producto de PrestaShop (o con la referencia de combinación). Si ese mapeo es impreciso, el pedido se importa contra el producto equivocado y el stock se descuenta de la línea incorrecta. Decide tu convención de SKU desde el principio y mantén el Seller SKU de Amazon idéntico a tu referencia de PrestaShop siempre que puedas.
• Un estado de pedido dedicado. Crea un estado personalizado en Parámetros de la tienda → Configuración de pedidos → Estados, algo como "Amazon, por enviar". Esto hace que los pedidos del marketplace se distingan visualmente, te permite filtrarlos e impide que disparen los emails normales de confirmación de pedido de PrestaShop a un cliente al que Amazon, en cualquier caso, no te permite escribir.
• El stock se descuenta una sola vez, del fondo común maestro. Como PrestaShop manda, el pedido importado reduce la misma cantidad que lee tu listing de Amazon. Cerrar ese círculo es todo el objetivo: es lo que evita que los canales se vendan por encima de las existencias entre sí.
• El seguimiento vuelve a Amazon. Cuando envías el pedido e introduces el transportista y el número de seguimiento en el pedido de PrestaShop, la integración los envía a Amazon mediante la SP-API para que el comprador vea el estado de envío y tu Valid Tracking Rate se mantenga sano. Sin esto, introduces el seguimiento dos veces y abres la puerta a errores de transcripción.

Por qué "enviarlo al back office" es mejor que vivir en Seller Central

Centralizar los pedidos no es una cuestión de orden por el orden. Te da un único descuento de stock en todos los canales, un único flujo de preparación y envío que tu equipo ya conoce, e informes combinados donde los ingresos de Amazon aparecen junto a los ingresos directos, no en un silo aparte que tienes que encajar mentalmente al cierre de mes.

La línea de cumplimiento que no puedes cruzar: los datos de clientes de Amazon

Cuando los pedidos de Amazon aterrizan en PrestaShop, hay un botón tentador que no debes pulsar. Las condiciones de Amazon prohíben usar datos de clientes derivados de pedidos para tu propio marketing. No importes compradores de Amazon a tu lista de newsletter, no hagas retargeting con ellos, no les envíes emails para que "la próxima vez compren directamente". Amazon vigila exactamente esto y suspende a los vendedores que lo hacen. En la práctica, esto significa que tu integración debe traer los pedidos para la preparación y envío, pero mantener a esos clientes fuera de cualquier segmento de marketing. Si tienes en PrestaShop un flujo de carritos abandonados o de newsletter, asegúrate de excluir a los clientes procedentes de Amazon por estado o grupo: una pequeña configuración que protege tu cuenta de vendedor.

Precios en dos canales sin hacerte la competencia a ti mismo

Tu precio en PrestaShop y tu precio en Amazon no tienen por qué ser idénticos, pero la relación entre ambos tiene una regla estricta y un par de decisiones de criterio.

La regla estricta: nunca pongas Amazon por debajo de tu propia tienda. Si un cliente que te encontró directamente puede pagar menos en Amazon, le has enseñado a comprar por el canal que se lleva una comisión y te oculta su email, debilitando justo la tienda que te pertenece. Que Amazon sea la opción más barata es sabotearte.

A partir de ahí, tienes margen de maniobra:

• Igualar precios para mantener coherencia y confianza. Tu margen en Amazon es menor por la comisión de referencia, pero evitas el conflicto entre canales que erosiona la confianza del cliente cuando los precios no coinciden.
• Poner Amazon ligeramente más caro para recuperar la comisión de referencia; viable en productos donde tienes poca competencia de precio, más arriesgado cuando la Buy Box está disputada.
• Lanzar promociones exclusivas por canal en lugar de descuentos cruzados: un pack o una oferta de envío gratuito que solo exista en tu tienda PrestaShop da a los compradores directos una razón para acudir a ti sin que los dos canales se contradigan de forma visible. En PrestaShop, Catálogo → Descuentos (reglas de carrito y reglas de precio de catálogo) es donde construyes esas ofertas exclusivas de la tienda.

La cuestión más profunda de si la economía del marketplace funciona para tus márgenes pertenece al plano estratégico; de nuevo, marketplace frente a tienda propia cubre los cálculos de comisiones.

Gestión logística: FBA, FBM y el modelo híbrido al que llegan muchos comerciantes de PrestaShop

La elección logística cambia cómo fluye el stock, por eso encaja en una guía de integración y no solo en una de estrategia.

• FBA (Fulfilment by Amazon): envías inventario a Amazon, ellos lo almacenan, preparan y envían, y el producto puede llevar la insignia Prime. El punto delicado para la sincronización es que el stock FBA está físicamente en los almacenes de Amazon; por tanto, la cantidad "maestra" de PrestaShop debe tener en cuenta las unidades comprometidas con Amazon por separado de las unidades en tu propio almacén, o tu tienda directa intentará vender stock que no tiene físicamente.
• FBM (Fulfilment by Merchant): envías desde tu propio almacén. El stock es de verdad un único fondo común, lo que hace que la sincronización sea conceptualmente más sencilla: cada pedido, de Amazon o directo, sale de la misma estantería. Sin insignia Prime salvo que cumplas los requisitos de Seller Fulfilled Prime.
• El modelo híbrido que muchos comerciantes acaban usando: FBA para los productos más vendidos, los que más se benefician de la insignia Prime y de la velocidad, FBM para la larga cola donde las tarifas de almacenamiento de Amazon se comerían el margen. Esto mantiene visibles los productos de alta rotación y barato el mantenimiento de los de baja rotación, pero también significa que tu integración debe saber qué productos se gestionan de cada forma, porque las dos modalidades tienen realidades de stock distintas.

Las métricas que hacen irrenunciable una sincronización de stock precisa

Amazon evalúa continuamente el rendimiento de los vendedores, y varias de esas métricas dependen directamente de la calidad de tu sincronización:

• Order Defect Rate: se mantiene por debajo del umbral de Amazon, en parte, no cancelando pedidos que no puedes servir.
• Cancellation Rate: la métrica a la que más golpea un fallo de sincronización de stock. Si vendes de más en Amazon porque PrestaShop vendió la última unidad y no actualizó el listing a tiempo, te ves obligado a cancelar, lo que eleva directamente esta tasa.
• Late Shipment Rate y Valid Tracking Rate: ambas quedan protegidas cuando el seguimiento vuelve automáticamente desde el pedido de PrestaShop en lugar de introducirse tarde y a mano.

El mensaje es directo: una brecha en la sincronización de stock no es un problema de orden interno, es un problema de salud de cuenta. Cancelaciones repetidas por vender por encima de las existencias pueden suspender una cuenta de vendedor. Por eso una sincronización "suficientemente buena casi siempre" es una falsa economía en un catálogo de alta rotación.

La pila multicanal en el lado de PrestaShop

Una configuración funcional es un conjunto de piezas, cada una haciendo su trabajo. En PrestaShop, los componentes importantes son:

• El catálogo como fuente única de verdad para productos, combinaciones y stock.
• La integración con Amazon (SP-API), que sincroniza listings y stock hacia fuera y trae pedidos hacia dentro.
• Una configuración de envío multitransportista en Envío → Transportistas para que tanto los pedidos FBM como los directos reciban tarifas y etiquetas correctas.
• Estado de pedido y segmentación para que los pedidos de Amazon estén claramente marcados y queden fuera de los flujos de marketing.
• Separación contable limpia para que las comisiones de referencia, las tarifas FBA y los ingresos por canal sean distinguibles al cierre de mes.

Dónde encajamos nosotros: en mypresta.rocks desarrollamos los módulos del lado de PrestaShop alrededor de esta pila: las herramientas SEO que hacen crecer el canal directo que realmente te pertenece y el trabajo sobre el proceso de pago que convierte a los visitantes que, tras conocer tu marca en Amazon, acaban buscándote y llegando a tu propia tienda. El enfoque en beneficios es deliberado: Amazon te compra descubrimiento y volumen; los módulos de tu propia tienda son los que convierten esa audiencia prestada en clientes cuya relación, y cuyo margen completo, te pertenecen.

No dejes que Amazon se convierta en todo el negocio

Una última advertencia operativa que, en realidad, es estructural. Cuanto más profundo entre Amazon en tu mezcla de ingresos, más puede desestabilizar toda la operación un único cambio de política o de comisiones de Amazon. Mantén el marketplace como alimentador de la tienda que posees, no como sustituto: precisamente por eso todas las preguntas de integración anteriores tienden a mantener PrestaShop como sistema maestro y las relaciones con tus clientes de tu lado de la línea. Si estás valorando hasta qué punto apoyarte en marketplaces, esa compensación es el tema de marketplace frente a tienda propia; y si parte del atractivo de Amazon era simplemente que "la gente confía más en él que en mi tienda desconocida", la comparación honesta de dónde gana realmente un marketplace alojado está en dónde gana Shopify: la misma lógica de transferencia de confianza, mirada de frente.

Un primer mes realista

• Semana 1: base. Abre una cuenta de vendedor Profesional de Amazon (el plan Individual por artículo solo tiene sentido por debajo de ~40 ventas al mes y te deja fuera de las herramientas masivas). Confirma que PrestaShop es tu fuente de verdad y que tus referencias de producto coinciden con los Seller SKU que vas a usar.
• Semana 2: conexión y mapeo. Pon en marcha tu integración SP-API, mapea un pequeño conjunto de SKU más vendidos y crea el estado de pedido "Amazon, por enviar". Verifica que las actualizaciones de stock salen y que un pedido de prueba entra y descuenta correctamente antes de escalar.
• Semana 3: logística. Decide FBA o FBM por producto. Si usas FBA, envía tu primer shipment y asegúrate de que tu stock maestro tiene en cuenta las unidades que ahora están en el almacén de Amazon.
• Semana 4: puesta en marcha y vigilancia de indicadores. Publica el resto de tu gama inicial y revisa a diario, durante las primeras semanas, la precisión de la sincronización y tus métricas de Amazon. El mes de infraestructura trata de demostrar que el círculo se cierra: pedidos dentro, stock abajo, seguimiento de vuelta; no trata de volumen.

La venta multicanal bien hecha no tiene glamour: un catálogo, un back office, un stock que dice la verdad y una línea clara entre los clientes que Amazon te deja conservar y los que no. Hazlo bien y Amazon será un segundo escaparate encima de la tienda que posees; que, al final, es la única que es plenamente tuya.

Preguntas frecuentes sobre Amazon y PrestaShop

¿Debe PrestaShop o Amazon ser la fuente de verdad del stock?

Para un comerciante que ya trabaja con PrestaShop, PrestaShop debería ser el sistema maestro casi siempre. Tu catálogo, combinaciones y cantidades de stock alimentan Amazon, y los pedidos de Amazon vuelven para descontarse del mismo fondo común. Esa única regla, un lugar para cambiar un precio, un lugar para leer el stock real, un flujo de almacén sin importar de dónde venga el pedido. Elimina la mayoría de las contradicciones que hacen dolorosa la venta multicanal. Gestionar cada canal a mano solo aguanta a escala muy pequeña, y se rompe caro.

¿Sigo necesitando un módulo MWS, o debe ser SP-API?

SP-API, sin discusión. Amazon retiró el antiguo MWS (Marketplace Web Services), así que cualquier módulo o script que siga basado en él es peso muerto: no se autenticará. Cuando hagas una lista corta de integraciones con Amazon, que sea "nativa de SP-API" es un requisito imprescindible, no un extra interesante. La SP-API también usa Login with Amazon OAuth en lugar de claves estáticas, así que cuando una herramienta te lleva por una pantalla de consentimiento de Amazon para "conectar tu cuenta", eso significa que está funcionando correctamente.

¿Puede un módulo sincronizar realmente miles de SKU en tiempo real?

No de verdad segundo a segundo, y un proveedor que promete "todo en tiempo real, sin límites" está usando mal las palabras o está a punto de sufrir limitaciones. La SP-API tiene límites de frecuencia por endpoint, así que las integraciones honestas agrupan actualizaciones dentro de las cuotas de Amazon. Lo que quieres es una latencia baja y predecible, y envíos activados por eventos a partir de los cambios de stock de PrestaShop: lo bastante rápidos para que la ventana de sobreventa sea pequeña, no una garantía literal de instantaneidad que la API, de todos modos, no permite.

¿Por qué importa tanto la sincronización de stock para mi cuenta de Amazon, y no solo para tenerlo todo ordenado?

Porque Amazon evalúa continuamente el rendimiento del vendedor y varias métricas dependen de la calidad de la sincronización. Si vendes de más porque PrestaShop vendió la última unidad y el listing no se actualizó a tiempo, te ves obligado a cancelar, lo que eleva directamente tu Cancellation Rate y tu Order Defect Rate. El seguimiento que vuelve automáticamente protege tu Late Shipment Rate y tu Valid Tracking Rate. Cancelaciones repetidas por vender por encima de tus existencias pueden suspender una cuenta de vendedor; por eso una sincronización "suficientemente buena casi siempre" es una falsa economía en un catálogo rápido.

¿Debe mi precio de Amazon coincidir con mi precio de PrestaShop?

La regla estricta: nunca pongas Amazon por debajo de tu propia tienda, o enseñarás a los clientes a comprar por el canal que se lleva una comisión y oculta su email. Por encima de ese suelo tienes margen: igualar precios por confianza, poner Amazon ligeramente más caro para recuperar la comisión de referencia cuando la competencia sea ligera, o lanzar promociones exclusivas por canal (un pack o una oferta de envío gratuito creada con Catálogo → Descuentos de PrestaShop) para que los compradores directos tengan una razón para acudir a ti sin que los dos canales se contradigan de forma visible.

Sigue leyendo

• Marketplace frente a tienda propia, la estrategia y los cálculos de comisiones para decidir si vender en Amazon tiene sentido.
• Por qué importa ser dueño de tu código, por qué PrestaShop sigue siendo el activo y Amazon sigue siendo el alimentador.
• Por qué elegimos PrestaShop, el razonamiento de plataforma detrás de los módulos de esta pila.