Event ticketing software. Built around paid registration.

No, and we shouldn't pretend otherwise. Eventbrite, Ticketmaster, DICE, Universe are consumer marketplaces: they list events publicly for discovery, handle scalper protection, queue large drops, and own the buyer relationship. Eventtia is paid registration inside an event management system: you own the audience, you own the buyer relationship, and every paid attendee is a row in your registration database from the moment of purchase. They're different products solving different problems. If you need public discovery and anonymous ticket holders, you want a marketplace. If you need attendee data, branded checkout, and the payment record connected to who shows up, you want this.

In Eventtia's case, "ticketing" is paid registration: tiered pricing, group orders, approvals, payment processing, and the attendee record that ties it all together. You set up pricing tiers on the event (early-bird, regular, late, student, VIP, by-invitation), connect a payment processor, and the form on your branded landing page handles the rest. The transaction posts through your merchant account; the attendee record carries the registration data, the payment receipt, and the access rules into check-in and reporting.

Tiered pricing with time- and capacity-windows. Group orders where one buyer pays for many. Multi-currency support if your program runs across markets. A processor your finance team already trusts (Stripe, Adyen, PayPal, or the regional ones). Discount codes per tier. Native VAT handling that doesn't break the calculation. A clear refund path through your payment processor. Attendee data ownership in writing. And exports to the systems your team already uses for reporting and CRM. If a platform doesn't do one of those, the gap shows up later as a workaround.

On your processor's payout schedule, into your merchant account, before the event happens. Eventtia is not the payment processor — Stripe (or Adyen, or PayPal, or whichever you connected) is. Funds clear through their cadence, not ours, and we never sit on ticket revenue waiting for the event to take place. This matters for cash flow during the planning months; some marketplaces hold revenue until after the event, which complicates budgeting.

Yes, through an open integration model rather than vendor-built native connectors. Zapier connects Eventtia to the major CRMs out of the box — Salesforce, HubSpot, Microsoft Dynamics, Marketo, Mailchimp, and the long tail — without custom development. For deeper sync, the REST API and webhooks let your team build the exact mapping you need, so attendee, transaction, and registration-field data lands in the records your sales and marketing teams already work in. More upfront setup than clicking a "native Salesforce" button, but the integration ends up matching your CRM model rather than the other way around.

Major card networks (Visa, MasterCard, Amex), Apple Pay, Google Pay, PayPal, Klarna, plus regional methods through the processors we support: Bizum, iDEAL, Bancontact, Sofort via Stripe and Adyen; PSE, Nequi via Wompi and PayU; Pix, Boleto via Mercado Pago. For B2B buyers who pay by bank transfer or other offline channels, the organizer receives the payment outside Eventtia and marks the registration as paid in the platform — we call these manual payments. The exact list depends on the processor your event is connected to.

Yes, through what we call manual payments. Eventtia doesn't process bank transfers itself — the organizer receives the transfer (or cash, or internal billing) directly, then marks the registration as paid in the platform. The attendee record reflects the paid status and flows into check-in and reporting like any card transaction. Useful for corporate registrations, government contracts, partner billing, and markets where card payment isn't the norm.

Eventtia issues receipts for every transaction — the buyer name, the line items, the discount, the VAT calculation, the total. If your finance department needs a proper fiscal invoice (with a sequential number, the seller's tax ID, and whatever else local law requires), that's generated on your side, by your accounting system, against the registration data we provide. The receipt and the fiscal invoice serve different purposes; Eventtia handles the first, your finance team handles the second.

VAT applies to the subtotal after coupons in most setups, but the rule is configurable per event because the right answer depends on local tax law (and on whether the displayed price is inclusive or exclusive of VAT). The pricing-tier setup lets you set a tier as VAT-inclusive or VAT-exclusive, and coupons can be configured to apply before or after VAT depending on what your tax advisor says is correct. The detailed help article walks through each case.

You do. Eventtia is the data processor; you are the controller. We don't share or sell attendee data with third parties. The full registration history, transaction records, and audit trail export in standard formats whenever you ask — no retention fees, no export charges. The legal basis is in the privacy policy; operational handling is in the SLA.

Because the seams between a ticketing tool and an attendee database are where event ops go wrong. The ticketing tool says 1,847 sold; the attendee list says 1,802 confirmed; the badge printer pulls from a third spreadsheet that's a day stale; refunds happen in the processor but not in the attendee record, so the door staff lets someone in who already got their money back. Putting payment and attendee data in the same row eliminates the reconciliation. The cost is that the platform is more opinionated about how registration works; the gain is that the door is never out of sync with the books.