CLICK’DWorking prototype

Distributed photobooth platform

A booth that takes money unattended — and never loses a paid session.

Not a photobooth screen application. A distributed transaction system attached to physical hardware.

Open the booth→Test 10 roles
screens built

32

screens built

roles enforced

11

roles enforced

session states

28

session states

sessions recorded

0

sessions recorded

How it works

One paid session, start to finish

Payment is verified before the camera unlocks. Everything after is checkpointed, so a crash or power cut resumes rather than restarts.

AttractREADY
CLICK’DTap to get Click’d3 photos · prints · digitalSTART
01

Attract

Event identity, starting price, one action.

→
PayREADY

Unlock your session

Scan to pay

4 printed strips
₹400
02

Pay

UPI QR. Camera stays locked until the server verifies.

→
CaptureREADY
PHOTO 1 OF 33
03

Capture

Three photos, each with countdown, review and retake.

→
FulfilCOPY 1/4

Please wait

Printing your photos

Copy 1 of 4

● Reset locked
CLICK’D
POSE · CLICK · KEEP
04

Fulfil

Print dispatched, WhatsApp queued, backup QR ready.

The rule the whole product hangs on

A confirmed paid session stays an open obligation until print and digital delivery are resolved — completed, queued for recovery, or closed by an authorised person with a recorded reason.

Architecture

Edge executes, cloud decides

The booth completes a paid session with no cloud round-trip. The cloud owns money, configuration and identity. The booth opens every connection — nothing inbound.

BOOTH · EDGERuns even when the cloud does notGuest UI23 screens, 1920×1080Session state machinecheckpointed, 28 statesLocal storeSQLite WAL · outboxHardware adapterscamera · printerSigned entitlement · unlocks the camera offlineCLOUD · CONTROL PLANEAuthority for money and configPayment + entitlementidempotent, server-verifiedConfig versionspublished, pinned per sessionFleet + fulfilment ledgeropen obligations trackedIdentity · RBAC · audit11 roles, scopedBooth opens every connection · no inbound portsVerified payment → signed entitlementConfig publish (next session only)Health, telemetry, commandsMedia upload + delivery jobs
23

Booth runtime

Guests

/booth →

9

Operator console

Event associate

/ops/login →

7

Control panel

Ops · finance · admin

/console →

1

Partner portal

Venue partners

/partner →

Value

Three interests, one session

None of them sees the others' data — that separation is enforced, not conventional.

☺

Guest

  • Pay once — prints and a digital copy
  • No app install
  • A broken booth holds the session, never drops it
⌂

Venue

  • Unattended revenue in footfall space
  • Co-branded frames and campaigns
  • Reporting without touching guest data
◉

Click'd ops

  • One team configures the whole fleet
  • Every paid session tracked to resolution
  • Remote recovery instead of a site visit

Differentiation

Why not just licence booth software

LumaBooth and dslrBooth are strong products — for an attended event booth. This is an unattended kiosk taking a guest's money, which is a different problem.

Licensed booth softwareClick’d platform
Guest experience polish
360 booth, video guest book, background removal
Server-verified payment
Entitlement required before the camera unlocks
Recoverable paid session
Open obligation with no silent-abandon path
Fleet control
Config publish, version pinning, remote commands
Multi-tenant roles
11 roles enforced at the API
Time to first booth
Licence and run vs build and certify
Cost per device
~$20/mo vs bespoke build

Read it honestly: licensed software wins on creative features, speed and cost. It has no payment ledger, no entitlement model, no fleet control and no multi-tenant reporting. For attended events it is the faster path. For unattended paid kiosks it cannot meet the requirement at all.

Access control

Every gap is a deliberate restriction

Rendered directly from the permission model the API enforces. Marketing genuinely cannot reach money; finance genuinely cannot reach photos.

RoleFleetSessionsConfigMoneySensitiveReportsGovernance
Event Success Associate11 of 27
Field technician7 of 27
City operations lead13 of 27
Central operations16 of 27
Marketing / content manager4 of 27
Finance7 of 27MFA
Partner user1 of 27
Product / analyst4 of 27
Administrator20 of 27MFA
Super administrator27 of 27MFA

Try it

Ten roles, one click each

Real accounts, scrypt-hashed passwords (clickd123), lockout after five failures. Sign in as marketing and the finance API returns 403 — not a hidden menu item.

Guest — no login

Full paid journey. Payment auto-confirms via the simulator.

Operator console — PIN 123456

Local booth console, still on the legacy shared PIN.

Honest status

What is real, what is not

Real

  • Session state machine — illegal transitions rejected with 409
  • Payment idempotency — replays cannot mint a second entitlement
  • Browser camera capture, atomic writes, SHA-256 checksums
  • Strip render at 2×6in / 300dpi to the real Windows spooler
  • RFC 6238 TOTP — arbitrary codes rejected
  • 11 roles enforced at the API, scrypt passwords, lockout
  • Immutable audit trail on every privileged action

Not yet real

  • Razorpay — adapter written, waiting on test API keys
  • WhatsApp — Twilio adapter written, waiting on the auth token
  • Tethered DSLR control — needs camera model and SDK (OD-01)
  • DNP media, ribbon, cut mode — needs printer SDK (OD-02)
  • Print completion inferred from the spooler, not proven
  • Design reconstructed from the prototype, not pixel-matched
  • Schema applies on boot; migration chain overdue

Built against the Click’d Software Development & Central Control Panel Docket v1.0 and the Technology Architecture & Implementation Guide v1.0.