Terms and conditions for your store: what must be included

Last reviewed: June 2026. Back-office paths reflect PrestaShop 1.7, 8 and 9; legal points are dated where the date matters.

This is general information, not legal advice. Your terms are your own responsibility, a CMS page and a checkout checkbox enforce a document, they don't draft a compliant one for you. For a multi-country, B2B or subscription store, have the text reviewed by a lawyer who does e-commerce; the cost is small next to one regulator complaint.

Terms and conditions are the least glamorous page in your store and the one you'll be glad you got right the first time a customer disputes a charge, refuses a return, or files a complaint with a consumer authority. In the EU they're not optional, and "I copied them from a bigger store" is exactly the answer that turns a minor disagreement into a losing one. The good news for PrestaShop merchants: the platform already gives you a place to put them, a way to make customers agree to them at checkout, and the hooks to enforce that agreement. This guide is about what belongs in the document and how to wire it into PrestaShop properly, not the cookie banner, not the privacy policy, not the full returns workflow, which are their own jobs with their own pages on this blog.

What "terms and conditions" actually means in PrestaShop

It helps to separate two things that merchants routinely conflate. There is the document. The contract text setting out who you are, what the customer is buying, and the rules of the sale. And there is the consent mechanism, the "I agree to the terms of service" checkbox a customer ticks before they can place an order. PrestaShop handles the first as a CMS page and the second as a core checkout setting, and they are linked by a single configuration value. Get both halves right and PrestaShop will enforce acceptance of the terms at checkout, but be aware that core doesn't store a per-order copy of the exact terms version accepted, so if you need to prove which text a customer agreed to, date and version your terms and archive each version (or use a module that records it).

The document itself lives as an ordinary CMS page under Design → Pages (the CMS controller). A fresh PrestaShop install ships a placeholder "Terms and conditions of use" page. That placeholder is the single most common compliance gap we see, because it reads as real to a busy owner who never opens it. It is Lorem-ipsum-grade filler. Replace it.

The legal minimum your terms must cover (EU)

EU consumer law requires that certain information reach the customer before they're bound by the contract. Some of it is satisfied by your product pages and checkout; the rest belongs in the terms. At minimum, the document needs to cover:

• Business identity: full legal trading name, registered address, email and a phone number. A PO box doesn't satisfy this. Your actual registered address does. (In Germany this overlaps with the separate Impressum obligation; see the EU e-commerce law guide for the country-by-country picture.)
• What's being sold and the total price: the essential characteristics of the goods, and the all-in price including VAT plus any delivery or handling charge, no figure that only appears for the first time at the payment step.
• Payment and delivery: which methods you accept, when payment is taken, the delivery timeframe and who bears shipping cost.
• The 14-day right of withdrawal: that it exists, how to use it, and any product categories it doesn't apply to. This one has teeth, covered below.
• Legal guarantee of conformity: the EU's mandatory minimum two-year liability for goods that don't match what was sold, kept distinct from any commercial warranty you choose to add on top.
• Complaint handling and dispute resolution: how a customer raises a problem, plus a reference to the applicable national alternative dispute resolution (ADR) or consumer complaint body where required.

So what? Missing or burying any of this isn't a style problem, it shifts legal rights toward the customer. The clearest example: fail to properly inform a buyer of their withdrawal right and the cancellation window doesn't stay at 14 days, it stretches to 12 months. A vague terms page can mean accepting returns most of a year after a sale you thought was final.

The withdrawal right is the clause that bites, get it exact

The 14-day cooling-off period is the part of your terms most likely to be tested, so it deserves its own precise wording rather than a hand-wave. Your terms should state plainly that the right exists, explain how a customer exercises it (email, a form, or a letter), make the EU model withdrawal form available, commit to refunding within 14 days of being informed of the withdrawal (for goods, you may withhold the refund until you have received the goods back or the customer has supplied proof of having sent them, whichever is earlier), and say clearly who pays return postage. You're allowed to put that on the customer, but only if you've told them so in advance.

You should also state your exceptions honestly: custom-made or personalised items, sealed hygiene products once unsealed, perishables, and digital downloads the customer agreed to start before the period ends are all genuinely exempt. List the ones you actually rely on; don't claim blanket exemptions you can't support. The withdrawal right intersects with how your returns are actually processed in the back office, which is a deeper topic in its own right, see distance selling and the right of withdrawal and, for the day-to-day handling, what a returns policy must require.

Wiring the terms into PrestaShop's checkout

A terms page nobody agreed to proves nothing. PrestaShop's value here is that it can force agreement and record it. Two settings turn it on, both in Shop Parameters → Order Settings on the General tab:

• Enable terms of service, the toggle stored as the PS_CONDITIONS configuration value. Switch it on and the checkout's payment step grows an "I agree to the terms of service" checkbox the customer cannot skip.
• Page for the terms and conditions, a dropdown stored as PS_CONDITIONS_CMS_ID, pointing the checkbox's link at the right CMS page. This is where merchants slip: they enable the checkbox but leave it aimed at the placeholder page, so customers are agreeing to Lorem ipsum.

Under the hood the core class ConditionsToApproveFinder reads PS_CONDITIONS; when it's on, it builds the default checkbox from the CMS page named by PS_CONDITIONS_CMS_ID and refuses to let the OrderController validate the order until the box is ticked. You don't need to touch any of this code, but knowing it's enforced server-side, not just by front-end JavaScript, is the reassurance: a customer can't bypass the agreement by disabling scripts.

One detail worth knowing if you sell more than one product type or operate B2B: that same class runs a PrestaShop hook, termsAndConditions, so a module can add additional consent checkboxes (a separate withdrawal-form acknowledgement, an age-verification tick, B2B-specific terms) alongside the default one. Each checkbox carries an identifier, and a later one with the same identifier overrides the earlier. Which is how a module cleanly replaces the stock checkbox instead of duplicating it. The practical upshot: you're not stuck with one all-or-nothing terms box, and adding a second consent doesn't mean editing core files.

