Signing in
How Example Tickets signs Anna in with her wallet: one button for every visit, the wallet's prompt, what the site says it received, a returning visit with no prompt, and a second device.
Example Tickets has no sign-up and no password. Anna presses one button and approves one prompt in her wallet. The site then has what it needs to recognise her: a key her wallet made for this site alone. The rules for this kind of sign-in are in the Signing in pattern. This page applies them to a ticketing site.
The gig page, before signing in
Anna arrives from a link to the gig. She can see the listing, the date and the price without connecting anything. The header carries one button, Connect wallet, with a line under it: "No account needed. Use the same wallet on any device to see your tickets." A small link, "What we ask your wallet for", opens the site's exposure statement.
There is no separate "Sign up" and "Log in". A first visit and a return visit are the same action, so they share one button.
Do
Let people browse every gig, date and price without connecting. Connecting is for buying and for seeing tickets already bought, not for looking.
Don't
Name a wallet brand on the site's connect button or its explanation. The site works with any compatible wallet, and naming one tells everyone else they are in the wrong place.
The wallet's prompt
Bitcoin SV Wallet, running on Anna's laptop, shows its own prompt: "Example Tickets wants to connect", with the verified domain tickets.example.com beneath. Two lines say what connecting means: "It will recognise you with a key made for this site only." and "It can't take any money without asking you." The buttons are Connect and Not now. This is the same sheet Bitcoin SV Wallet shows for The Satoshi Vision.
The prompt does not mention Passes or tickets, because the site has not asked for them yet. Each is asked for when Anna reaches the step that needs it.
While the prompt is open, the site shows "Waiting for your wallet…" in place of the button, and nothing else changes. It does not time out. See While the prompt is open.
Do
Ask only for the sign-in key at this step. Payment, the age check and the ticket basket each wait for the screen where Anna first needs them.
Don't
Treat "Not now" at this prompt as a failure. Put the Connect wallet button back, keep the gig page as it was, and say nothing louder than the button.
What the site received
Back on the gig page, a quiet line closes the loop: "Example Tickets can now recognise you next time. We can't see your balance, your other apps or who you are." It has a Got it link and does not come back once dismissed. The header now says Your account, not a key or a shortened string.
Anna has not given a name, so the site has none to show. That is correct, not a gap to fill with a form.
Do
Show the "what we can and can't see" line once, after the first sign-in only, on the page Anna was already on rather than a separate welcome screen.
Don't
Ask for a name or email straight after sign-in to make the header friendlier. "Your account" is enough until Anna chooses to add something.
Coming back
A week later Anna opens tickets.example.com again. Her browser session has expired, but Bitcoin SV Wallet still holds the permission it granted the site, so it hands over the same key without asking. The site signs her in in the background. The first thing she sees is the home page, with Your tickets (1) in the header.
There is no "Welcome back" screen and no wallet prompt. If the wallet does ask, because it was restored or its permissions were cleared, the site shows the same waiting state as the first time.
Do
Try a silent sign-in on load when the site has seen this browser before, and fall back to the Connect wallet button only if the wallet does not answer without a prompt.
A second device
The day before the gig, Anna opens the site on her phone. On mobile the site runs inside her wallet's built-in browser, which passes its requests to the wallet (see How it works). Her phone holds the same Bitcoin SV Wallet, restored from the same recovery words and wallet backup. It derives the same key for tickets.example.com, so the site sees the same account: Your tickets (1).
Whether the phone asks her to approve the site again depends on whether her wallet carries its permissions between devices. This design assumes it might, and treats that one prompt as normal.
If she opens the site in her phone's ordinary browser instead, there is no wallet to ask. The site says so in a sentence and offers one action, "Open in your wallet", instead of an error. See the no-wallet rows in The failures.
Do
Under the connect button, say in one line that the account follows the wallet, not the device: "Use the same wallet on any device to see your tickets. A different wallet starts a new account."
Don't
Offer to "find" Anna's account when a different wallet connects. The site cannot tell it is her, and guessing from anything else would link identities she kept apart.
Open questions
- Do people expect a site to remember them on a new phone, and are they surprised when a second wallet shows an empty account?
- When a wallet does not carry permissions between devices, does a second prompt for the same site read as reassurance or as a fault?
- Is "Use the same wallet on any device to see your tickets" understood by someone who has never connected a wallet, or does it need a picture?
Related
- Signing in pattern: app-specific keys, returning visits and signing out
- Connecting a wallet: the connect moment and asking for the minimum
- Proving an age: the next thing the site asks for, and only at checkout
- Identity
Written from: /guide/patterns/signing-in/, /guide/patterns/connecting-a-wallet/, /guide/patterns/permissions-and-allowances/, /guide/how-it-works/identity/, /guide/patterns/errors-and-failed-payments/.
Checklist
The rules on this page, in a form you can work through.
9 rules