Live chat on a PrestaShop store is usually discussed as a widget problem: where do you put it, what does it look like, does it pop up at the right moment. Those are legitimate questions but they come after the one that actually decides whether your support works.
The question that decides it is this: when a customer says "where is my order", does your chat have access to the order record? When they say "I sent it back", does it know the return status? When they say "the tracking says delivered but I have nothing", does it have the carrier reference on screen?
On PrestaShop, all of that lives in the back office. The widget is a wrapper. Here is what the agent actually needs in front of them, where it sits in PrestaShop, what the chat can read without calling a person, and what has to be wired up before it can.
What PrestaShop actually holds for support
A PrestaShop installation keeps four distinct records that matter for customer support. They are not stored in one place and they do not all behave the same way when something outside PrestaShop asks for them.
The order record is the central object. It contains the items bought, the price paid, the payment status, the PrestaShop internal order reference, the customer name and email, the delivery address, and a log of status changes. Every order gets a reference like ZWXNAJHSB that the customer can quote and the agent can search for. The record also carries a customer thread: a timeline of internal notes and emails attached to that order by your team.
The carrier tracking reference is attached to the order but it does not live inside PrestaShop's own database in the way you might expect. PrestaShop records the tracking number you entered and the carrier name. The tracking data itself comes from the carrier's API or website when someone asks for an update. If you are using a module that fetches live tracking status, that module holds its own data and may expose it differently from the standard order screen.
The return status is the most variable piece. In a base PrestaShop installation, the order record shows whether a return has been initiated. A dedicated Returns (Merchandise) module, if installed, gives you a separate page under Orders with its own status workflow. Third-party returns services keep their own records and are invisible to PrestaShop unless a module connects them.
The customer profile is a separate record from the order. It shows the customer's registration details, their total order history, how long they have been a customer, and any notes your team has added. An agent handling a chat often needs to look at the profile to see whether the person asking about a missing delivery is a first-time buyer or someone with ten previous orders.
Where each piece lives in the PrestaShop back office
Here is a precise map. These are the standard back office paths in a current PrestaShop installation.
| Record | Back office path | Can a chat read it automatically? | What it needs first |
|---|---|---|---|
| Order record | Orders → Orders → select order by reference | Yes, via PrestaShop web service API | Web service enabled; API key created; endpoint permissions for orders |
| Carrier tracking number | Orders → Orders → order detail → Shipping tab | Yes, the number itself | Same API access; live status requires carrier API or tracking module |
| Return status | Orders → Orders → order detail (standard), or Orders → Merchandise Returns if module installed | Only if returns module is present and exposes it | Module and its API, or manual check |
| Customer profile | Customers → Customers → select customer | Yes, via PrestaShop web service API | Web service enabled; permissions for customers endpoint |
| Internal customer thread | Orders → Orders → order detail → Messages tab | Only the messages your team sent | API access to messages; note that customer replies via email may not be in PrestaShop at all |
The internal customer thread is the piece most likely to be incomplete. If customers email your support address directly, those replies arrive in your mailbox, not in PrestaShop. An agent reading only the back office thread will miss them unless your workflow syncs them back.
What the chat can read without a person
When a chat widget is connected to PrestaShop through its web service API, it can pull data for the customer who is currently logged in. It can also pull data for a customer who provides their email address or order reference, though that requires a lookup step that a logged-in session does not. An AI chatbot for PrestaShop can handle this data retrieval automatically during conversations.
Three things happen automatically when the connection is live.
First, the chat knows the customer is logged in. PrestaShop sessions carry the customer ID. The chat can use that to fetch the customer profile and show the agent at once: name, email, account age, total lifetime spend, number of previous orders. The agent does not have to ask for any of this.
Second, the chat can look up the most recent order by email. When a customer says "I ordered last Tuesday", the agent does not need to ask for the order number. The chat can retrieve it directly and surface it before the agent says a word.
Third, the chat can display the tracking number from the shipping tab of that order. It cannot automatically fetch the live status from the carrier's tracking page unless you have a module that does that, but the tracking number itself is available and can be presented to the customer or used to construct a carrier tracking URL.
Two things require a person or a specific setup.
Return status is the most common case where the chat hits a wall. If you have the standard PrestaShop returns module installed and it exposes data via API, the chat can retrieve the status. If you use a third-party returns service, the chat cannot see inside it without a separate connection to that service.
The internal thread of customer notes exists in PrestaShop but the chat may not have permission to read it by default. Your API key needs explicit read permission for the messages endpoint on the orders you want to surface.
What has to be connected before any of this works
The chat widget itself does not connect to PrestaShop. The system behind the widget connects to PrestaShop's web service API. Here is the sequence.
- Enable the PrestaShop web service. Go to Advanced Parameters → Web Service. Check that it is on. Generate a key and give it a name that makes sense to you. You will need this key in your chat system's configuration.
- Set API permissions. The key starts with no access. You choose which endpoints it can read. For support chat you typically need read access to: customers, orders, order_slip (refund records), and messages. You do not usually need write access for a read-only lookup tool.
- Connect the chat system to the API. Your chat platform needs a configured connection to PrestaShop using your store URL with the API endpoint appended, the key, and the endpoint permissions you set above. If the chat system is a module installed inside PrestaShop, it may handle this automatically. If it is a standalone product, it needs the connection details explicitly.
- Map customer identity. The chat needs to know which logged-in customer is chatting. In most setups this is automatic because the chat widget sits on the storefront and reads the PrestaShop session cookie. If a customer chats while not logged in, the chat can still look them up by email address if they provide it.
If you skip step two and give the key full access by default, the chat can read everything including prices and cost data you may not want exposed. Set permissions explicitly.
The questions the storefront receives most
Based on what PrestaShop stores, five question types dominate the average storefront's support load. Each maps differently to what the chat can answer automatically.
"Where is my order?" This is the single most common question on any PrestaShop store. The chat can answer it by retrieving the order status and the tracking number. If you have a tracking module that fetches live carrier status, the chat can go further and tell the customer the last recorded scan. Without that module, it can display the tracking number and a link to the carrier's tracking page, which at least saves the customer searching for it themselves.
"Can I change my order?" The chat can look up the order and check its current status. If it has not yet moved to shipment processing, the answer is yes and the chat can flag it for a team member to act on. If it has shipped, the chat can say so and offer alternatives. The chat cannot change the order itself without a write-enabled API connection and a workflow that makes the change safely.
"I sent something back. When will I hear?" This is the question that exposes the return status gap. If you use PrestaShop's returns module and it is API-accessible, the chat can retrieve the return status. If you use a third-party service, the chat cannot see inside it. The chat can still be useful by collecting the return tracking number and looking it up with the carrier, but the return's internal processing status requires either the module or a manual check.
"I want a refund." The chat can check whether a refund has already been issued by looking at the order_slip endpoint. It can confirm the refund amount, the method, and the date. It cannot process a refund itself.
"What is my account?" The chat can retrieve the customer profile entirely. It can show the customer their order history, their registered email address, their account status. This is the question type where the chat is most fully self-sufficient with a logged-in customer.
How many chats your plan covers
Asyntai counts in messages, not in chat sessions. A single support conversation between a customer and an agent typically runs to several back-and-forth messages, and a chat where Asyntai handles the first response adds a few more. The number varies by question complexity and how your routing is set up. To work out which plan fits your volume, start with the number of chats you expect in a month, multiply by the messages in an average chat, and compare the total to the plan allowance.
As a worked example: if your store runs 400 chats in a month, that is 400 multiplied by 6, which equals 2,400 messages. The Starter plan at 2,500 messages covers it. If your volume is closer to 1,500 chats a month, which is 1,500 multiplied by 6, or 9,000 messages, the Standard plan at 15,000 messages has room to spare. The Pro plan at 50,000 messages suits stores running 8,000 chats or more.
The exact message count per conversation depends on your workflow. A store where Asyntai resolves most questions in a single automated reply uses fewer messages than one where it gathers information before handing to a person. The figures above use six messages per chat as a working assumption. When you have three months of chat history, count the messages in a sample of 50 conversations and use that average instead.
What most people miss
The gap that causes the most support failures on PrestaShop is the one between what the chat looks up and what the agent knows. The chat retrieves the order. The agent sees it on their screen. But the agent does not see the note that a colleague left on the order two days ago, or the email the customer sent to the support address that arrived in the inbox but not in PrestaShop.
Customers do not think in terms of systems. They sent an email on Monday asking about a delay. They get a chat on Tuesday and the agent does not know about the Monday email. The customer repeats everything. The customer gets frustrated. The agent does not understand why.
Closing that gap is not a configuration problem inside PrestaShop or inside your chat tool. It is a workflow problem. The two places where customer history lives most reliably are the mailbox and the PrestaShop customer thread. You need one of three things: a shared inbox where the agent checks before or during a chat, a workflow that copies emails into PrestaShop as messages on the order, or a chat system that reads the mailbox directly.
Without that step, your chat is smart about the order but blind to the conversation the customer has already had with your team.
Making the PrestaShop connection
If you are setting up Asyntai on a PrestaShop store, the technical steps are straightforward. Enable the web service, create a key, set read permissions for the endpoints you need, and connect it through your Asyntai dashboard. The part that takes more time is deciding which permissions to grant and making sure your team knows what the chat can and cannot see without them.
Summary
The live chat on a PrestaShop store is only as useful as the data behind it. The widget is the easy part. The question that determines whether your support actually works is whether the chat can reach the order record, the carrier reference, the return status, and the customer thread when your agent needs them.
PrestaShop holds all of these. The order record and customer profile are available via the web service API with read permissions set correctly. The carrier tracking number is there. The return status is there only if your returns module exposes it. The customer thread is there but may need explicit API permissions and may not contain emails that went directly to your inbox.
Before you choose a chat widget, map what you want it to answer and check which PrestaShop endpoints hold that data. Then configure the API access and test it with a real order before you go live.
Sources and further reading
- PrestaShop web service documentation: how to enable and configure API access, on PrestaShop Project's own documentation site.
- Asyntai plan message allowances: published on asyntai.com/pricing/.