Which version did they see?
Your terms and policies change over time. A record that points to the current version cannot prove what was in place on the day someone agreed.
For any business that asks people to agree to something
The problem is not asking for agreement.
The problem is proving it later.
99zebras keeps each acceptance as a clear, timestamped record you can produce when asked.
- Chargeback & dispute evidence
- GDPR Art. 7
- CCPA / CPRA
- FINRA & SOX
- e-discovery
The gap
The questions a checkbox cannot answer
Most businesses already have terms, policies, refund rules, onboarding agreements, or consent language. A checkbox at signup or checkout may show that someone clicked. It often does not prove what they were shown, which version applied, when it happened, or whether the record has changed since.
That gap usually stays invisible until there is a dispute, audit, chargeback, complaint, or legal request. By then, it is too late to reconstruct the record properly. When an acceptance is challenged, the real questions are more specific.
What exactly was on the screen?
A policy link is not the same as the words shown to the customer, user, vendor, or employee at the time of acceptance.
When and where did it happen?
The record should show the time, the flow it came from, and the surrounding context: checkout, signup, renewal, policy update, onboarding, or another process.
Can anyone tell if the record changed later?
A useful record should be difficult to quietly edit. If the text, timestamp, or acceptance details are altered, that should be obvious.
Your policy page only shows the version that is live today. It cannot show which version a customer accepted, or when they accepted it.
Who it helps
The record is the same. What it protects depends on your business.
Online stores & growing businesses
Better evidence for the disputes you currently have to absorb
If you sell online, you probably already have a returns policy, refund policy, shipping policy, and terms page. What many stores do not have is proof that a particular customer accepted a particular policy before they paid.
That matters when a customer says they never agreed to the return window, refund condition, subscription term, delivery rule, cancellation policy, or custom-order condition.
Without a proper acceptance record, you are often left pointing to a policy page that exists today. That may not be enough to show what the customer accepted at checkout.
99zebras gives you a record you can use in support conversations, customer disputes, and chargeback responses: this customer, this policy, this version, this time.
It does not guarantee the outcome of every dispute. It gives you better evidence than a normal checkbox, a policy link, or a screenshot taken after the fact.
Useful for
- Returns and refund policies accepted at checkout
- Subscription, cancellation, and renewal terms
- Custom-order, made-to-order, or final-sale conditions
- Chargeback and customer dispute responses
- Reducing casual “I never agreed to that” claims
Without a record to point to, these disputes are usually lost. Each one costs the refunded sale, the chargeback fee, and the staff time spent contesting it.
Regulated & enterprise teams
Give counsel the record, not a reconstruction project
For larger teams, the acceptance record may need to satisfy people outside the product team: legal, compliance, audit, regulators, procurement, or opposing counsel.
Those people are not looking for a database row that says “accepted: true”.
They need to know what was shown, which version applied, when it was accepted, how the record was preserved, and whether it can be checked without relying only on your internal systems.
99zebras turns each acceptance into a record with the relevant terms, version, timestamp, subject reference, context, and verification details kept together.
Retention rules can be set by policy. Legal holds can preserve specific records when needed. Access and changes are logged. Records can be exported when your team needs to respond to an audit, dispute, investigation, or legal request.
Useful for
- Customer, vendor, employee, or platform agreements
- Consent records and policy acknowledgements
- Regulated onboarding and account flows
- Evidence packs for legal and compliance teams
- Long-term retention and legal holds
- Audit trails around record access and export
When someone asks for proof, your team can produce the record instead of reconstructing what happened from logs, emails, and old policy versions.
Why use a dedicated system
Why not just build this yourself?
You can. Many teams start there. At first, it looks simple: save the user ID, timestamp, IP address, and a policy version. The hard part comes later.
It is a versioning problem before it is a storage problem.
Your terms keep changing. Your record needs to stay tied to the exact version accepted, not whatever the policy page says today.
The record matters most when someone does not trust you.
If the other side questions your evidence, “because our database says so” is not always persuasive. The record needs to be verifiable outside the normal application flow.
It has to survive years of ordinary business activity.
Teams change. Databases are migrated. Admins edit things. Policies are rewritten. Evidence needs to remain understandable and intact long after the original checkout, signup, or onboarding flow is gone.
It is easy to underbuild until the day it matters.
The cost of doing this properly is usually invisible. The cost of not doing it appears all at once: a lost chargeback, a failed audit, an urgent legal request, or a dispute your team cannot answer cleanly.
99zebras exists so your product, engineering, support, and compliance teams do not have to design and maintain this system themselves.
What is in a record
The details you need later, kept together
Every acceptance becomes a record your team can open, export, or share. It includes:
The point is not to collect more data than necessary. The point is to keep the right evidence in the right shape before anyone asks for it.
- 01
The exact terms accepted
The policy or agreement version tied to the acceptance, so the record does not drift when your live page changes.
- 02
The moment of acceptance
A server-side timestamp showing when the acceptance happened.
- 03
The subject and context
The customer, user, account, order, checkout, signup, or other reference you choose to attach.
- 04
The surrounding evidence
Information such as the flow, network context, user agent, and other details useful when reconstructing what happened.
- 05
A tamper-evident seal
A way to detect whether the record has been changed after it was created.
Enforceability
What courts look for when an agreement is challenged
Electronic acceptance is recognised by law in most places — the E-SIGN Act and UETA in the United States, eIDAS in the European Union, and similar laws elsewhere. But recognition is not the same as enforceability. When an agreement is challenged, a court does not ask whether you collected a click. It asks whether this person was clearly shown the terms, took a deliberate step to accept them, and whether you can still produce an unaltered record of it.
The terms were clearly shown.
The person has to see the actual terms, not a link tucked at the bottom of a page.
99zebras records the exact version and rendered text that was on the screen.
Acceptance was a deliberate act.
A pre-ticked box, or a “by continuing you agree” line, is weaker than a clear, affirmative action to accept.
The record captures the acceptance and the moment it happened.
The record has not been quietly changed.
The court needs confidence the terms, the timestamp, and the details are the same as the day of acceptance.
Each record is sealed and tamper-evident; any change breaks verification.
You can actually produce it.
On a deadline, you have to hand over a record someone else can check.
Every record has a verification link anyone can open, with no account.
The cost of getting it wrong
When one of these fails, the result is not a warning. The clause you were relying on — an arbitration agreement, a liability cap, a refund condition, an auto-renewal term — can be set aside, and you are left arguing the case without the protection you thought you had. Clickwrap agreements have been refused enforcement for exactly these reasons: terms shown too faintly, acceptance that was not clearly affirmative, or a record that could not be produced intact. (Courts as far back as Specht v. Netscape have declined to enforce agreements where the user was not clearly put on notice or did not clearly assent.)
This is background, not legal advice — the standard varies by jurisdiction and by case, and your counsel is the authority on what your agreements require.
Verification
A record should not depend on your word alone
Every 99zebras record can include a verification link. That means a support team, auditor, bank, customer, lawyer, or other reviewer can check that the record exists and has not been altered.
They do not need access to your admin system. They do not need to ask an engineer to query a database. They do not need to rely on a screenshot. They can open the record and check it directly.
That is the difference between “we believe this happened” and “here is the record”.
Sign up freeVERIFICATION
Recordrcd_8K42Q9…
Terms hashsha256:7c2a9d4f…
TimestampRFC 3161 · independent
Intact and unaltered
99zebras
Set it up before the first dispute
The best time to create proper acceptance records is before anyone asks for them.
- Not during a chargeback.
- Not during an audit.
- Not after a customer complaint.
- Not when legal is already chasing the answer.
99zebras gives you a simple way to start keeping better records now, without building the system yourself.