Saltar al contenido principal
Cada tienda que tienes en modo real lleva un Plan Listo, y ese plan se te cobra a ti. Un plan por tienda, sin importar su access_tier, y sin importar si la tienda es una sucursal tuya o un restaurante para el que haces la integración. Listo nunca le cobra al restaurante un plan que pagas tú, y nunca se entera de cuánto le cobras: factúrale a tus clientes como quieras. En el acuerdo de algunos partners con Listo pasa al revés: cada restaurante paga su propio Plan Listo, y tú no pagas nada por él. Si ese es tu acuerdo, Listo lo configuró en tu cuenta y lo que esta página dice sobre cargos a ti no aplica en tu caso. Cuando cada restaurante paga su propio plan explica qué cambia. Si no sabes cuál tienes, pregúntale a Listo. Una tienda en modo real sin un plan al corriente no puede pedir repartidores. Las tiendas de prueba no tienen plan, nunca pagan uno y nunca se rechazan por no tenerlo.

​
Cuánto cuesta un plan

A precio de lista, Plan Listo cuesta MX$1,990 más IVA al mes por cada tienda: 199000 centavos antes de IVA, 230840 con IVA. Si acordaste otro precio con Listo, a todas tus tiendas se les cobra el precio acordado con Listo. El precio es por tienda y nunca se junta. Diez tiendas en modo real son diez planes, cada uno con su propia fecha de renovación y su propio cargo. Cuando cambia tu precio acordado, el cambio le llega a cada tienda en su siguiente renovación. El mes que una tienda ya pagó no se mueve, y una tienda que creas después del cambio empieza con el precio nuevo. Listo te manda un correo cuando pasa. El plan cubre los repartidores, la consola de Listo y el asistente de IA por WhatsApp de esa tienda. Si una tienda en full usa el asistente más allá de las conversaciones que incluye su plan, esas también se cobran, y se te cobran a ti junto con el plan de esa tienda.

​
Cuándo se cobra

El plan empieza el día que creas la tienda con una llave real, y el primer mes se cobra en esa misma petición. Si tu saldo y tu tarjeta no alcanzan a cubrir ese primer cargo, la tienda se crea de todos modos pero el plan todavía no empieza: empieza el día que ese cargo se paga (cuando el primer cargo no se puede pagar). De ahí en adelante se renueva cada mes el mismo día del mes. Una tienda creada un 29, 30 o 31 se pasa a un día anterior la primera vez que un mes es más corto, y ahí se queda. Mientras el plan está al corriente, next_charge_on en la tienda trae la fecha exacta. Cada cargo se paga de tu saldo real o de la tarjeta guardada en tu cuenta, lo que elijas en la página Planes y facturación del panel de socios, con la otra opción como respaldo, si quieres, para cuando la primera no alcanza. Nunca se paga del saldo propio de una tienda, y nunca de tu saldo de prueba. Un mes que se paga del saldo se gasta contra balance_cents, igual que un envío, y aparece en GET /v1/ledger como una fila plan_charge con el monto completo, IVA incluido, la tienda en store_id y un delivery_id en null. Un mes que se paga con tarjeta no mueve nada de tu saldo y no deja ninguna fila en el historial. Ve saldo y retiros.
Crear una tienda en modo real ya gasta dineroPOST /v1/stores con una llave real cobra el primer mes de la tienda en la misma petición, y el plan empieza ahí solo si ese cargo pasa; si no, la tienda espera y el plan empieza el día que se paga. Fondea tu saldo real o guarda una tarjeta antes de crear la tienda, y manda un Idempotency-Key en cada creación en modo real: una creación que se fue a timeout y se repite sin llave crea una segunda tienda, y la segunda tienda empieza un segundo plan. Si además mandas external_id, puedes encontrar la tienda con GET /v1/stores?external_id= cuando nadie reintentó.

​
Cuando el primer cargo no se puede pagar

Una tienda cuyo primer cargo no alcanzan a cubrir tu saldo y tu tarjeta se crea de todos modos, y la creación responde 201 con la tienda. Todavía no tiene plan: su plan dice awaiting_payment, y cada envío que pida se rechaza con 402 plan_required hasta que se pague el mes. Nada está vencido, porque todavía no se ha usado nada. Listo lo cobra solo en cuanto tu saldo real o tu tarjeta lo cubren, apenas recargas o guardas una tarjeta, y desde ese momento la tienda puede pedir repartidores. Te avisamos una vez que la tienda está esperando (ve qué te avisa Listo), y el precio que se le va a cobrar ya está fijo: es el que tomó tu tienda cuando se creó.

​
Cuando un cargo falla

