Versioning your policies and checkout statements

When a buyer disputes an order, or a reviewer asks what a buyer agreed to, the answer is the exact text that buyer saw at the moment they agreed. Today's wording does not answer that question if it has changed since. Versioning means keeping every version of your policies and checkout statements, recording when each one took effect, and linking each order to the version it used.

This guide covers why the exact text matters, what to version, what a version record should contain, and the mistakes that most often leave gaps.

Why the exact text matters

Stripe's dispute guidance says that for refund and return disputes, it is critical to show the customer agreed to and understood your terms at checkout, and it recommends a clean screenshot of how your terms are presented during checkout. Its fraud prevention guide goes further: an issuer might reject a checkbox that only contains a link as evidence the customer was aware of your policies, and there must be reasonable evidence that you presented a full copy before the purchase.

Both points assume you can produce what the buyer actually saw. If your refund policy was rewritten last month, a screenshot taken today shows the new policy, not the one in force when an older order was placed.

The same is true of tools. Stripe Checkout, for example, can require customers to accept your terms of service with a checkbox, and when they do, the Checkout Session's consent field records the terms as accepted. That tells you acceptance happened. Keeping track of which wording sat behind your terms link on that date is up to you. Stripe also advises consulting your legal and compliance advisers before changing the text shown next to that checkbox.

What to version

• Terms of sale.
• Refund and return policy.
• Shipping policy.
• Privacy policy.
• Researcher gate declarations shown at site entry.
• The research-use statement buyers sign or confirm at checkout.
• Intended-use statements on product pages.
• Order confirmation and receipt email templates, where they restate terms.

What a version record should contain

• An identifier. A version number or ID that never gets reused.
• The full text. The complete wording, not a summary or a list of changes.
• The effective date and time. When it went live, with the time zone.
• Who approved it. Ideally someone other than the person who wrote it. See compliance roles for small teams.
• What changed and why. A short change log entry.
• Where it appears. Which pages, which checkout step, which emails.
• How it was presented. A dated screenshot of the page or checkout step, so you can show layout as well as words.

Effective dates

• Decide when each change takes effect, and record it before it goes live.
• Orders placed before the change stay linked to the earlier version. Do not relink them to the new text.
• Never backdate a version. If a change went live late, record the real time.
• If a change affects terms for buyers who already have open orders or accounts, speak to a qualified lawyer about whether and how to give notice.

Link each order to the version it used

The most reliable way to answer "what did this buyer agree to?" is to store the version identifier with the order at the moment of agreement. Working it out later from dates is possible, but it depends on your effective dates being perfect and on nobody having edited a page in between.

• Store the statement version ID with the signature or confirmation.
• Store the policy versions in force with the order, or keep effective dates precise enough to work them out.
• Keep screenshots of each checkout layout alongside the version they show.

Writing a change log

A change log does not need to be long. Each entry should let someone who was not involved understand what happened. For example:

• Version 3 of the checkout statement. Added the words "will be handled by qualified personnel". Reason: align with the terms of sale. Drafted by the admin, approved by the owner, effective from the date and time recorded.
• Version 5 of the refund policy. Clarified how damaged parcels are reported. Reason: repeated buyer questions. Approved by the owner.

Common mistakes

• Editing live pages in place. The old text is gone unless someone saved it first.
• Treating small edits as non-changes. A corrected typo is still a new version. Record it, even if the change log entry is one line.
• Different wording in different places. The checkout statement, the terms page and the order email each say something slightly different. Pick one approved wording and use it everywhere.
• Screenshots without dates. An undated screenshot cannot show which period it covers.
• Pre-ticked boxes. A confirmation the buyer did not actively give is weak evidence of anything. See writing a research-use confirmation for checkout.

How Claddr handles statement versions

In Claddr, checkout statements are versioned. Changing the wording creates a new version, and every signature points to the exact text the buyer saw. Exports include the statement versions in force for the chosen date range. Policies on your own site, such as your terms of sale, are still yours to version. Buyer attestations, explained covers what a signed statement records.

What versioning cannot do

Versioning shows what was presented and when. It does not decide whether your terms are fair, clear or enforceable, and it does not make a buyer's declaration true. For the content of the terms themselves, see terms of sale for research-use-only products and have them reviewed by a qualified lawyer.