Tickettypen en registratie voorbereiden

De verkoop voorbereiden

1. Leg vast wie de verkoper is en welke betaalwijzen voor de editie gelden.
2. Open de tickettypen van de editie en maak de benodigde varianten aan.
3. Controleer prijs, beschikbaarheid, capaciteit en de periodes waarin het product wordt aangeboden.
4. Configureer opties en aanvullende vragen alleen waar ze voor registratie nodig zijn.
5. Test de hele bestel- en bevestigingsroute met fictieve koper- en deelnemersgegevens.

De screenshot verifieert het beheer-ingangsscherm. De volledige kopercheckout is in deze documentatieronde niet uitgevoerd; verifieer die keten op de geïnstalleerde release voordat je verkoop opent.

Formulieren en antwoorden

Gebruik de formulierfunctionaliteit voor de bedoelde vragen. Houd de gepubliceerde vraagversie en antwoorden bij elkaar. Een later gewijzigde vraag mag een eerder antwoord niet stilzwijgend een andere betekenis geven.

Vraag alleen gegevens die voor de taak nodig zijn. Een koper kan meerdere deelnemers bedienen; maak registratievragen niet per ongeluk afhankelijk van uitsluitend de koper.

Koper als persoon of bedrijf

Een bestelling heeft één koper: een persoon of een bedrijf. Een persoon als koper kan geen bedrijfsnaam of btw-nummer hebben. Een bedrijf als koper heeft een niet-lege bedrijfsnaam nodig. Bij nieuwe bestellingen is de bedrijfsnaam hooguit 200 tekens en het btw-nummer hooguit 20. Langere invoer wordt geweigerd met 400 en de veldfout too-long op buyer.company.name of buyer.company.vatIdentification. Bestaande bestellingen veranderen niet.

Deze regels gelden voor bestellingen die medewerkers via de beheer-API plaatsen (POST /v1/admin/commerce/events/{eventId}/orders). Bij zelfbediening en vouchers kan geen bedrijf worden ingevuld. Er is nog geen scherm om een bedrijf als koper in te voeren.

Registratievoorwaarden en hun versie

Een tickettype kan registratievoorwaarden hebben, per taal geschreven (maximaal 20.000 tekens per taal). Elk tickettype heeft ook een voorwaardenversie. Die begint bij 1 en gaat met 1 omhoog wanneer een opslag de voorwaarden wijzigt op een manier die een koper leest: de tekst in een taal verandert, er komt een taal bij of er gaat een taal af. Verschillen in alleen witruimte rond de tekst tellen niet. Andere registratie-instellingen opslaan of het tickettype hernoemen laat de versie ongemoeid. Dit is niet de version van het tickettype (de If-Match-waarde), die bij elke bewerking verandert. Bestaande tickettypen kregen versie 1.

De versie is termsVersion in AdminRegistrationConfiguration, teruggegeven door GET en PUT /v1/admin/commerce/events/{eventId}/ticket-types/{ticketTypeId}/registration. Ze is alleen-lezen: je kunt haar niet instellen. Commerce biedt andere modules ook een leesactie voor de huidige versie, voor de leadonthulling (zie sponsors en leads en privacy).

Als twee mensen tegelijk de voorwaarden wijzigen, wint één opslag. De andere wordt geweigerd met 412 en krijgt geen versienummer; lees het tickettype opnieuw, sla nog een keer op en de nieuwe tekst krijgt het volgende nummer.

Ik heb in de beheerapp in de gecontroleerde revisie geen scherm voor registratievoorwaarden of hun versie gevonden; beschouw dit als alleen via de API.

Een claimlink voor een gratis ticket opnieuw uitgeven

Een gratis ticket kan als claimlink worden uitgegeven. Is de ontvanger de link kwijt voordat die is geclaimd, dan kan een collega met commercebeheer een vervangende link uitgeven:

1. Controleer dat het ticket een gratis claimlinkticket is, nog niet is geclaimd en niet is ingetrokken.
2. Vraag een vervangende link aan voor dat ticket, met de ticketversie die je het laatst hebt gelezen (If-Match).
3. Geef de nieuwe link via een betrouwbaar kanaal aan de ontvanger. Hij wordt één keer getoond.

De oude link werkt meteen niet meer. De vervaldatum blijft gelijk en loopt dus nooit voorbij het einde van de editie. Een verlopen link kun je zo niet weer tot leven wekken.

Dit kan voorlopig alleen via de API: POST /v1/admin/commerce/events/{eventId}/tickets/{ticketId}/replacement-link (replaceAdminClaimLink) antwoordt met 201 en de nieuwe link. Weigeringen: 409 ticket-already-claimed, place-withdrawn, claim-link-expired, not-a-claim-link of belongs-to-an-order; 404 bij een onbekend ticket; 428 zonder If-Match en 412 bij een verouderde versie. De beheerapp heeft er nog geen knop voor.

Na een bestelling

Controleer de order en het resultaat per deelnemer. Voor betaalstatus, facturen en terugbetalingen gebruik je betalingen en administratie. Voor groepsorders en gereserveerde plaatsen gebruik je groepen en workshops.

Voer ook een proef uit met uitverkocht aanbod, verlopen keuze, geweigerde betaling en een dubbele bevestiging. Alleen een geslaagde eerste bestelling bewijst die situaties niet.