Una renovación que tu saldo o tu tarjeta no alcanzan a pagar deja en past_due a una tienda que ya estaba funcionando, y cada envío que pida se rechaza con 402 plan_required hasta que se pague el mes. Listo vuelve a intentar el cargo en cuanto recargas tu saldo real o guardas una tarjeta, y todos los días hasta que pasa. Te avisamos cuando el cargo falla, y tres días antes de una renovación que tu saldo no alcanza a cubrir (ve qué te avisa Listo).

​
Cómo leer plan en una tienda

Cada objeto de tienda trae plan: la respuesta de la creación, GET /v1/stores/{id}, cada fila de GET /v1/stores, la respuesta de la actualización y el objeto de tienda que trae un evento store.updated.
plan es null cuando la tienda no necesita plan: una tienda de prueba, o una en modo real creada antes de que existiera Plan Listo, que sigue pidiendo repartidores sin plan. Si tu acuerdo hace que cada restaurante pague su propio plan, plan también es null en una tienda cuyo restaurante todavía no compra uno. Cuando plan es un objeto, cada una de sus llaves viene siempre, y las que no aplican vienen en null. paid_by es "store" mientras un restaurante que conectaste sigue pagando su propio plan: entonces pending_paid_by es "partner" y pending_paid_by_on es la fecha de su siguiente renovación, el día en que el plan pasa a ser tuyo y tu primer cargo. En cualquier otra tienda los dos vienen en null. Si tu acuerdo hace que cada restaurante pague su propio plan, paid_by es "store" para siempre y price_cents e interval son el precio y el intervalo de cobro que paga el restaurante. La única excepción es un plan que ya estabas pagando el día en que cambió tu acuerdo: se queda en paid_by: "partner" hasta su siguiente renovación, con pending_paid_by: "store" y pending_paid_by_on el día en que pasa al restaurante, y next_charge_on es null porque ya no se te cobra. paid_by y billing responden preguntas distintas, y ninguno se deduce del otro. billing dice qué saldo paga los envíos de la tienda, y sigue al access_tier. paid_by dice quién paga su plan, que eres tú en cualquier tier. Una tienda en full dice billing: "store" y paid_by: "partner". Un cambio en el plan de una tienda manda un evento store.updated con el objeto de tienda completo, plan incluido: un plan que empieza, una renovación mensual, un cargo que falla o que pasa, una baja, cuando la deshaces, un plan que termina, una reactivación, un cambio de tu precio y un plan que pasa a ser tuyo. Cada acción manda un solo evento, con el estado en que quedó el plan: una tienda nueva cuyo primer cargo no se puede pagar manda un solo evento con awaiting_payment, nunca un active antes. Los cambios que ocurren casi al mismo tiempo pueden llegar en un solo evento con el estado más reciente, así que lee el plan que trae cada evento en lugar de contar eventos. Ve webhooks. Cuando un restaurante se conecta, su store.connected llega primero y muestra el plan como estaba cuando el dueño aprobó; después llega el store.updated del plan que pasa a ti.

​
Cuándo se rechaza una cotización o un envío

Una tienda en modo real sin un plan al corriente responde 402 plan_required en POST /v1/quotes, en POST /v1/deliveries y en POST /v1/deliveries/{id}/retries. La cotización también se rechaza, porque prometería un precio para un envío que la creación después rechazaría. No se creó nada, no se despachó nada y no se tomó nada de tu saldo.
Tiene cinco motivos, y error.message dice cuál es: retryable es false: la misma petición va a fallar hasta que alguien de tu lado pague, reactive el plan o tenga respuesta de Listo, o hasta que el ciclo se renueve. Ramifica según el código, muéstrale error.message a quien administra tu cuenta de Listo, y distingue los motivos solo por error.message. No leas el plan.status de la tienda para eso: una tienda con el plan active puede haber usado todos los envíos que incluye, así que plan.status sigue en active en esa negativa. Un pedido con tarjeta que se creó mientras el plan estaba al corriente se despacha de todos modos cuando tu cliente paga, aunque el plan haya vencido mientras tanto: el pedido pasó la revisión cuando se creó.

​
Cómo terminar el plan de una tienda

POST /v1/stores/{id}/plan_cancellation da de baja una tienda. No lleva cuerpo. El plan termina al final del mes que ya pagaste, sin reembolso, y la tienda sigue pidiendo repartidores hasta entonces. Responde 200 con la tienda, cuyo plan ahora dice canceling, con canceled_at y ends_on llenos y next_charge_on en null. Un plan con el cobro pendiente (past_due) no tiene un mes pagado por delante, y la tienda ya está sin repartidores, así que termina el mismo día en que lo das de baja: la tienda responde con su plan en canceled y ese día en ends_on. A partir de ends_on el plan queda en canceled y los envíos se rechazan con plan_required: un plan pagado hasta el 6 de octubre dice ends_on: "2026-10-07" y deja de atender ese día. Nada más desaparece: la tienda conserva su id, su historial de envíos, su saldo si tiene uno propio y sus facturas, y ya no se cobra nada por ella. Idempotency-Key es obligatorio, igual que al crear un envío. Repetir la llamada con la misma llave responde con la respuesta original, así que una baja que se fue a timeout se puede volver a mandar sin riesgo. 409 not_cancellable significa que no hay plan que dar de baja: la tienda ya está en canceling, su plan ya terminó, o no necesita plan.

