Swimming Ticketing — Online ticketing web application (Laravel)
The ticketing system takes a booking, a payment, and issues a QR e-ticket that is scanned at the gate. It keeps the minimum needed to prove that a ticket is valid and that it was paid for.
Swimming Ticketing is software that an organization installs and runs on its own infrastructure. The pool operator operating a given installation decides what data is entered into it and is the data controller for that installation. This page documents what the application itself collects and processes by design; it is the reference policy for the software, and an operator may publish additional terms on top of it. As the developer, I have no access to any production database unless an operator explicitly grants it for maintenance.
| Data | Why |
|---|---|
| Buyer details | Name plus an email address or phone number — so the e-ticket can be delivered and the booking can be found at the gate. |
| Booking details | Date, session, ticket type and quantity, and price — for capacity management and pricing (weekday/weekend). |
| Payment status | Midtrans order ID, amount, method, and status. No card or bank credentials are received or stored. |
| E-ticket and scan log | The booking reference encoded in the QR code, plus the time it was scanned at the gate, so a ticket cannot be reused. |
| Staff accounts | Name, role, and hashed password for gate and management users. |
| Technical logs | IP address, user agent, and timestamps. |
| Service | What it does |
|---|---|
| Midtrans (PT Midtrans) Privacy policy ↗ | Processes payments (QRIS, virtual account, e-wallet, card). Card and banking details are entered on Midtrans’ own page — this application never sees or stores them. |
| Email delivery (SMTP provider) | Sends order confirmation and status emails. The provider receives the recipient email address and the message content. |
The QR code encodes a random booking reference and nothing else. Someone who photographs it cannot read your name, contact details, or payment information from it — but they could use it to enter, so treat it like a paper ticket. Scanning at the gate marks the reference as used.
The application uses cookies only for functionality:
There are no advertising cookies, no third-party analytics or tracking pixels, and no cross-site profiling. Clearing cookies simply logs you out.
Booking data is visible to the pool’s staff and management. It is shared with the payment provider for the transaction and with nobody else; it is never sold. Bookings and visit logs are kept for as long as the operator’s reporting and bookkeeping obligations require, and you can ask the operator to remove your contact details once a visit is complete.
The application applies standard protections: passwords are stored as one-way hashes (never in plain text), access is limited by role, and all traffic between client and server is expected to run over HTTPS/TLS.
No system is perfectly secure. Server hardening, backups, and access management for a live installation are the responsibility of the organization operating it.
Tickets for children are purchased by a parent or guardian, whose details are the ones recorded. The system does not knowingly collect data directly from children.
You have the right to ask for access to, correction of, or deletion of your personal data, and to object to certain processing.
Because your data lives in the installation run by the organization you deal with, address those requests to that organization first — they hold the data and can act on it. If you cannot reach them, or you believe the application itself is at fault, contact the developer at mhdlutfidev@gmail.com and I will assist technically.
If this policy changes, the “Last updated” date at the top of this page will be revised. Material changes will be reflected in the application release notes.
Questions, complaints, or privacy requests about this application:
I aim to respond within 7 business days.