Multilingual and multistore: where the placeholder bites twice

Because the terms live in a CMS page, they inherit PrestaShop's translation model: a CMS page has a separate body per installed language. If you sell into France, Germany and Poland, the terms page has a French, German and Polish version, and PrestaShop will happily serve an empty or English tab to a French customer if you only filled in one. A "Terms" link that resolves to a blank page in the customer's language is, legally, no terms at all. Check every active language tab on the page, not just your default.

Multistore amplifies this. PS_CONDITIONS and PS_CONDITIONS_CMS_ID are both multistore-aware configuration values, so each shop in a multistore group can point its checkbox at its own terms page. That's correct and useful, a B2C shop and a B2B shop in the same group should reference different terms, but it means "I set it up once" isn't true. Set the page, and the two settings, per shop and per language.

Don't let your terms swallow the other policies

The instinct to make terms and conditions a single mega-document is understandable and wrong. PrestaShop treats privacy, cookies, returns and shipping as distinct concerns, and so does the law. Bundling them makes each harder for a customer to find and harder for you to update without re-touching everything. Keep them as separate, individually linkable pages:

• Privacy policy (GDPR): what data you collect, the legal basis, who you share it with, retention and customer rights. This is a separate document with its own obligations. Start with GDPR for online stores and, for the PrestaShop specifics, GDPR and cookie compliance for PrestaShop.
• Cookie consent: the banner and what counts as valid consent is its own legal test, see what cookie consent actually requires.
• Shipping and returns: customers look for these before buying, so give them a findable standalone page rather than burying delivery times and return steps in clause 14 of the terms. The mechanics live in returns and refunds.
• Price presentation: how you show net, gross and unit prices is a compliance area of its own, price display rules in Europe.

Your terms can, and should, reference these pages. They shouldn't reproduce them.

The mistakes that cost real money

Writing terms people can actually read

Compliance and readability aren't in tension. The law wants the required information present and clear; it does not demand intimidating legalese, and intimidating legalese tends to reduce the chance a customer can be said to have genuinely understood what they agreed to. Use the same structure you'd use for any good page: headings, short paragraphs, and the points customers care about, returns, delivery, guarantees, pulled to the front. A terms page a customer can skim and follow is both more compliant and a small trust signal at the exact moment they're deciding to pay.

For a small, single-country B2C store, a solid EU-compliant template adapted carefully to your business is usually enough. The moment you add real complexity, selling into several EU countries, B2B alongside B2C, subscriptions or digital goods, the cost of a lawyer who does e-commerce is small next to a single regulator complaint about a missing withdrawal notice. If that complexity describes you, the neighbouring guides are the natural next stops: cross-border returns, B2B e-commerce with PrestaShop, and the VAT obligations that travel with them in VAT in the EU: OSS and IOSS.

FAQ

Can I just copy a template or another store's terms?

A solid EU-compliant template is a reasonable starting point for a small single-country B2C store, but adapt it to your actual catalogue, countries, payment methods and return policy before it goes live. Copying another store's terms verbatim is the failure mode in the mistakes table: their document references products, obligations and jurisdictions that aren't yours, and a clause that doesn't fit can be worse than a missing one. The moment you add real complexity (several EU countries, B2B alongside B2C, subscriptions, digital goods), have it reviewed by a lawyer.

Does enabling the terms checkbox prove a specific customer agreed to a specific version?

It proves they ticked the box at checkout, PrestaShop enforces that server-side via ConditionsToApproveFinder and the OrderController, so a customer can't bypass it by disabling JavaScript, and the order timestamps when they did it. What core does not do is store a per-order copy of the exact terms text that was live at that moment. So if you may need to prove which wording applied to an order, date and version your terms and archive each version yourself, or use a module that records the accepted text against the order.

Should privacy, cookies and returns go inside the terms document?

No. Keep them as separate, individually linkable CMS pages, the law treats privacy, cookie consent, returns and price presentation as distinct concerns, and bundling them makes each harder for a customer to find and harder for you to update. Your terms can and should reference those pages; they shouldn't reproduce them. The linked GDPR, cookie-consent and returns guides cover each on its own page.

Is an "all sales final / no refunds" clause valid in the EU?

No. The 14-day right of withdrawal under the Consumer Rights Directive (2011/83/EU) cannot be waived for distance B2C sales, so a blanket "no refunds" clause is void and signals to a regulator that the rest of the document is untrustworthy. Replace it with a compliant withdrawal clause plus the genuine exemptions you actually rely on (custom-made, unsealed hygiene goods, perishables, started digital downloads). The mechanics are in distance selling and the right of withdrawal.

Can a module add a second consent checkbox without editing core?

Yes. The same core class runs a PrestaShop hook, termsAndConditions, so a module can add additional consent checkboxes (a separate withdrawal-form acknowledgement, an age-verification tick, B2B-specific terms) alongside the default one. Each checkbox carries an identifier, and a later one with the same identifier overrides the earlier. Which is how a module cleanly replaces or supplements the stock checkbox without touching core files. You're not limited to a single all-or-nothing terms box.

Terms and conditions won't make a sale. But they're the page that decides whether a dispute goes your way or the customer's, and PrestaShop already hands you the parts to do it properly: a real CMS page in every language, the PS_CONDITIONS checkbox to force agreement (enforced server-side), and the order timestamp to mark when the customer placed it, and for stronger proof of the exact text accepted, add version archiving or a module that records it. Spend an afternoon on it once and stop thinking about it, until you're glad it's there.