Attendize

Attendize is an open-source ticket selling and event management application built on the Laravel PHP framework. I follow it when organizers want to sell tickets and manage attendees on infrastructure they control — without paying service fees to third-party ticketing platforms. The GitHub project and attendize.com document the product as a full event stack: mobile-friendly public pages, checkout, payments, attendee messaging/exports, affiliate tracking, embeddable widgets, and a browser-based QR scanner for the door. Current releases sit in the v2.x line (e.g. 2.8.0 in composer.json), with install paths via manual LAMP/LEMP setup or a Docker make setup flow for development (Getting started).

Official product shots below come from the Attendize screenshots on attendize.com.

#What I like most about Attendize

I reach for Attendize when the job is real event ops on PHP/Laravel — not a custom “ticket PDF + Stripe Checkout” bolt-on that still needs check-in, messaging, and organizer branding.

#1. End-to-end event + ticket loop

Public event pages, ticket types, checkout, attendee management (refunds, messaging), XLS/CSV export, print-friendly lists, and real-time style stats — as listed in the README and docs feature list.
Why it matters: Most organizers need sell → confirm → message → check in before they need a custom CRM.

#2. Door management without a proprietary scanner app

Browser-based QR code scanning for door management, plus customizable tickets with QR codes and organizer logos.
Why it matters: Venue staff can check in on a phone or laptop without buying a separate scanning stack.

#3. Multi-organiser, multi-event orientation

Unlimited organisers/events (per product docs), public organiser listing pages, multiple currencies, and brandable tickets/pages.
Why it matters: Agencies and venues often run more than one brand or series on the same install.

#4. Payments beyond a single gateway

Omnipay-backed Stripe and PayPal out of the box, offline payments, partial/full refunds, and optional service charges on tickets; README also notes Coinbase among supported options, with more gateways addable via Omnipay.
Why it matters: Local events often mix card, PayPal, and cash/bank transfer — a hard Stripe-only checkout breaks the workflow.

#5. Embed and promote where traffic already lives

Ticket-selling widgets for existing sites/WordPress, social sharing, affiliate tracking (visits and sales volume), and custom checkout questions.
Why it matters: Many events already have a marketing site; Attendize can sell tickets without forcing every visitor onto a separate SaaS domain.

#6. Self-host control vs fee-heavy SaaS

The whole pitch is owning the platform so you are not paying per-ticket platform fees to Eventbrite-class vendors. Source is AAL-licensed with optional white-label licenses if you need to remove “Powered by Attendize” (license).
Why it matters: High-volume or multi-event operators care about fee math and brand control; self-host shifts cost to hosting and ops.

← Prev

Next →

#Project structure

High-level layout from the Laravel Attendize repository (v2 / Laravel 6 era):

Mental model:

• Organisers & events — multi-organiser admin, public listing pages
• Tickets & checkout — ticket types, custom questions, service charges
• Payments — Omnipay gateways + offline; refunds
• Attendees — messaging, exports, print lists
• Door — QR on tickets + browser scanner
• Distribution — widgets, affiliates, social sharing

git clone https://github.com/Attendize/Attendize.git
cd Attendize
git checkout master
cp .env.example .env
composer install
php artisan key:generate
# Point the web server document root at ./public
# Then open https://your-ticket-site.example/install

Docker (dev) — from the docs:

make setup
# Installer: https://localhost:8081/install
# Or: docker-compose run php php artisan attendize:install

Upstream requirements (master / v2): PHP ≥ 7.1.3 (composer pins ^7.3), OpenSSL/PDO/Mbstring/Tokenizer/Fileinfo/GD, MySQL 5.7+. See Getting started.

#Code analysis

Stack snapshot (from composer.json + README, Attendize ~2.8):

Strengths when I evaluate it:

• Product completeness for events — not just a payment link
• Laravel familiarity — deploy, mail, queues, and debugging stay in PHP ops habits
• Omnipay payment surface — Stripe/PayPal/offline plus room to add gateways
• Operational door path — QR tickets + browser scanner documented as first-class

Trade-offs / caveats:

• Laravel 6 / PHP 7.3-era stack — plan maintenance, security patching, and upgrade work; this is not a Laravel 11 greenfield app
• AAL attribution — free to self-host with the notice; white-label and SaaS redistribution need paid licenses (license page)
• Project support model — maintainers point paid support/licensing to attendize.com; GitHub issues are for bugs, not free ops support
• Branch/gateway nuance — docs still mention an older Laravel 5.2 line for some Omnipay v2 gateways; verify gateway choice against the version guidance
• Self-host means you own SSL, mail deliverability, backups, and capacity for on-sale spikes

Env sketch (illustrative — secrets stay in .env):

// .env (names illustrative; follow .env.example on install)
APP_URL=https://tickets.example.com
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=attendize
MAIL_MAILER=smtp
# Stripe / PayPal credentials configured via installer + Omnipay settings

#Why people use it

Skip it if you need a modern Laravel LTS greenfield, heavy SaaS multi-tenant ticketing without buying a SAAS license, or a fully managed Eventbrite-class product with zero PHP ops.

#Conclusion

Attendize remains one of the clearest Laravel-native open-source ticketing options I follow: event pages, checkout, payments, attendee ops, and QR door check-in in one self-hosted package (repo, docs, getting started).

Honest caveat: treat it as a mature v2 Laravel 6 product, not a bleeding-edge framework showcase. Budget for PHP/MySQL ops, mail/DNS, and license/attribution rules before an on-sale date — and prove checkout + scanner on staging before selling real tickets.