Front of House for Event Espresso runs the box office of a live event from a tablet. Each device is trusted by an administrator, every action is attributed to the clerk who took it, and the whole shift is captured in an append-only audit trail. It is an Event Espresso add-on — it reads and writes through Event Espresso's own models, so a sale, a payment, or a return at the door is the same real transaction it would be in wp-admin.
\nThe station runs as an installable PWA with no WordPress chrome: a clerk signs in with a badge, the tablet shows a fast registration search or a sales grid, and the door keeps moving.
\nWhat a station can do
\nBuilt for the front desk
\nFull documentation and architecture notes live in the bundled README.md.
", "installation": "wp-content/plugins/ and activate it (activate per site on multisite).Does this require Event Espresso?
\nYes. It is an Event Espresso add-on and is tested against Event Espresso 5. Sales, payments, check-ins, and returns are written through Event Espresso's own models, so they are identical to what wp-admin would produce.
\nWhy does it need HTTPS?
\nThe camera-based barcode/QR scanner (camera access) and Bluetooth thermal printing (Web Bluetooth) only work in a secure browser context. Serve the site over HTTPS and the station works on tablets and phones.
\nHow do clerks log in?
\nA clerk signs in to a station with a badge — scanned by the device camera, read by a hardware wedge scanner, or typed in as a code. Clerks are not WordPress users; they are managed under Front of House → Clerks and governed by configurable roles. Treat a printed badge as a physical login key.
\nWhat happens when the network drops?
\nThe station distinguishes a genuine network failure (an offline banner) from a server-side response such as a too-short search or an out-of-scope result (shown inline). When the card-present path charges but recording the payment fails, the station does not swallow it: it retries, prints a manager error slip, records an audit incident, and shows a blocking manager modal.
\nCan I add card payments or store credit?
\nYes. Cash and check are built in. Card-present payments come from a pluggable provider add-on, and store credit / pay-with-credit come from a companion customer-credit plugin. When those companions are absent, the station hides the affordances entirely.
\nDoes it work on multisite?
\nYes. Activate it per site on a multisite network.
", "changelog": "0.23.4
\n* Card bump-back fix: the \"Pay with card\" action now launches the card-present provider (Collect) via a real tapped <a href> instead of a programmatic window.location.assign. From an installed Android WebAPK only a user-tapped anchor hands the launchApp deep link to the provider as an Android intent, so the provider runs integrated and returns to our /foh/payment-result callback (auto-bumps back into the app); a programmatic navigation made it run standalone and return to its own home. The temporary Diagnostics test link stays for one more cycle. Manifest unchanged — no reinstall; reopen the app after updating.
0.23.3
\n* TEMPORARY diagnostic: a \"Test: $1 Collect charge\" link under Settings (hamburger) ▸ Diagnostics. It launches Collect via a real tapped <a href> (the way the proven probe did) instead of the app's programmatic window.location.assign, to isolate why the card return doesn't bump back into the app. Manifest unchanged — no reinstall needed, just reopen the app after updating. Remove once diagnosed.
0.23.2
\n* Revert the 0.23.1 manifest link-capture keys. On Android the installed WebAPK already captures in-scope https returns purely from scope (the proven, working mechanism — Collect's redirect to an in-scope /foh/ URL re-enters the app). handle_links/launch_handler are desktop-only no-ops there, and the explicit id risked changing WebAPK identity (treated as a different app without legacy_ids). Manifest is back to the minimal scope-only form. Reinstall the PWA (uninstall + Chrome \"Install app\") so the WebAPK re-mints its /foh/ intent filters.
0.23.1
\n* PWA link capture: the station manifest now declares handle_links: preferred + launch_handler: navigate-existing (and an explicit id) so an installed station can capture an in-scope return navigation — e.g. a card-present provider redirecting back to /foh/payment-result after a charge — into the existing app window instead of a browser tab. Requires reinstalling the PWA to pick up the new manifest.
0.23.0
\n* Registrations now keep their contact questions on a Purchase sale. A ticket flagged by a companion (via the new eea_foh_ticket_collects_contact filter) — e.g. an \"attendee\"-class registration — keeps its contact/personal questions even on an anonymous Purchase, so the attendee's details are still captured. Anonymous merch/meal tickets are unchanged (contact still suppressed for a one-tap counter sale).
\n* Fix: corrected the card-present return fallback to match Collect's actual callback (result=success). Pair with eea-foh-collect 0.3.2.
0.22.3
\n* Screenshots tab now uses the gallery pipeline (captions paired with screenshot-N images); with no images committed yet, the captions-only tab is dropped. No functional change.
0.22.2
\n* Update-details sections now come from readme.txt (WP-native); base/config renamed to .mu-manifest.yaml + .mu-release.yaml. No functional change.
0.22.1
\n* Release now flows through the shared manifest pipeline; the \"View details\" modal carries a description, changelog, and tags. No functional change to the plugin.
0.22.0
\n* Added a color-coded plugin icon (delivered through the update channel) and declared WordPress 7.0 compatibility. No functional change.
The full history is in CHANGELOG.md bundled with the plugin.
\n0.21.2
\n* Updates are now handled by the Manifest Updater plugin (via the standard \"Update URI\" header) instead of a bundled updater. No change to how Front of House works; this lets it run on a single site instead of network-wide. Requires the Manifest Updater plugin to be network-activated to receive update notifications.
0.21.1
\n* Fixed for real (multisite): the \"payment method Return/Settlement was automatically deactivated\" admin notice that kept coming back. Root cause was that Front of House auto-activated its internal Return/Settlement methods on every site in the network and then kept reactivating them, which Event Espresso re-deactivated in a loop. Those methods are now created only on the site that actually records a return/settlement (the desk site), and the stale notice is cleared in every admin context. No effect on how returns/settlements work.
0.21.0
\n* Per-method payment options. Settings ▸ Payment Methods now lets you set, per method, a custom button label, whether a check number is required, and (for card) a surcharge. A card surcharge is added to the sale as a real fee line item — it raises the total, prints on the receipt, and is recorded in Event Espresso — so the customer is actually charged it. Card payments include the surcharge in the amount charged on the reader.
\n* Card is now provided through the Collect for Stripe add-on's registration with Front of House, and Front of House owns enabling/disabling and labelling every method (including card) in one place. Update the Collect add-on to 0.2.0 alongside this release.
\n* The old \"Allow cash refunds\" setting is carried forward into the new Payment Methods section automatically; no reconfiguration needed.
0.20.1
\n* Fixed a \"payment method was automatically deactivated\" admin notice that kept reappearing for the Return and Settlement payment methods. The methods themselves were working; the stale warning is now cleared properly (the previous fix was being undone by Event Espresso's own notice save).
0.20.0
\n* Per-device payment hardware. Each device now has a \"Hardware\" block (card reader, cash drawer); unchecking one hides that payment method on that station's point of sale — card needs a card reader, cash needs a cash drawer. Visibility only: it never changes who may take payment, and nothing changes on existing devices (every device is treated as fully equipped until you say otherwise).
0.19.0
\n* A single home for payment methods. A new \"Payment Methods\" settings section turns cash, check, and card on or off and sets cash-refund policy in one place; an access profile can restrict which methods a given station offers. Nothing changes on an existing install — every method stays enabled exactly as before until you adjust it. Under the hood the method set is now data-driven (a registry) so future methods can plug in cleanly.
0.18.1
\n* Check payments at the desk (activates Event Espresso's Check method in the admin scope). Server-side event-scope enforcement on every payment/return endpoint (a clerk can only act on their own event's transactions). Clerk/manager codes widened to 10 digits with a per-device brute-force lockout, plus a remote \"Clear lockout\" admin action.
0.18.0
\n* Card-present payments are verified against Stripe before approval (no more trusting the return URL). Every first-touch money write (sales, exchanges, cash, credit, settlements) is now idempotent against a lost-response retry. Audit-log failures are no longer silent.
0.17.2
\n* The Return and Settlement payment methods now reactivate themselves automatically after a plugin update — no manual step on the Payment Methods screen, ever.
0.17.1
\n* Walk-up Return (card-less return/exchange). Sales and returns now verify the transaction's true status in Event Espresso before completing — no more false \"Sale Complete\" on an unpaid exit.
0.17.0
\n* Admin-configurable branding (receipt logo, app icon, splash, background) and Bluetooth badge printing in wp-admin (one badge at a time, tear between).
0.16.2
\n* Service worker REST namespace fix (eea-checkin/v1 -> eea-foh/v1); no behavior change.
0.16.1
\n* Update channel + repository URLs moved to the ee-extensions org. Removed a hard-coded external domain from the receipt printer's barcode/QR test page.
0.16.0
\n* Taking payment is now a lookup filter (All / Needs check-in / Needs payment), not a separate mode. Sell remains its own mode. No schema or server change.
0.15.0
\n* Printable clerk badges plus camera and hardware-wedge scan-to-login, with per-device camera configuration.
0.14.x
\n* Bluetooth thermal receipt printing with templated header/footer, itemized line items, and configurable tear feed; a dedicated receipt-printer configuration modal with on-device test buttons; loud \"charged but unrecorded\" incident handling for the card-present path.
0.13.0
\n* Returns, exchanges, refunds, and customer credit settled as real Event Espresso transactions, with cash-refund/forfeit/store-credit settlement and exchange tax suppression.
0.12.0
\n* Card-present payments via a pluggable, provider-agnostic descriptor model; cash tender with change; on-demand emailed receipts.
0.11.0
\n* Sell / POS mode — front-desk sales through a category grid and persistent cart, building real Event Espresso transactions with automatic tax and full rollback.
0.9.0 - 0.10.0
\n* Station modes, pluggable in-person payments, the corrected visibility-vs-action check-in model, assistive (stacked) manager login, per-device themes, and a Q&A + payments details modal.
0.5.0 - 0.7.x
\n* Device-secret authentication and nonce-sealed enrollment, first-class enrollment links, configurable clerk roles and stateful sessions, clerk-to-station scoping, linked-registration reverse lookup, and a role-gated registration details modal.
0.1.0 - 0.4.0
\n* Foundation: profiles/devices/clerks/audit data model, REST layer, ranked search, check-in over Event Espresso models, the device approval handshake, and the station PWA.