# Terms and conditions versioning and acceptance proof: documentation

> Installation Install the module from Modules > Module Manager > Upload a module by sending the ZIP file, or copy the dftermsversion folder into the /modules/ directory of your shop…

- Page: <https://www.datafirefly.com/en/documentation/dftermsversion/>
- Language: en
- Last updated: 2026-09-30
- Other languages: [fr](https://www.datafirefly.com/documentation/dftermsversion/index.md), [es](https://www.datafirefly.com/es/documentation/dftermsversion/index.md), [de](https://www.datafirefly.com/de/documentation/dftermsversion/index.md), [it](https://www.datafirefly.com/it/documentation/dftermsversion/index.md), [pl](https://www.datafirefly.com/pl/documentation/dftermsversion/index.md), [nl](https://www.datafirefly.com/nl/documentation/dftermsversion/index.md), [pt](https://www.datafirefly.com/pt/documentation/dftermsversion/index.md)
- Index: <https://www.datafirefly.com/en/documentation/llms.txt>

## Installation

Install the module from **Modules > Module Manager > Upload a module** by sending the ZIP file, or copy the `dftermsversion` folder into the `/modules/` directory of your shop and click Install.

On installation, the module creates its tables, adds two tabs under the **Orders** menu (**Terms versions** and **Acceptance register**) and imports the content of your terms CMS page as a draft. Nothing is visible to your customers yet: no version is in force until you publish one.

Make sure the terms of service checkbox is enabled in **Shop Parameters > Order Settings**. Without it, customers tick nothing before paying and the evidence is weaker. The module configuration page warns you if it is disabled.

## Publishing your first version

Open **Orders > Terms versions**. The imported draft is listed with the Draft status. Click it to read it in every language, then click **Edit** if needed.

### Version fields

- **Version number**: the label shown to customers, for example 2026-10 or 4.2. It must be unique.
- **Title and text**: per language. A language left empty takes the text of the default language on publication.
- **In force from**: leave empty to apply the version as soon as it is published. A future date schedules the change. A past date adds an earlier version to the history (see below).
- **Change summary**: shown in the public version history.

Then click **Publish**. The version is locked: its text, its SHA-256 fingerprint and its PDFs, generated in every language, can no longer change. If timestamping is enabled, the module immediately requests a timestamp from the configured authority.

A published version can no longer be edited or deleted. That is what gives it value as evidence. Read the draft carefully before publishing.

## Changing your terms

From a published version, click **Create a new version from this one**. A draft is created with the same text. Edit it, fill in the change summary, choose the effective date, then publish.

### Comparing two versions

On a version page, the **Compare** block suggests the previous version by default, or the version in force when you are on a draft. Click **Show the changes**: modified, added and removed paragraphs are highlighted, word by word for modified paragraphs, and unchanged paragraphs are collapsed. Switch languages with the buttons at the top right.

### Scheduling a change

A version published with a future date has the Scheduled status. It becomes the version in force automatically on that date, with no cron task. The configuration page shows the next scheduled version.

## What the customer sees

- **At payment**: above the payment methods, a notice shows the version in force, its date and a link to its PDF, plus a link to previous versions if the public history is enabled.
- **In the confirmation email**: the PDF of the accepted version is attached to the `order_conf` email.
- **In their account**: the details of each order show the accepted version with a download link.
- **On the invoice**: a mention of the version and its fingerprint, if the option is enabled.

## What the module records on each order

When the payment step is displayed, the module notes the version shown to the customer, with their IP address, browser and the time. When the order is validated, it records the version shown, the SHA-256 fingerprint of the text in the customer's language, and this display information.

If no display was traced, for example with a checkout that does not call the `displayPaymentTop` hook, the module records the version in force on the order date with the recording method "Order validation". An order created in the back office is recorded with the method "Back office".

## Viewing the evidence for an order

On the back office order page, the **Accepted terms and conditions** card shows the version, the dates, the IP address, the recording method, the text integrity check and the position of the order in the register. Three buttons:

- **Evidence pack (ZIP)**: the file to send in a dispute (details below).
- **Acceptance certificate (PDF)**: a document listing all recorded data, followed by the full accepted text.
- **Accepted terms (PDF)**: the PDF of the version, as attached to the email.

### Contents of the evidence pack

- `01-acceptance-certificate.pdf`: the acceptance certificate.
- `02-...pdf`: the PDF of the accepted version.
- `03-accepted-text.txt`: the exact source text. Its SHA-256 equals the fingerprint recorded with the order.
- `04-version-timestamp/`: the version manifest and its `.tsr` timestamp token.
- `05-register/`: the order's register entry, an extract of the chain (identifiers and fingerprints only, no data about other customers) and the seal that covers it.
- `README.txt`: an explanation of each file and the verification commands, in the employee's language.

## The sealed register

Each acceptance contains the fingerprint of its content and the fingerprint of the previous acceptance. Changing, inserting or deleting a record afterwards breaks this chain. In **Orders > Acceptance register**, the **Verify the register** button recomputes the whole chain and shows the first altered entry, if any.

### Seals

A seal has the authority timestamp the fingerprint of the latest register entry. It proves that the whole register up to that entry existed on that date, and it also reveals the deletion of the latest entries. Click **Seal now**, or schedule the URL shown in the **Automatic sealing** block once a day in a cron task:

```
0 3 * * * curl -s "https://your-shop.com/module/dftermsversion/cron?token=..." > /dev/null
```

The URL only seals the register when new entries were recorded since the last seal.

## Third party timestamps

An RFC 3161 timestamp has an independent authority sign a fingerprint together with the date. The module uses it for each published version (on a manifest listing the fingerprint of the text in every language) and for register seals.

By default the module uses `http://timestamp.digicert.com`, free and without an account. You can set another authority in the configuration, for example `https://freetsa.org/tsr` or a qualified eIDAS authority. The shop server must be able to reach the authority.

If the authority does not answer on publication, the version is published anyway. The error is shown on the version page, with a **Timestamp now** button to try again.

## Existing shop: history and past orders

To cover orders placed before installation:

1. Publish the current version of your terms first.
2. Create one version per earlier version of your terms, with its real effective date in the past, and publish it. The module only refuses a past date when orders already linked to another version fall within that period.
3. In **Orders > Acceptance register**, the **Past orders** block shows how many orders are not linked to any version. Click **Link these orders**: processing runs in batches with a progress bar.

These orders get the version in force on their date and are marked **Linked afterwards**, with no IP address or display trace. The module does not claim what it did not observe: these links indicate the applicable version, they are not proof of display.

## Module settings

- **Attach the PDF to emails** and **Email templates**: `order_conf` by default, you can add for example `payment` or `bankwire`.
- **Show the version at payment**: the notice above the payment methods. When disabled, the module still traces the version displayed.
- **Mention on invoices**.
- **Public version history**: a page listing the published versions with their PDFs.
- **Update the CMS page automatically**: when a version takes effect, its text replaces the content of the chosen CMS page, so that the checkout checkbox always links to the right version. The **Update the CMS page now** button forces the synchronisation.
- **Anonymise IP addresses**: keeps only the network part of the IP address.
- **Third party timestamping** and **Timestamping authority**.
- **GDPR erasure requests**: see below.
- **Delete all data on uninstall**: disabled by default. Keep it disabled, your versions and register are your evidence.

## GDPR

The module hooks into the official PrestaShop GDPR module (psgdpr). A customer's acceptances are included in their data export. For erasure requests, two options:

- **Keep the evidence** (default): records are kept, which GDPR article 17.3.e allows to establish, exercise or defend legal claims. Mention it in your privacy policy.
- **Erase the IP address and browser**: these fields are cleared. The register stays verifiable and a fingerprint computed at erasure protects the remaining fields, but the evidence is weaker for that customer.

## Troubleshooting

### The notice does not appear at payment

Check that a version is in force and that the display option is enabled. If your theme or checkout module does not call the `displayPaymentTop` hook, orders are recorded with the version in force on the order date.

### The PDF is not attached to the email

Check the **Attach the PDF to emails** option and the exact template name. Some payment modules send their own confirmation email under another template name: add it to the list.

### Timestamping fails

The error message gives the cause. Most often the host blocks outgoing connections. Try another authority or ask your host to allow access to the authority's address. The PHP cURL extension is recommended.

### Register verification reports an alteration

The message gives the entry concerned and the type of problem: modified content, entry inserted or deleted before it, or sealed entry missing. Restore the `dftv_acceptance` table from a backup taken before the alteration, then run the verification again.

## Compatibility

- PrestaShop 8.0 to 9.x, the same ZIP covers both branches.
- Multistore and multilingual.
- PDFs generated with the TCPDF library built into PrestaShop, PHP zip extension required for the evidence pack.
- ModuleAdminController architecture, no Composer dependency.
- Interface available in English, French, Spanish, German, Italian, Dutch, Polish and Portuguese.