> ## Documentation Index
> Fetch the complete documentation index at: https://docs.listo.delivery/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Notes on the Listo Partner Delivery API:
> - Every endpoint is under `https://api.listo.delivery/v1/` and authenticates with a bearer API key.
> - This documentation site is at https://docs.listo.delivery. The full machine-readable reference is the OpenAPI document at https://api.listo.delivery/docs/openapi.yaml (served by the API host, not by this site).
> - Any page of this site is also available as raw markdown by appending `.md` to its URL, for example https://docs.listo.delivery/en/guides/webhooks.md. The index of every page is https://docs.listo.delivery/llms.txt and all of them in one file is https://docs.listo.delivery/llms-full.txt.
> - Every page is published in English under https://docs.listo.delivery/en/ and in Spanish under https://docs.listo.delivery/es/, with the same path after the language. The API reference is under https://docs.listo.delivery/api-reference/ in English and https://docs.listo.delivery/es/api-reference/ in Spanish.
> - To debug an integration yourself: `GET /v1/request_logs` lists the calls your keys made with what you sent and what was answered, `GET /v1/events` lists the events Listo emitted, `GET /v1/webhook_deliveries` lists every attempt to deliver them, `POST /v1/events/{id}/resend` sends one event again and `POST /v1/test_webhooks` sends a sample event (`"test": true`). The page https://docs.listo.delivery/en/guides/debugging describes them. A resent event is a snapshot from when it happened; `GET /v1/deliveries` is still how you recover current state.
> - Every error response has `error.doc_url`, a page that explains that error code and what to do, and `error.request_id`, the same value as the `X-Request-Id` response header. All the pages are listed at https://docs.listo.delivery/en/errors. Filter `GET /v1/request_logs` with `request_id` to read the logged call.
> - A `409 account_exists` from `POST /v1/stores` means the restaurant already has its own Listo account: connect it instead of creating it, as the page https://docs.listo.delivery/en/guides/connect-existing-account describes.
> - Every live store carries one Plan Listo, charged to the partner. The exception is a connected restaurant that had already paid its current month: it keeps paying its own plan until its next renewal, shown as `paid_by: "store"` with the handover date in `pending_paid_by_on`. A `402 plan_required` from a quote, a delivery create or a retry means the store's plan is not paid or has ended; the page https://docs.listo.delivery/en/guides/plan-and-billing describes the plan, the `plan` block on a store and how to end or restart it.
> - An AI assistant (Claude Code, Cursor, Codex) can act through the same API key at `https://api.listo.delivery/mcp`, an MCP server over Streamable HTTP authenticated with `Authorization: Bearer <API key>`. Every tool runs the matching `/v1/` endpoint, and each one that moves money first previews and then needs a confirmation token; the page https://docs.listo.delivery/en/guides/connect-ai-client lists the tools and describes the two steps.

# Plan y cobro

