Skip to main content
Every store you run in live mode carries one Plan Listo, and the plan is charged to you. One plan per store, whatever the store’s access_tier, and whether the store is a location of your own or a restaurant you integrate for. Listo never charges the restaurant for a plan you pay, and never learns what you charge it: bill your own clients however you like. Some partners’ agreements with Listo work the other way: each restaurant pays its own Plan Listo, and you pay nothing for it. If that is your agreement, Listo has set it on your account and the rest of this page about charges to you does not apply to you. Where each restaurant pays its own plan says what changes. If you are not sure which one you have, ask Listo. A live store without a paid-up plan cannot request couriers. Test stores have no plan, never pay one and are never refused for lack of one.

​
What a plan costs

At list price, Plan Listo is MX$1,990 plus IVA a month for each store: 199000 cents before IVA, 230840 with it. If you agreed a different price with Listo, every one of your stores is charged the price agreed with Listo instead. A price is per store and never pooled. Ten live stores are ten plans, each with its own renewal date and its own charge. When your agreed price changes, the change reaches each store at its next renewal. The month a store already paid for does not move, and a store you create after the change starts at the new price. Listo emails you when it happens. The plan covers the couriers, the Listo console and the WhatsApp AI assistant for that store. A store on the full tier that runs the assistant past the conversations its plan includes is charged for those too, and they are charged to you along with that store’s plan.

​
When it is charged

The plan starts the day you create the store with a live key, and the first month is charged in that same request. If your balance and card cannot cover that first charge, the store is still created but the plan has not started: it starts the day that charge is paid (when the first charge cannot be paid). From then on it renews every month on the same day of the month. A store created on the 29th, 30th or 31st moves to an earlier day the first time a month is shorter, and stays there. While the plan is paid up, next_charge_on on the store carries the exact date. Each charge is paid from your live balance or from the card saved on your account, whichever you choose on the Planes y facturación page of the partner dashboard, with the other one as an optional backup when the first cannot pay. It is never paid from a store’s own balance, and never from your test balance. A month paid from the balance spends against balance_cents, exactly as a delivery does, and appears on GET /v1/ledger as a plan_charge row with the whole amount, IVA included, the store in store_id and a delivery_id of null. A month paid by card moves nothing on your balance and writes no ledger row. See balance and withdrawals.
A live store create spends money nowPOST /v1/stores with a live key charges the store’s first month in the same request, and the plan starts there only if that charge goes through; otherwise the store waits and the plan starts the day it is paid. Fund your live balance or save a card before you create a store, and send an Idempotency-Key on every live create: a create that timed out and is repeated without one makes a second store, and the second store starts a second plan. Sending external_id as well lets you find the store with GET /v1/stores?external_id= when nobody retried.

​
When the first charge cannot be paid

A store whose first charge your balance and card cannot cover is still created, and the create still answers 201 with the store. It has no plan yet: its plan reads awaiting_payment, and every delivery it asks for is refused with 402 plan_required until the month is paid. Nothing is past due, because nothing has been used. Listo charges it by itself the moment your live balance or your card covers it, as soon as you top up or save a card, and from then on the store can request couriers. You are told once that the store is waiting (see what Listo tells you), and the price it will be charged is already fixed: it is the one your store took when it was created.

​
When a charge fails

A renewal your balance or card cannot pay leaves a store that was already running past_due, and every delivery it asks for is refused with 402 plan_required until the month is paid. Listo tries the charge again as soon as you top up your live balance or save a card, and every day until it goes through. You are told when the charge fails, and three days before a renewal your balance cannot cover (see what Listo tells you).

​
Reading plan on a store

Every store object carries plan: the create response, GET /v1/stores/{id}, every row of GET /v1/stores, the update response, and the store object a store.updated event carries.
plan is null when the store needs no plan: a test store, or a live store created before Plan Listo existed, which keeps requesting couriers without one. If your agreement has each restaurant pay its own plan, plan is also null on a store whose restaurant has not bought one yet. When plan is an object, every key in it is always present, and the ones that do not apply are null. paid_by is "store" while a restaurant you connected is still paying its own plan: pending_paid_by is then "partner" and pending_paid_by_on is the date of its next renewal, the day the plan becomes yours and your first charge. On every other store both are null. If your agreement has each restaurant pay its own plan, paid_by is "store" for good and price_cents and interval are the price and the billing interval the restaurant pays. The one exception is a plan you were already paying on the day your agreement changed: it stays paid_by: "partner" until its next renewal, with pending_paid_by: "store" and pending_paid_by_on the day it passes to the restaurant, and next_charge_on is null because you are not charged again. paid_by and billing answer different questions, and neither can be read off the other. billing says whose balance pays the store’s deliveries, and follows access_tier. paid_by says who pays its plan, which is you on every tier. A full store reads billing: "store" and paid_by: "partner". A change to a store’s plan sends a store.updated event carrying the whole store object, plan included: a plan that starts, a monthly renewal, a charge that fails or goes through, a cancellation, its undo, a plan that ends, a restart, a change of your price, and a plan moving to you. One act sends one event, carrying the state the plan ended in: a new store whose first charge cannot be paid sends a single event reading awaiting_payment, never an active before it. Changes that land close together can arrive as one event carrying the latest state, so read the plan each event carries rather than counting events. See webhooks. When a restaurant connects, its store.connected comes first and shows the plan as it stood when the owner approved; the store.updated for the plan passing to you follows it.

