Tickets → pay → check-in
End-to-end journey when Eventyvo holds tickets — plus hybrid when registration started on your site.
Two data situations
| Situation | What to do |
|---|---|
| Registered only on your website | Mirror/approve into Eventyvo before payment-on-Eventyvo or QR check-in can work; or move registration to Eventyvo forms |
| Already on Eventyvo | Follow the journey below |
Goal
Register (Eventyvo form / CTA / subwebsite) ← Model A for visitors
→ optional payment (return URLs on Eventyvo)
→ approval / ticket QR
→ door scan (app or POST /api/v1/checkin) ← Model B
→ ATTENDANT_CHECKED_IN webhook ← Model B
If you only need a register button and run doors in the Eventyvo app, stop at Model A — Two website models.
1 — Registration
| Channel | Notes |
|---|---|
| Registration CTA | Button → Eventyvo |
| Subwebsite Register | Full hosted form |
| Hybrid | Your form → CSV into Eventyvo |
Webhooks: FORM_SUBMISSION, FORM_SUBMISSION_APPROVED.
2 — Payment
Listen: PAYMENT_SUCCESS, PAYMENT_FAILED, PAYMENT_REFUNDED. No Connect card fields on your site.
3 — Ticket / QR
Issued by Eventyvo after approval/payment (module-dependent). Store submissionId from webhooks if you reconcile in your CRM.
4 — Check-in
POST https://api.eventyvo.com/api/v1/checkin
X-API-KEY: ev_live_xxxxxxxx
{ "code": "<scanned-string>" }
Details: QR check-in.
Checklist
- People exist as Eventyvo submissions before scan
- Webhooks HMAC-verified
- Door devices use a secure backend
- Idempotent check-in handling