What the customer sees: the accept page
The tokenized public page a customer opens from a sent quote link, including the pending-verification attestation step.
This is the page a customer lands on when they open the link you sent them (see Send a quote to the customer). No login — the token in the URL is the only credential. An unknown, revoked, or already-superseded link resolves to an honest "link no longer valid" page; nothing is invented.
1. What the customer reviews
The page shows the quote's route, the aircraft option(s) offered, pricing and fee breakdown, and — if your tenant uses deposits — the payment schedule. A standing disclosure is shown alongside every option:
All prices are estimates, subject to operator approval, aircraft availability, and regulatory verification. Submitting a request does not confirm a booking. Your request will be reviewed by the operator's flight desk; final pricing and availability are confirmed before any charge is made.
Each option carries a compliance pill sourced verbatim from the backend — never restyled or upgraded:
- Compliance ready — the tail's compliance check passed.
- Pending verification — the verdict is
PENDING_VERIFICATION. - Unavailable — anything else, including a suppressed (hard-blocked) result.
"Compliance ready" and "Pending verification" are not approvals and never
mean the trip is legally cleared to fly. A PENDING_VERIFICATION tail has
not been checked against live authoritative data — only against seeded or
modeled inputs. The operator completes verification separately, before
departure.
2. The pending-verification attestation
If the option the customer picks is still PENDING_VERIFICATION, they cannot
accept it silently. The page shows this notice and requires an explicit
checkbox before the Accept action becomes available:
This aircraft's compliance is still pending verification against live authoritative data. This is not a determination that the flight is compliant or authorized to operate. To proceed, acknowledge that the operator will complete verification before departure.
☐ I acknowledge the pending verification and wish to proceed.
Ticking that box and accepting writes an immutable attestation record on the backend: which gates were unverified, the acknowledging party, and when — never a claim that the trip is compliant.
An attestation is a private record of what was acknowledged — it is never a
legal or regulatory approval, and it is never described to the customer or
the operator as "FAA approved" or "compliant." A suppressed (hard-failed)
result is never offered as acceptable in the first place, attestation or
not.
3. Not ready to accept
If the customer won't tick the acknowledgment, or the offered option doesn't work for them, the page offers two non-booking paths instead of a dead end: Ask the operator a question or Request a different option. Either one notifies the operator against this quote; nothing is booked and no compliance detail is exposed to the customer beyond what's already shown.
4. After accepting
Once accepted, the page confirms the charter, shows the deposit due now (if any) and the remaining balance, and — where your tenant has Stripe deposit invoicing configured — a Pay deposit link. If no pay link is available, the page tells the customer the operator will follow up with payment instructions; it never fabricates a payment step that didn't happen.
If the accepted tail was PENDING_VERIFICATION, the confirmation restates
what was acknowledged, in the same non-approval language as step 2. If a
compliance certificate was minted for the accepted tail, the page links to
it — described as a certificate, not a clearance.
In a demo tenant, a pending-verification human gate can auto-complete
(recorded DEMO-AUTO in the same attestation ledger) so the demo flow runs
end-to-end. A real tenant's customer always ticks the acknowledgment
themselves — demo mode changes who completes the step, never whether it's
recorded or what the verdict says.