​
When a quote or a delivery is refused

A live store without a paid-up plan answers 402 plan_required on POST /v1/quotes, on POST /v1/deliveries and on POST /v1/deliveries/{id}/retries. The quote refuses too, because it would promise a price for a delivery the create would then refuse. Nothing was created, nothing was dispatched, and nothing was taken from your balance.
It has five reasons, and error.message names the one it is: retryable is false: the identical request fails until somebody on your side pays, restarts the plan or hears back from Listo, or until the cycle renews. Branch on the code, surface it to whoever manages your Listo account with error.message, and tell the reasons apart by error.message alone. Do not read the store’s plan.status for that: a store whose plan is active can still have used all the deliveries it includes, so plan.status stays active for that refusal. A card order created while the plan was paid up still dispatches when your customer pays, even if the plan lapsed in between: the order passed the check when it was created.

​
Ending a store’s plan

POST /v1/stores/{id}/plan_cancellation cancels a store’s plan, which the dashboard calls Dar de baja. It takes no body. The plan ends at the end of the month you already paid, with no refund, and the store keeps requesting couriers until then. It answers 200 with the store, whose plan now reads canceling, with canceled_at and ends_on filled in and next_charge_on at null. A plan whose charge is pending (past_due) has no paid month left to run out, and the store is already without couriers, so it ends the day you cancel it: the store answers with its plan canceled and that day in ends_on. From ends_on the plan is canceled and deliveries are refused with plan_required: a plan paid through 6 October reads ends_on: "2026-10-07" and stops serving that day. Nothing else goes away: the store keeps its id, its delivery history, its balance if it owns one, and its invoices, and nothing more is charged for it. Idempotency-Key is required, as it is on a delivery create. Repeating the call with the same key answers with the original response, so a cancellation that timed out can be sent again safely. 409 not_cancellable means there is no plan to cancel: the store is already canceling, its plan has ended, or it needs no plan at all.

​
Changing your mind

DELETE /v1/stores/{id}/plan_cancellation undoes a cancellation before ends_on. The plan goes back to active and renews on the date it would have, as if you had never canceled it. It answers 200 with the store. It is safe to repeat. On a store whose plan is running with no cancellation to undo, it changes nothing and answers 200 with the store as it is. Once the plan has ended it is too late to undo, and the answer is 409 plan_ended, whose message gives the date the cancellation took effect: restart the plan with POST /v1/stores/{id}/plan instead. A connected restaurant that is still paying its own plan decides its own cancellation until the plan moves to you. In that window a cancellation of its plan answers 409 not_cancellable, and so does an undo of a cancellation the restaurant gave.

​
Restarting an ended plan

POST /v1/stores/{id}/plan restarts the plan of a store whose plan is canceled. It takes no body. It charges a new month right away, from the same balance or card any other charge would use, and from then on the plan renews every month on the day of the month you restarted it. It answers 200 with the store, its plan active. Idempotency-Key is required here too. A restart that timed out and is repeated with the same key answers with the original response rather than charging a second month. All three plan endpoints answer 404 not_found to a test key, because a test store has no plan to end or restart.

​
A restaurant that already pays its own plan