​
Si cambias de opinión

DELETE /v1/stores/{id}/plan_cancellation deshace una baja antes de ends_on. El plan vuelve a active y se renueva en la fecha en que lo habría hecho, como si la baja nunca hubiera pasado. Responde 200 con la tienda. Repetir esta llamada no tiene riesgo. En una tienda cuyo plan sigue corriendo sin ninguna baja que deshacer, no cambia nada y responde 200 con la tienda tal como está. Una vez que el plan terminó ya es tarde para deshacer la baja, y la respuesta es 409 plan_ended, cuyo mensaje da la fecha en que la baja surtió efecto: en ese caso reactiva el plan con POST /v1/stores/{id}/plan. Un restaurante conectado que todavía paga su propio plan decide su propia baja hasta que el plan pasa a tu cuenta. En esa ventana, dar de baja su plan responde 409 not_cancellable, y deshacer una baja que dio el restaurante también.

​
Cómo reactivar un plan que terminó

POST /v1/stores/{id}/plan reactiva el plan de una tienda cuyo plan está en canceled. No lleva cuerpo. Cobra un mes nuevo en ese momento, del mismo saldo o tarjeta que usaría cualquier otro cargo, y de ahí en adelante el plan se renueva cada mes el mismo día del mes en que lo reactivaste. Responde 200 con la tienda, con su plan en active. Idempotency-Key también es obligatorio aquí. Una reactivación que se fue a timeout y se repite con la misma llave responde con la respuesta original en vez de cobrar un segundo mes. Los tres endpoints del plan responden 404 not_found a una llave de prueba, porque una tienda de prueba no tiene plan que terminar ni que reactivar.

​
Un restaurante que ya paga su propio plan

Un restaurante que usa Listo con una cuenta propia, y que se conecta contigo, puede estar pagando ya su propio Plan Listo. Si ya pagó su mes en curso, lo sigue pagando hasta su siguiente renovación, y a partir de esa renovación su plan se te cobra a ti. Un restaurante que pagó un año por adelantado pasa al terminar ese año. Nada se cobra dos veces, no queda ningún hueco entre los dos, y nada se prorratea. Los meses que pagó antes de ese día son suyos: se le facturan al restaurante, y nunca tocan tu saldo, tus facturas ni tu RFC. Lo mismo pasa con lo que le debiera a Listo por su propio plan al conectarse: Listo se lo cobra al restaurante, a ti no te llega ningún aviso, y nunca detiene los repartidores que pagas tú. Hasta ese día la tienda dice paid_by: "store", con pending_paid_by: "partner" y la fecha en pending_paid_by_on. next_charge_on ya es tu primer cargo y price_cents ya es tu precio, así que el bloque siempre describe lo que vas a pagar tú. El evento store.connected de la tienda muestra el plan como estaba cuando el dueño aprobó, el del propio restaurante; unos momentos después te llega un store.updated con el bloque como se describe arriba, y otro cuando el plan cambia, incluido el día en que pasa a ti. Si el restaurante da de baja su propio plan antes de ese día, su baja manda: el plan sigue hasta que se acaba el tiempo que el restaurante ya pagó y termina ahí, y nunca se te cobra a ti. El bloque dice entonces status: "canceling" con paid_by: "store" y sin pending_paid_by, y tu panel dice que el negocio dio de baja su plan y cuándo termina. No puedes deshacer la baja del restaurante, y no hay nada que reactivar hasta que el plan termine. Desde entonces la tienda es una tienda terminada como cualquier otra, y al reactivarla empieza tu propio plan ese día. Si el restaurante retira su baja mientras su plan sigue vigente, el paso a tu cuenta vuelve, para la misma renovación, y te avisamos de nuevo. Un restaurante conectado que no tiene un plan vigente propio empieza uno el día en que se conecta, y ese primer mes se te cobra a ti ese mismo día, igual que en una tienda que creas tú. Un restaurante conectado cuyo mes en curso está sin pagar cuando se conecta tampoco espera a una renovación: el plan pasa a ti ese mismo día, el mes que no había pagado se anula, así que no se le cobra a nadie, y ese mismo día se te cobra un mes completo, igual que en una tienda que creas tú. Lo que le debiera a Listo de meses anteriores sigue siendo suyo, como arriba.

