Checkout from a backend

The checkout endpoints let a custom event site sell exactly what the platform sells — tickets, add-ons, bundles, redemption codes, free and paid — with orriven handling what it already does underneath: capacity holds, payment on Stripe, settlement by webhook, fulfilment into registrations and perks, and the ticket email to the buyer.

On this surface the path is always buyer → frontend → backend (holding the API key) → orriven. The key can read and write the whole Business Unit, so it must not ship to a browser. The backend must return only that signed-in buyer’s orders and registrations. Buyer accounts are built by the integrator: orriven hosts no attendee sign-in and identifies buyers by email.For a site with no backend, the same checkout sessions are available from the browser with a publishable key. See the Storefront API.

Two ways in

	Checkout session (recommended)	Direct place / confirm
The backend sends	The selection, what is known about the buyer, a `returnUrl`	Email, name, items, form answers — the whole order
orriven’s hosted pages	Collect the rest, hold the seat, take payment, show the result, return the buyer	Only the payment (Stripe) and, unless the backend passes its own return URLs, the order result
Best when	Buyer identity, the registration form, and payment should be handled by the platform	Every step is rendered by the integrator and only settlement is needed

Checkout sessions

Show what is on sale

Render the event page from GET …/ticket-types (names, prices, sale windows, statuses), …/availability (live remaining numbers), …/addons, …/bundles, …/venues, …/sessions (the agenda), and …/speakers. When the buyer enters a redemption code, preview it with GET …/redemption-codes/lookup?code= — the unlocked ticket, its perks, and the discounted price, before anything is placed.

Create the session and redirect

curl -s -X POST "$BASE/v1/events/$EVENT/checkout-sessions" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "itemType": "registration_type", "itemId": "…", "quantity": 1 },
      { "itemType": "addon",             "itemId": "…", "quantity": 2 }
    ],
    "email": "ada@example.com",
    "name": "Ada",
    "redemptionCode": "VIP2026",
    "returnUrl": "https://tickets.example.com/thanks"
  }'

201 returns { "id", "url", "expiresAt" }. Send the buyer to url — orriven’s hosted checkout page. Everything in the body except items is optional: the page asks for whatever was not provided (email, name, the ticket’s registration form answers, add-ons). A prefilled email is shown masked and cannot be changed by the buyer. The session lives 24 hours and holds no seat. The hold starts when the buyer places the order from it. GET …/checkout-sessions/{id} reports whether it has produced an order (orderId).

Take the buyer back

After payment (or immediately for a free order) the buyer sees the hosted order page and its Return to organizer button, which goes to the returnUrl with ?order=<orderNumber>&status=<status> appended. status=paid means the seat, the perks, and the entry pass exist. Anything else (expired, cancelled) means the buyer walked away. If returnUrl is omitted, the button uses the event’s page address from the console.

Confirm on the backend

The backend can read the order at any time: GET …/orders (or by id) shows status, registrationId once fulfilled, orderUrl (its hosted page), and checkoutUrl while it is still open. Settlement of paid orders arrives by the platform’s Stripe webhook, never by this call. Poll until paid before acting on it server-side.

Direct place and confirm

For a checkout rendered entirely by the integrator, the three steps remain:

Place the order

curl -s -X POST "$BASE/v1/events/$EVENT/orders" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{
    "email": "ada@example.com",
    "name": "Ada",
    "items": [
      { "itemType": "registration_type", "itemId": "…", "quantity": 1 },
      { "itemType": "addon",             "itemId": "…", "quantity": 2 }
    ],
    "redemptionCode": "VIP2026",
    "returnUrl": "https://tickets.example.com/thanks"
  }'

201 returns the pending order. It holds its places for 15 minutes and carries orderUrl, the hosted order page the buyer can be handed for the review-and-pay step. A buyer already registered in the event returns 200 with alreadyRegistered: true: acknowledged, never double-booked. A full ticket returns 412.

Confirm — free settles, paid gets a Stripe page

curl -s -X POST "$BASE/v1/events/$EVENT/orders/$ORDER_NUMBER/confirm" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{
    "successUrl": "https://tickets.example.com/thanks?order='"$ORDER_NUMBER"'",
    "cancelUrl":  "https://tickets.example.com/checkout?order='"$ORDER_NUMBER"'"
  }'

A free order (total 0) settles immediately: {"status":"paid", "registration":{…}, "created":true}. No Stripe involved.
A paid order returns {"status":"awaiting_payment", "paymentUrl":"https://checkout.stripe.com/…"}. Redirect the buyer there. successUrl/cancelUrl are optional: with them, Stripe returns the buyer straight to the integrator’s pages (https only — plain http is allowed for localhost); without them, the buyer lands on the hosted order page, which returns them to the order’s returnUrl.

Wait for settlement

Payment settles through the platform’s Stripe webhook, not through this call. Poll GET …/orders/{orderId} until status is paid and registrationId is set. That is when the seat, the perks, and the check-in code exist.

”My tickets” on the site

The platform emails every confirmed buyer an entry pass link — the hosted page with their check-in QR, wallet passes, certificate, and surveys. It opens for anyone holding the link and the buyer’s email, so it is safe to show again inside a custom site. Build the page server-side, filtered to the person the backend authenticated:

Registrations (GET …/registrations?email=) — exact-email filter. Each carries status, the ticket type, the checkinCode for rendering the QR directly, and passUrl, the hosted entry-pass page to link to.
Regenerate a link (POST …/registrations/{id}/rotate-access-token) — every earlier address stops working immediately. The response carries the new passUrl. Use it when a link was forwarded somewhere it should not have been.
Perks (GET …/registrations/{id}/perks) — the effective union of ticket ∪ code ∪ individual grants.
Check-ins (GET …/checkins?registrationId=) — usage history.
Orders — purchase history, each with orderUrl.

Constraints

One order, one seat. The registration model is one person per event, so an order carries at most one ticket seat (412 otherwise). A buyer purchasing for friends places one order per person, each with that person’s email. Add-ons may repeat.
The order number is the order’s credential on this surface. Keep it server-side with the same care as a session token for that buyer. The hosted pages additionally ask the buyer for the order’s email.
A pending order holds capacity for 15 minutes. Confirming a paid order stretches the hold to 35. Cancel (POST …/orders/{orderNumber}/cancel) to release it early. Cancelling twice acknowledges.
A checkout session holds nothing until the buyer places from it, and expires after 24 hours. An expired session returns the same 404 as one that never existed.
Regenerating a pass link is irreversible. Resend the buyer their ticket (or show the new passUrl in the site) afterwards.
If payments are not configured for the Business Unit (no Stripe onboarding), placing a paid order returns 412. The free path works regardless.
Automations and the ticket email fire the same as the platform’s own checkout — order placed/expired/cancelled and registration triggers behave identically.

Endpoint reference

Schemas for sessions, place, confirm, and cancel.

Orders (console view)

How the same orders look to the organizer.

Get started

Reference

Endpoints

Storefront endpoints

Two ways in

Checkout sessions

Direct place and confirm

”My tickets” on the site

Constraints

Endpoint reference

Orders (console view)

​Two ways in

​Checkout sessions

​Direct place and confirm

​”My tickets” on the site

​Constraints

​Related

Endpoint reference

Orders (console view)

Two ways in

Checkout sessions

Direct place and confirm

”My tickets” on the site

Constraints

Related