How to require consents at checkout
Require buyers to accept legal texts (such as image and voice usage) before completing a purchase, then review and export the evidence of who accepted.
You can require every buyer to accept one or more legal texts before completing a purchase — for example, an image and voice usage authorization, for when you photograph or film the event. Each acceptance is recorded together with the exact text the person read, and you can review and export that evidence later.
The texts are written and versioned by Baila, not by the organizer. You choose which ones each event requires; the wording itself is standardized so it holds up legally. Need a text that doesn't exist yet? Talk to Baila.
Choosing consents while creating the event
Consents is step 4 of the creation wizard, between Ticket batches and Review.
Create the event as usual until you reach the Consents step.
The list shows the texts available for your country. Each item has a summary and a view text link — which opens the preview already filled in with your organization's name and your event's name, exactly as the buyer will read it.
Tick the ones this event requires. A counter shows how many you selected.
Click Continue. The selection is saved at that moment — if you leave and resume the draft later, it is still ticked.
The Review step lists the chosen consents before you publish.
Changing it after publishing
The event page has a Required consents section. Tick or untick and save — it applies to future purchases. People who already bought are not asked again, and the record of what they accepted stays untouched.
Editing the list requires the events.write permission. Anyone without it (the Check-in role, for example) sees the section read-only, showing the texts already required.
On closed or canceled events the list is read-only — you can still see what was required, but not change it.
What the buyer sees
In the checkout summary — on the web and in the app — a block appears with one row per consent:
- a checkbox with the title of the text;
- a Read full text link, which opens the whole text already filled in with your organization's name, the event, the venue, the date and the buyer's own name;
- the confirm button stays disabled until every box is ticked.
The block is not just visual: even if someone bypasses the interface, the order is rejected on the server, and no ticket is ever issued without the consent on record.
Reviewing and exporting the evidence
Also on the event page, the Consent evidence section lists every acceptance with:
| Column | What it shows |
|---|---|
| Date | when the person accepted |
| Buyer | name and email given at purchase |
| Template / version | which text, and which version of it |
| Language | the language the text was displayed in |
| IP and Country | where the acceptance came from |
| Platform | web, iOS or Android |
| Device | identifier of the device used |
You can filter by text, language, date range, and search by name or email. The date filter uses the event's timezone — asking for "August 26" gives you the 26th where the event takes place.
The Export CSV button downloads consent-evidence-<event-id>.csv with one line per acceptance, ready for a spreadsheet or to attach to a legal request.
Viewing and exporting evidence requires the orders.read permission — the same one used to see orders. For anyone without it, the section doesn't appear at all.
In the event's Orders table, a Consents column marks the orders that have a recorded acceptance with a ✓.
Using the record as proof
Every acceptance creates one record per consent on each order — an order that required two texts creates two records. Each record holds the exact text that appeared on that person's screen, already filled in with their name, your organization's, the event's, the venue and the date. It is not a link to the template: it is a copy frozen at the moment of purchase, which no later version rewrites.
Stored alongside the text: the language it was displayed in, the version accepted, the name and email given at purchase, the date and time, and the text's fingerprint (a SHA-256 hash).
Viewing the text of one acceptance
In the Consent evidence section, every row has a View text button. It loads the text for that specific acceptance, on demand — the full text does not travel with the table or the CSV, precisely so the listing stays light and personalized texts are not shipped in bulk.
The panel shows the text in full, the language, the version and the SHA-256 hash, with a button to copy the text.
Proving the text was not altered
The hash is a fingerprint of the text: any change, even a single character, produces a completely different code. Because it is recorded at purchase and never recalculated, you can demonstrate to a third party that the text you are showing today is exactly what the person accepted.
This is optional. For most situations it's enough to click View text, copy the text and the hash, and hand them over. The check below exists for when the other side — a lawyer, an expert witness, a company's legal team — wants to confirm for themselves that nothing changed. If that's not your situation, feel free to skip it.
Where to type these commands
The commands below don't go into Baila or your browser: they go into a program that already comes installed on your computer.
- On a Mac: open Terminal — press
Command + Space, typeTerminaland hit Enter. - On Windows: open PowerShell — press the
Windowskey, typePowerShelland hit Enter. (The older "Command Prompt" won't run these; use PowerShell.)
A window opens with a blinking cursor. That's where you paste the command and press Enter. Nothing here changes anything on your computer or in Baila — the commands only read what you copied and compute the code.
Step by step
In the dashboard, click View text on the acceptance in question, then Copy text.
Open Terminal (Mac) or PowerShell (Windows), as above.
Paste one of the commands below — the one for your system — and press Enter.
On Mac:
printf '%s' "$(pbpaste)" | shasum -a 256On Windows (PowerShell):
$t = Get-Clipboard -Raw
$h = [System.Security.Cryptography.SHA256]::Create().ComputeHash([System.Text.Encoding]::UTF8.GetBytes($t))
($h | ForEach-Object { $_.ToString('x2') }) -join ''The program prints a long string of letters and numbers. Compare it with the Text hash (SHA-256) shown in the panel: if they match, the text is intact.
Got a different result? It's almost never tampering. The two usual causes are invisible to the naked eye:
- One extra line break at the end. That's why the commands above compute the code straight from
what you copied, without going through a file. If you'd rather save to a file, make sure it does
not end on an empty line (on Mac, use
printf '%s', neverecho). - The file saved as "UTF-8 with BOM" — an invisible marker some Windows programs add at the start, which changes the code completely.
Redo it with the exact command above before concluding anything.
Querying outside the dashboard
If you need to reconcile acceptances with your own systems, the same information is on the API, behind the same permission as the dashboard (orders.read):
| For | Endpoint |
|---|---|
| List the event's acceptances (paginated, same filters as the table) | GET /api/events/{eventId}/consent-acceptances |
| Download everything as CSV | GET /api/events/{eventId}/consent-acceptances/export |
| Get the full text of one acceptance | GET /api/events/{eventId}/consent-acceptances/{acceptanceId} |
The listing and the CSV carry every field except the text; the text comes only from the single-acceptance call, one at a time. The buyer's tax document is never returned by any of the three — it shows masked in the table and is absent from the CSV.
When a text gets a new version
Baila may publish a new version of a text (to correct wording, for instance). When that happens:
- the new version applies from the next purchase onward;
- people who already bought are not asked again;
- each record keeps the exact version and text that person accepted — a new version never rewrites the past.
If someone is mid-checkout when the version changes, the app tells them the text was updated and asks them to accept again, with the new text.
How long the record is kept
Consent records are legal proof, so they are never deleted — not even when the buyer deletes their own account. In that case the account is anonymized, but the record keeps the name and email given at purchase, so you can still identify who signed.
This follows Brazil's LGPD: the controller must be able to prove the consent it obtained (art. 8, § 2). For image and voice texts, you are the controller of that data and Baila acts as the processor, holding the proof.
Frequently asked questions
Can I write my own consent text? Not yet. The texts are written and versioned by Baila so they hold up legally. Get in touch if you need one that doesn't exist yet.
Does requiring consent hurt conversion? It's two extra clicks on the summary (ticking the box; reading the text is optional). There's no new step and no redirect.
Does it work on free events? Yes. The requirement applies to every payment method — free, Pix or card — and is checked before payment.
What if I untick a consent after selling tickets? Future purchases stop requiring it. Acceptances already recorded stay available to review and export.
Is the text shown in English to international buyers? Yes. The text is shown in the language of the purchase, and the record stores which language it was displayed in.
Can I delete a consent record? No, and that's deliberate: a record you can delete is no proof at all.
Where is the text the person accepted stored? In one record per consent on each order, holding the full text already filled in with the real data — not a link to the template. See Using the record as proof above.
Why isn't the text in the CSV?
To keep the export light and to avoid shipping every buyer's personalized text in bulk. The CSV carries
a body_sha256 column identifying each acceptance's text; the text itself you open one at a time with
View text.
What exactly is the SHA-256 hash? A fingerprint of the text. It proves the text hasn't changed since the purchase — it doesn't hide the content. It is recorded at acceptance time and never recalculated.
My hash came out different. Was the record tampered with?
Almost certainly not: the usual cause is one extra line break at the end of the file you created. Redo
it with printf '%s' as shown above before concluding anything.
Does the buyer's tax document appear anywhere? Not in the clear. It is stored encrypted, shows masked in the evidence table, and is neither exported in the CSV nor returned by the API.