​
Qué te avisa Listo

Cada correo le llega a cada usuario de tu cuenta de socio. Los mismos avisos te llegan por WhatsApp si pones un número para avisos de cobro en Planes y facturación: un número por cuenta, opcional.
  • El plan de una tienda empezó y se cobró su primer mes.
  • El primer mes de una tienda no lo cubrieron tu saldo ni tu tarjeta, así que la tienda está esperando y no tiene repartidores hasta que se cobre. Una vez por tienda.
  • Las tiendas que se renovaron hoy: un correo al día, con sus facturas.
  • Un cargo falló. Una vez, cuando falla: los reintentos diarios que siguen no avisan.
  • Faltan tres días para una renovación y tu saldo no la alcanza a cubrir.
  • Diste de baja una tienda, con el día en que termina su plan.
  • Cambió tu precio acordado, y desde cuándo.
  • Un restaurante que conectaste está pasando su plan a tu cuenta, y la fecha.
  • Un restaurante que conectaste dio de baja su propio plan antes de que pasara a tu cuenta, así que no pasa a tu cuenta, y el día en que termina.
Una tienda con un dueño en la consola también recibe avisos de Listo, porque ese dueño es quien la opera: cuando sus repartidores se detienen porque tu cargo está pendiente, cuando la das de baja y cuando su plan pasa a tu cuenta. Cada uno de esos mensajes le dice al dueño que hable contigo, y ninguno muestra lo que pagas tú.

​
Facturas

Cada cargo pagado se factura con un CFDI a los datos que tengas en Datos de factura, en Planes y facturación. La factura le llega por correo a cada usuario de tu cuenta, y al correo para facturas de Datos de factura si pones uno, y queda en esa página en PDF y XML, una fila por cargo y por tienda. Solo se te facturan los meses que pagas tú: un mes que un restaurante conectado pagó antes de que su plan pasara a tu cuenta se le factura al restaurante. Un cargo que se paga antes de que captures tus datos fiscales se factura en cuanto los captures, y esa factura te llega en un correo aparte. Captúralos antes de crear tu primera tienda en modo real, para que la primera factura llegue con el primer cargo.

​
Cuando cada restaurante paga su propio plan

En el acuerdo de algunos partners con Listo, cada restaurante paga su propio Plan Listo en lugar del partner. Listo lo configura en tu cuenta; no es algo que cambie la API ni el panel. Cuando está configurado en la tuya:
  • A ti nunca se te cobra un periodo nuevo de plan que paga la tienda, y no te llega ninguno de los correos ni WhatsApps de cobro de arriba por uno. Tu saldo y tu tarjeta no se usan para periodos nuevos de plan. El cambio es hacia adelante: un mes que ya se te cobró sigue siendo tuyo por pagar, un plan que ya estabas pagando corre hasta el final del periodo que pagaste y pasa al restaurante en su siguiente renovación (pending_paid_by: "store", con la fecha en pending_paid_by_on), y nada se reembolsa ni se perdona.
  • Una tienda que creas en modo real empieza sin plan, así que su plan es null. Para que el restaurante pueda comprar Plan Listo, la tienda debe tener acceso wallet o full y se debe invitar a su dueño a iniciar sesión: el restaurante compra el plan desde su propia consola, en Ajustes > Plan, y paga con su saldo o su tarjeta como cualquier restaurante en Listo. Una tienda en modo real con acceso api_only no tiene consola, así que nadie podría comprar su plan: crear una, o pasar una tienda en modo real a api_only, se rechaza con validation_failed y param: "access_tier", y Listo no cambia tu cuenta a este acuerdo mientras tengas una. En cuanto el restaurante lo compra, plan es un objeto con paid_by: "store" y el precio y el interval ("month" o "year") que paga el restaurante.
  • Mientras un restaurante no tenga un plan al corriente, sus cotizaciones y envíos se rechazan con 402 plan_required, como en cualquier tienda en modo real sin plan al corriente. Estas tiendas no tienen periodo de prueba: el modo de prueba es donde ensayas.
  • Una tienda que se conecta contigo con conectar una cuenta existente sigue pagando su propio plan, y nada pasa a ti.
  • POST /v1/stores/{id}/plan no reactiva un plan así, porque no te toca pagarlo: el restaurante lo hace desde su consola.

​
En modo de prueba

Nada de esto pasa con una llave de prueba. Las tiendas de prueba traen plan: null, no se cobra nada, ninguna cotización ni envío se rechaza con plan_required, y los tres endpoints del plan responden 404 not_found. El modo de prueba es donde ensayas todo lo demás; el primer plan que vas a ver es el de tu primera tienda en modo real. Ve modo de prueba.