Buying a ticket
How Anna buys a ticket on Example Tickets: the review screen, the wallet's payment prompt, the ticket arriving in her wallet as something she holds, and the ticket on the night.
Anna pays once, in her wallet, and the ticket arrives in her wallet. The site never holds a card, a balance or a standing right to charge her. The ticket is a token: an output her wallet holds, which she can show at the door, give to someone, or keep after she stops using the site. Holding tokens sets out what that means for the design.
The review screen
The review screen answers three questions before anything else: what the ticket is, what it costs, and who is paid.
- What: "1 standing ticket, The Corner Room, Sat 14 November, doors 19". Under it, "Over 18: checked" or "Show ID at the door", from the age step.
tip
- How much: "£12.00 (24,000 sats)", with a small "at today's rate" note. The sats figure is the one the wallet will show.
- Who is paid: "Paid to Example Tickets, for The Corner Room."
- What she gets: "Your ticket will be kept in your wallet. You can give it to someone else. Not refundable."
There is one button, Pay with your wallet, and no fee line, unit picker or advanced section. The price leads in pounds because the venue set it in pounds. The sats amount is what is actually paid, so it sits beside the price rather than in small print. See Lead with local currency.
Do
Show on the review screen the same sats amount the wallet's prompt will show, and if the rate moves before Anna presses the button, update the figure on this screen first rather than letting the wallet show a different number.
Do
Name who receives the money and who the ticket is for in one line. Anna is paying the ticket site, for a venue, and both names belong on the screen.
Do
Say on the review screen what Anna can do with the ticket afterwards, give it away or not, refund it or not, before she pays rather than in the terms.
Don't
Add a booking fee or any other charge after the review screen. If the product charges one, it is part of the price shown here.
Paying
Pressing the button opens Bitcoin SV Wallet's payment prompt. It shows the verified site, the amount from the request ("about £12.00", with "24,000 sats" beside it), "One-time payment", what it is for, and that it cannot be undone (see Design the permission prompt).
Because this is Anna's first ticket, the same prompt carries one more item, which she can decline on its own: "Keep tickets from Example Tickets in a list it can read." That is a basket, and it lets the site show Your tickets later. If she declines it, the payment still goes ahead and the ticket still arrives. The site then shows her orders from its own records instead of reading the wallet.
The site shows "Waiting for your wallet…" until the wallet answers. If Anna cancels, the site says "You cancelled the payment. Nothing was sent." and returns her to the review screen with everything still filled in. Other failures follow The failures.
Do
Ask for the tickets basket in the first purchase's prompt, as a separate item Anna can decline, and never at sign-in.
Don't
Ask for a spending allowance "to make the next purchase faster". A site people pay a few times a year should ask each time.
The confirmation
When Anna's wallet accepts, the site shows You're going: the gig, "Paid £12.00 (24,000 sats) to Example Tickets", and "Your ticket is in your wallet." Below that is the one place the site asks for an email, as an optional field: "Want a receipt by email? Optional.", with a Skip link of equal weight.
Do
Tell Anna where the ticket is, in her wallet, on the confirmation, so she does not wait for an email that is not coming.
The ticket in her wallet
In Bitcoin SV Wallet the ticket appears with the four things the holding-tokens pattern asks for: what it is (the gig, the date, "1 standing ticket"), where it came from ("Issued by Example Tickets for The Corner Room"), whether it is the real one (the wallet matches the issuer against ones it recognises), and what can be done with it ("Can be given to someone. Not refundable.").
The wallet draws this screen, not the site. What the site controls is the data it puts on the ticket when it issues it, so the gig, date and venue have to be on the token itself, not only in the site's database.
Do
Write the gig name, venue, date and what the holder may do with the ticket into the token when it is issued, so any wallet can show it without asking the site.
On the night
At the door, Anna opens the ticket in her wallet and presses Show at the door. The wallet shows a code that proves she holds the ticket right now. The door scans it and marks the ticket used. In this design the code changes every few seconds, so a screenshot of someone else's ticket does not work. How the wallet produces that code is not settled by the standards the guide cites. See the open questions. If her ticket says "Show ID at the door", the screen says so too, and she has the ID ready.
The door screen shows the gig and "Admits one". It does not show the price, her balance or anything else in her wallet.
Don't
Let a picture of the ticket be enough to get in. The picture is the part anybody can copy; the door has to check that the person in front of it holds the ticket now.
Open questions
- How does the door check a ticket when the venue has no signal? Can the wallet produce a proof the door can check offline, and how long should it stay valid?
- If Anna gives the ticket to a friend, the age check at checkout proved only her age. Should the door check every holder, or should over-18 tickets not be transferable?
- Do people trust a ticket they cannot see in their email, or will they screenshot the wallet screen anyway?
- Is "at today's rate" beside the sats amount enough, or do people need to know how long the figure holds?
Related
- Holding tokens: what a token is and the four things to show
- Amounts and units: sats, local currency and fees
- Errors and failed payments: cancelling and failed payments
- Sending: the review screen from the wallet's side
- Proving an age: the step before the review screen
- Coming back and leaving
Written from: /guide/patterns/holding-tokens/, /guide/patterns/amounts-and-units/, /guide/patterns/permissions-and-allowances/, /guide/patterns/errors-and-failed-payments/, /guide/patterns/connecting-a-wallet/, /guide/daily-spending-wallet/sending/.
Checklist
The rules on this page, in a form you can work through.
9 rules