> Cada tienda en modo real lleva un Plan Listo, y lo pagas tú. Cuánto cuesta, cuándo se cobra, cómo leerlo y cómo terminarlo o reactivarlo.

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](#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](#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](https://partners.listo.delivery), 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`](https://docs.listo.delivery/es/api-reference/ledger/list-your-ledger-entries) 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](https://docs.listo.delivery/es/guides/balance-and-withdrawals.md).

> [!WARNING]
>
> **Crear una tienda en modo real ya gasta dinero**
>
> `POST /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](#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](#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`.

```json theme={null}
{
  "id": "st_4bR8kM2wQ7xT1nV5cZ9pLdYe",
  "access_tier": "api_only",
  "billing": "partner",
  "test": false,
  "plan": {
    "status": "active",
    "price_cents": 199000,
    "currency": "MXN",
    "interval": "month",
    "current_period_ends_on": "2026-10-06",
    "next_charge_on": "2026-10-07",
    "canceled_at": null,
    "ends_on": null,
    "paid_by": "partner",
    "pending_paid_by": null,
    "pending_paid_by_on": null,
    "courtesy": false
  }
}
```

`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`.

| Campo | Qué es |
| - | - |
| `status` | En qué está el plan. Ve la siguiente tabla. |
| `price_cents` | Lo que te cuesta un mes del plan de esta tienda, antes de IVA: tu precio, aunque un restaurante conectado siga pagando su propio plan. El cargo es esto más IVA. |
| `currency` | Siempre `"MXN"`. |
| `interval` | Cada cuánto se cobra este plan: `"month"` en un plan que pagas tú. En un plan que paga el restaurante, el intervalo del propio restaurante, `"month"` o `"year"`. |
| `current_period_ends_on` | El último día del periodo en curso, como fecha: ya pagado, salvo que `status` sea `past_due`. |
| `next_charge_on` | El día de tu siguiente cargo: la siguiente renovación, o, mientras un restaurante conectado sigue pagando su propio plan, tu primer cargo. `null` cuando el plan está por terminar o ya terminó, porque ya no se va a cobrar nada. También `null` mientras el plan está en `past_due`, porque el mes que se debe no tiene fecha: se cobra en cuanto tu saldo o tu tarjeta guardada lo permitan, y se reintenta cada día hasta que se pague. También `null` mientras `courtesy` es `true`. |
| `canceled_at` | Cuándo se dio de baja la tienda, como marca de tiempo. `null` si no. |
| `ends_on` | El día en que el plan deja de atender a la tienda, que es el día siguiente al último día pagado, o el día en que diste de baja un plan con el cobro pendiente. Desde ese día sus envíos se rechazan. `null` si el plan no está por terminar ni terminó. |
| `paid_by` | Quién paga este plan: `"partner"`, que eres tú, o `"store"`, el restaurante. |
| `pending_paid_by` | Quién lo va a pagar a partir de `pending_paid_by_on`, cuando eso está por cambiar. `"partner"`, `"store"` o `null`. |
| `pending_paid_by_on` | La fecha en que llega ese cambio, o `null`. |
| `courtesy` | `courtesy` es true mientras el plan de esta tienda es una cortesía de Listo: no se cobra nada y `next_charge_on` es null. |

| `status` | Qué significa | Repartidores |
| - | - | - |
| `active` | Al corriente, y se renueva en `next_charge_on`. | sí |
| `awaiting_payment` | El primer mes de la tienda no se ha pagado: tu saldo y tu tarjeta no alcanzaron a cubrirlo. Todavía no tiene plan, `price_cents` es el precio que se le va a cobrar antes de IVA (lo que hace falta para pagarlo es ese precio más IVA) y las fechas vienen en `null`. Listo lo cobra en cuanto recargas o guardas una tarjeta. | no, `plan_required` |
| `past_due` | El mes en curso no se ha pagado. Listo lo reintenta en cuanto recargas o guardas una tarjeta, y todos los días. | no, `plan_required` |
| `canceling` | Dada de baja. Se atiende hasta antes de `ends_on`, y ya no se cobra nada más. | sí, hasta el día anterior a `ends_on` |
| `canceled` | Terminado. No se cobra nada, y se puede reactivar. | no, `plan_required` |

`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](https://docs.listo.delivery/es/guides/webhooks.md).
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`](https://docs.listo.delivery/es/api-reference/quotes/price-a-delivery), en
[`POST /v1/deliveries`](https://docs.listo.delivery/es/api-reference/deliveries/create-a-delivery) y en
[`POST /v1/deliveries/{id}/retries`](https://docs.listo.delivery/es/api-reference/deliveries/retry-a-failed-dispatch).
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.

```json theme={null}
{
  "error": {
    "code": "plan_required",
    "message": "This store's plan charge is pending.",
    "param": null,
    "retryable": false
  }
}
```

Tiene cinco motivos, y `error.message` dice cuál es:

| Motivo | Qué hacer |
| - | - |
| La tienda no tiene un plan activo. | Reactívalo (abajo). |
| El cargo del plan de la tienda está pendiente. | Recarga tu saldo real o guarda una tarjeta: el cargo se vuelve a intentar en ese momento. |
| El plan de la tienda terminó en la fecha que dice el mensaje. | Reactívalo (abajo). |
| La tienda no puede pedir repartidores por ahora. | Contacta a Listo. |
| La tienda ya usó todos los envíos que incluye su plan en este ciclo. | Espera al día de renovación que dice el mensaje: la cuenta empieza de nuevo con el ciclo nuevo. Para quitar el límite, contacta a Listo. |

`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`](https://docs.listo.delivery/es/api-reference/stores/cancel-a-stores-plan)
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`](https://docs.listo.delivery/es/api-reference/stores/undo-a-stores-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`](https://docs.listo.delivery/es/api-reference/stores/reactivate-a-stores-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.

| HTTP | `code` | Qué pasó |
| - | - | - |
| 402 | `insufficient_balance` | Ni tu saldo ni tu tarjeta alcanzaron para pagar el mes. No cambió nada: no se cobró nada y la tienda sigue terminada. Recarga o guarda una tarjeta y vuelve a llamar. |
| 409 | `charge_in_progress` | Un cargo con tarjeta del plan de esta tienda sigue en manos del banco. No se cobró nada nuevo. `retryable` es `true`: vuelve a leer la tienda en unos minutos, o repite la llamada. |
| 409 | `not_reactivatable` | El plan no ha terminado. Una tienda en `canceling` se deshace con `DELETE /v1/stores/{id}/plan_cancellation`, y una en `past_due` vuelve a arrancar cuando pasa su cargo. |

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](https://docs.listo.delivery/es/guides/connect-existing-account.md), 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](https://docs.listo.delivery/es/guides/connect-existing-account.md)
  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](https://docs.listo.delivery/es/concepts/test-mode.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.