Connected web app
A reference design for a ticketing website with no accounts and no passwords: signing in with a wallet, proving an age with a Pass, buying a ticket, coming back and leaving.
A worked example of a website that people use with their own wallet instead of an account. Example Tickets, at tickets.example.com, sells tickets to gigs on desktop and mobile. There is no sign-up form, no password and no stored card. The wallet signs Anna in, proves she is old enough, pays, and holds the ticket.
Many teams building on BSV make an app like this rather than a wallet, so it is where most of the guide's patterns meet in one product.
About these screens
Every screen in this section is a proposed design, drawn as a wireframe, and none describes a shipped product. Anna Keller, Example Tickets, The Corner Room and Example ID Service are fictional, and Anna is the same person in all three reference designs. Bitcoin SV Wallet is the BSV Association's wallet, used here as Anna's wallet; its screens in this section are proposals, not the app as it ships. Amounts convert at an illustrative 2,000 sats to £1. The wording, prices and limits are worked examples to take apart, not measured results.
Who it is for
Anna Keller wants a ticket to a gig at The Corner Room, an over-18 venue. She uses Bitcoin SV Wallet on her laptop and her phone.
Anna is closest to Ilse, privacy-minded: she does not want an account to buy a ticket, and she reads what she agrees to. The team building the site is closer to Emma, who fears asking for too much and losing people at the permission prompt. Both shape the design. Anna decides whether each screen is acceptable; Emma decides what the site can live without.
What it does
- Signs Anna in with a key her wallet makes for this site, and recognises her when she comes back.
- Asks for one fact from a Pass, "over 18", at checkout for an over-18 gig and nowhere else.
- Takes a one-off payment, approved in her wallet each time.
- Delivers the ticket as a token that Anna holds in her wallet, not as a row in the site's database.
- Lets her sign out, disconnect, and see what the site keeps about her.
The flows
- Signing in. One Connect wallet button for every visit, the wallet's prompt, what the site says it received, a returning visit with no prompt, and the same account on a second device.
- Proving an age. Asking at checkout for "over 18" only, the wallet's Pass prompt, what the site offers when Anna has no Pass, and a refusal that is not an error.
- Buying a ticket. The review screen, the payment, the ticket arriving in her wallet, and the ticket on the night.
- Coming back and leaving. Signing out against disconnecting, removing the site in the wallet, what the site keeps, and taking the ticket elsewhere.
The patterns it applies
- Signing in, for recognising Anna on every visit with a key derived for this site.
- Connecting a wallet, for asking for the minimum at the first wallet request.
- Permissions and allowances, for checkout and the ticket: one Pass field, one basket and no allowance.
- Asking for a Pass, for the age check, with the concepts in Identity.
- Holding tokens, for the ticket.
- Amounts and units, for prices in pounds first with satoshis beside them.
- Errors and failed payments, for refusals and failed steps.
What it deliberately leaves out
- Accounts. No email, password or username to sign in. An email is offered after a purchase, for receipts only, and can be skipped.
- A spending allowance. People buy tickets a few times a year. Each purchase is approved in the wallet, so the site never holds a standing right to charge.
- The wallet's root identity key. The site has no reason to recognise Anna anywhere else.
- A Pass at sign-in. Only an over-18 gig needs one, so only that checkout asks.
- Wallet brand names. The site says "your wallet" throughout. Bitcoin SV Wallet appears only in Bitcoin SV Wallet's own screens.
- Fees. The network fee is less than 1p and does not appear on the review screen. A booking fee, if a real product charges one, belongs in the price on the review screen, not in a line added at the end.
On other platforms
Example Tickets is a website on purpose: the wallet can show its domain as checked, and on a phone it runs inside the wallet's browser. As an installed iPhone app, three things would change:
- The connect prompt would show a name the app gave itself, so the first sign-in would ask for less and the wallet would mark the name as not checked.
- Buying a ticket would send the person to their wallet to approve and back again; the ticket screen has to hold its place while they are away.
- Opening a shared link in an ordinary phone browser could not connect at all as a website; as an app it would need its own route to the wallet. See Phone apps.
How to use this
Do
Write down, before drawing any screen, the three things a ticketing site needs from the wallet (a key for this site, one Pass field for age-restricted gigs, one basket for tickets) and treat any request beyond them as a design change that needs a reason.
Don't
Add an account system "for later" alongside the wallet sign-in. Two ways to be the same person on one site is how people end up with two half-accounts and a support ticket.
Recommendation
Publish the site's exposure statement where the sign-in button is, as a link, so somebody like Ilse can read what the site asks for before she connects. See Disclose what you use.
Related
- Pay-per-use reader: an app that charges often, so it does use an allowance
- Agent with a budget: software spending on somebody's behalf
- Daily spending wallet: the wallet side of the same conversation
- Signing in
Written from: /guide/patterns/signing-in/, /guide/patterns/connecting-a-wallet/, /guide/patterns/permissions-and-allowances/, /guide/how-it-works/identity/, /guide/patterns/holding-tokens/, /guide/patterns/errors-and-failed-payments/, /guide/patterns/amounts-and-units/, /guide/research/personas/.
Checklist
The rules on this page, in a form you can work through.
3 rules