A restaurant that runs on Listo with an account of its own, and connects to you, may already be paying its own Plan Listo. If it has paid its current month, it goes on paying until its next renewal, and from that renewal its plan is charged to you. A restaurant that prepaid a year moves at the end of that year. Nothing is charged twice, there is no gap between the two, and nothing is prorated. The months it paid before that day are its own: they are invoiced to the restaurant, and never touch your balance, your invoices or your RFC. So is anything it still owed Listo for its own plan when it connected: Listo collects that from the restaurant, you are never told about it, and it never stops the couriers you pay for. Until that day the store reads paid_by: "store", with pending_paid_by: "partner" and the date in pending_paid_by_on. next_charge_on is already your first charge and price_cents already your price, so the block always describes what you will pay. The store.connected event for the store shows the plan as it stood when the owner approved, the restaurant’s own; a store.updated follows within moments with the block as above, and another arrives when the plan moves, the day it passes to you included. If the restaurant cancels its own plan before that day, its cancellation wins: the plan runs to the end of the time the restaurant already paid for and ends there, and it is never charged to you. The block then reads status: "canceling" with paid_by: "store" and no pending_paid_by, and your dashboard says the business canceled its plan and when it ends. You cannot undo the restaurant’s cancellation, and there is nothing to reactivate until the plan has ended. From then on the store is an ended store like any other, and reactivating it starts your own plan that day. If the restaurant takes its cancellation back while its plan is still running, the move to you is back on, for the same renewal, and you are told again. A connected restaurant with no live plan of its own starts one the day it connects, and that first month is charged to you that day, exactly as for a store you create. A connected restaurant whose current month is unpaid when it connects does not wait for a renewal either: the plan passes to you that day, the month it had not paid is voided, so nobody is charged for it, and one full month is charged to you that day, exactly as for a store you create. Whatever it owed Listo for earlier months stays its own, as above.

​
What Listo tells you

Every email goes to every user on your partner account. The same moments reach you on WhatsApp when you set the number for charge notices on Planes y facturación: one number for the account, optional.
  • A store’s plan started and its first month was charged.
  • A store’s first month could not be covered by your balance or card, so the store is waiting and has no couriers until it is charged. Once per store.
  • The stores that renewed today: one email a day, with their invoices.
  • A charge failed. Once, when it fails: the daily retries after it are silent.
  • A renewal is three days away and your balance does not cover it.
  • You canceled a store’s plan, with the day it ends.
  • Your agreed price changed, and from when.
  • A restaurant you connected is moving its plan to you, and the date.
  • A restaurant you connected canceled its own plan before it moved to you, so it does not move to you, and the day it ends.
A store with a console owner hears from Listo too, because that owner runs the store: when its couriers stop because your charge is pending, when you cancel its plan, and when its plan moves to you. Each of those messages tells the owner to talk to you, and none of them shows what you pay.

​
Invoices

Each paid charge is invoiced with a CFDI to the fiscal data in Datos de factura on Planes y facturación. The invoice is emailed to every user on your account, and to the invoice address in Datos de factura when you set one, and it is listed on that page as PDF and XML, one row per charge and store. Only the months you pay are invoiced to you: a month a connected restaurant paid before its plan moved to you is invoiced to the restaurant. A charge paid before your fiscal data is in is invoiced as soon as you fill it in, and that invoice arrives in an email of its own. Fill it in before you create your first live store, so the first invoice comes with the first charge.

​
Where each restaurant pays its own plan

Some partners’ agreements with Listo have each restaurant pay its own Plan Listo instead of the partner. Listo sets this on your account; it is not something the API or the dashboard changes. When it is set on yours:
  • You are never charged for a new store-paid period, and none of the charge emails or WhatsApps above reach you for one. Your balance and your card are not used for new plan periods. The change is forward only: a month already billed to you stays yours to pay, a plan you were already paying runs to the end of the period you paid and passes to the restaurant at its next renewal (pending_paid_by: "store", with the date in pending_paid_by_on), and nothing is refunded or waived.
  • A store you create in live mode starts with no plan, so its plan is null. Before the restaurant can buy Plan Listo, the store must have wallet or full access and its owner must be invited to sign in: the restaurant buys the plan from its own console, in Ajustes > Plan, and pays from its own balance or card like any restaurant on Listo. A live store with api_only access has no console, so nobody could buy its plan: creating one, or moving a live store to api_only, is refused with validation_failed and param: "access_tier", and Listo does not switch your account to this agreement while you hold one. Once the restaurant has bought it, plan is an object with paid_by: "store" and the price and interval ("month" or "year") the restaurant pays.
  • Until a restaurant has a paid plan, its quotes and deliveries are refused with 402 plan_required, as for any live store without a paid-up plan. There is no trial for these stores: test mode is where you rehearse.
  • A store that connects to you through connect an existing account keeps paying its own plan, and nothing moves to you.
  • POST /v1/stores/{id}/plan does not restart such a plan, because it is not yours to pay: the restaurant does that from its console.

​
In test mode

None of this happens with a test key. Test stores carry plan: null, nothing is charged, no quote or delivery is refused with plan_required, and the three plan endpoints answer 404 not_found. Test mode is where you rehearse everything else; the first plan you see is on your first live store. See test mode.