Registration & Checkout

We handle these no matter which option you pick

Your options

Three ways in. If you'd rather see them as complete paths than as a menu, skip to the examples — or see all three side by side on Ways to integrate.

Storefront & booking Live

Server-rendered, crawlable pages on our domain, scoped to your organization. Link to them from your navigation and you have a working registration business.

These render without JavaScript and are indexable — but the SEO credit lands on our domain. If you want it on yours, use event-card fragments or the event API instead.

Customer Portal — your team's console Live

The operator side, and the part partners most often don't realise they're getting. Your own staff sign in at app-v2.thegoodgame.com and run the whole business from there. It comes with every integration option — you never build admin screens.

Everything your team creates here is what the public API and the checkout drawer then expose to your customers — one source of truth, two audiences. See it on Ways to integrate.

Org-Scoped Parent Portal Live

Checkout is the transaction. The portal is everything after it — and that's where most of the support burden actually lives. A parent who bought from you gets a self-service account, branded as your organization, that only ever shows them your events.

Add it to your account menu as "Manage my registrations" and you're done. No hosting, no build step, no data sync. It pairs with either the hosted storefront or the embedded drawer.

What a parent can do

Getting a buyer from checkout into the portal

The checkout and the portal are both served from {WEB_BASE_URL} — the same origin, no matter whose site the checkout was embedded on. So the account a buyer creates while checking out is their portal account. There's no user record to sync, no SSO handshake to implement, no identifier to map, and you never hold a credential.

Under the hood a login on either surface sets an HttpOnly refresh cookie (tgg_rt), and the other surface silently redeems it on boot via POST /auth/session — both halves are live in production, so a buyer who signed in during checkout normally lands in the portal already authenticated.

Best-effort, not guaranteed. The cookie is third-party from your page, so browsers that partition storage may withhold it until the drawer is granted Storage Access. Then the parent signs in once at the org sign-in screen. Treat a sign-in prompt as a normal outcome, not a bug — the deep links work either way.

# The portal home — put this in your account menu
{WEB_BASE_URL}/org/{organization_id}/manage

# Straight to one booking — use after a checkout completes
{WEB_BASE_URL}/org/{organization_id}/manage/bookings/{booking_id}

# Behind auth, surviving the sign-in bounce
{WEB_BASE_URL}/org/{organization_id}/manage/signin?redirect=%2Forg%2F{organization_id}%2Fmanage%2Fbookings

To get {booking_id} at the moment of purchase, listen for booking-complete on the drawer — see the JavaScript API. Branding and feature toggles are set on your organization record.

Memberships Live

Recurring revenue alongside one-off bookings. A membership is a subscription your organization publishes; families buy it once and it then covers the events you say it covers. Billing, renewals and cancellation all run on our side.

Where each side manages it

• Your team creates and publishes memberships in the Customer Portal.
• Families see and cancel theirs in the Org-Scoped Parent Portal. The page is hidden entirely for organizations that don't publish any, so it never shows an empty screen.

Memberships are configured in the portal rather than over the API today — there's no public membership endpoint yet. Tell us if you need one.

Checkout drawer Live

One script tag and one button attribute puts our entire registration and payment flow on your site. It opens as a full-viewport overlay on top of your existing page, so you don't need a dedicated event-detail page — trigger it from a listing, a hero CTA, a card, anywhere.

Because everything inside the drawer is served and processed by us, you stay out of payment handling entirely — card data never touches your page or your servers.

What's inside the drawer

Install

<!-- once, before </body> -->
<script src="https://my-v2.thegoodgame.com/embed.js" defer></script>

<!-- auto-wired on DOMContentLoaded -->
<button data-tgg-checkout data-event-id="{event_id}">
  Register Now
</button>

<button onclick="TGGCheckout.open({ eventId: '{event_id}' })">
  Register Now
</button>

Drawer JavaScript API Live

The loader exposes window.TGGCheckout.

data-org / open({ org }) is accepted and reserved for multi-org hosts, but does not yet change behavior — pass eventId only.

Choose your checkout mode

Your organization can use either of these two checkout modes:

In Multi-Camp Cart mode, the buyer picks a session and tickets for each camp, then registers each participant for the camp they are attending. If your organization has a multi-camp discount, the cart earns it.

The no-JavaScript integration. Tag your camp cards and we do the rest — we bind the clicks, hold the cart across pages, draw the cart, and open checkout:

<!-- One per camp card. data-option-id, data-qty and data-title are optional. -->
<button data-tgg-add-to-cart data-event-id="{event_id}" data-title="{camp_name}">
Add to cart
</button>

<!-- Optional: your own "View cart" entry point and a count to keep in step. -->
<button data-tgg-open-cart>Checkout</button>
<span data-tgg-cart-count>0</span>

Cards that mount after the script (any single-page storefront) are handled — the clicks are delegated, so a camp card rendered on a later route works with no re-binding. The cart lives in your site's localStorage, so it follows the buyer from page to page on your domain.

The cart we draw. When the setting is on and the cart has something in it, a round cart button with a count badge appears on your page; it opens a panel listing the camps with a Remove link and a Check out button. You can restyle it to match your site — but not switch it on or off, which stays with the organization setting:

TGGCheckout.init({
cartWidget: {
  accent: '#0077FF',      // count badge + Check out button
  buttonColor: '#111',    // the round cart button
  iconColor: '#fff',      // the cart icon; omit it and we pick white or near-black to suit buttonColor
  position: 'auto',       // the default — or bottom-right / bottom-left / top-right / top-left
                          // / top-center / bottom-center
  label: 'Your camps',    // the panel's heading
  checkoutLabel: 'Check out',
},
});

// Or restyle it later, after init:
TGGCheckout.cart.widget({ buttonColor: '#ffffff', position: 'bottom-left' });

position: 'auto' starts bottom-right and moves out of the way of whatever your page already pins to its corners — a chat launcher, a cookie banner, a sticky header — trying bottom-right, bottom-left, then the top two corners. Next to a chat launcher it lines up above it. A position you name is kept: we only lift the button within it, never move it elsewhere. Colours must be plain CSS colours; anything else is ignored.

Prefer your own cart UI? Drive it from cart.* and on('cart', …) and call openCart(). Our cart button still appears while the setting is on — it cannot be hidden from your code — so restyle and place it to sit alongside yours.

Opening a cart from a link. There is no URL parameter on your page that fills the cart — the loader does not read one. To send a buyer straight into a multi-camp checkout, read your own parameter on page load and call cart.add(…) for each camp, then openCart().

When your organization does not have the cart

• Our cart button is never drawn, and every data-tgg-add-to-cart button is hidden.
• cart.* still stores camps, and on('cart', …) still fires — so a cart built by your own code can still reach the drawer.
• The drawer refuses a cart of two or more camps: it says {organization} takes one camp per checkout, holds Continue, and the Remove link on each camp gets the buyer back to one camp, which checks out as normal.
• The order API answers 403 to an order of two or more camps.

Camps from more than one organization

One checkout is always one organization's camps. If a cart mixes organizations, the cart panel warns before checkout that the camps cannot be paid for together, the drawer refuses with These camps are run by different organizations and holds Continue until the buyer removes camps, and the order API answers 400.

Discounts in a cart

Automatic discounts are set up on your organization's Discounts page (Organization → Money → Discounts in your TGG console, or by your TGG contact) and on each event's Discounts section in the event builder. Nothing in your code sets them. They come off in a fixed order, and the summary lists them in that order: Early bird, Sibling discount, Package discount, Multi-camp discount, then any coupon.

• Multi-camp discount. Money off for booking several camps in one checkout — for example 2 camps → 5% off, 3 camps → 10% off. The best tier the buyer reaches applies. It counts camps by default (two children in one camp are already served by the sibling discount), a free camp does not count, and it can be limited to named camps or event types. It is taken off either the full ticket price or the price after the discounts above it (sibling and package). It can run between two dates; outside them it does not apply. The drawer shows it as its own line, such as 2 camps — 5% off, and as Multi-camp discount on the confirmation.
• Early bird and sibling discounts apply per camp, exactly as they do in a single-camp checkout: an early bird shows as an Early bird line under the ticket price, a sibling discount as Sibling discount.
• The next rung. When the cart is below a higher rung, the payment step says so — Add 1 more camp and save 10% — with an Add a camp button. The button closes the drawer: the cart lives on your page, so the buyer is back at your camps with the cart intact, and your cart button reopens it.
• Coupons. A code applies only to the camps it is valid for, and the summary names the camps it came off. Each coupon is set, when it is created, to apply Once per checkout (one use; a fixed amount comes off once, split across the camps it covers) or Each camp (one use per camp; a fixed amount comes off each). A percentage comes off each camp it covers either way.

Payment, confirmation and email

The buyer authorizes one charge for the whole cart. When a camp is sold on a deposit or instalment plan, that charge takes its deposit or first instalment alongside the full price of the other camps, and the rest of that camp's plan is billed on its own schedule. After payment the drawer shows an order summary for the cart — subtotal, discounts, fees, total, paid today and any balance due later — with a link to each camp's registration.

booking-complete fires once for the whole cart, with the first camp's booking, and the cart is emptied. The buyer gets one order confirmation (email, SMS, push and in-app) once every camp is confirmed, listing each camp with its dates, location and add-ons, each discount on its own line, the order total and what was charged today. It replaces the per-camp booking confirmation for those bookings; each camp's coach still gets their own booking notification.

// embed.js is deferred, so wait for load before touching TGGCheckout.
window.addEventListener('load', function () {
  TGGCheckout.on('booking-complete', function (e) {
    dataLayer.push({ event: 'registration_complete', booking_id: e.bookingId });
  });

  TGGCheckout.on('close', function () {
    console.log('checkout dismissed');
  });

  // Optional: pre-warm on an event page so the first open is instant.
  TGGCheckout.init({ eventId: '{event_id}' });
});

How the embed behaves on your page

Useful when you're debugging z-index, CSP, or analytics on a host page.

Event-card fragments Live

The most interesting option if you care about search: we render just the event-card grid, with no page chrome, and you inject it server-side into your own template. Google crawls your URL and sees fully-rendered listings.

1. Fetch it server-side when your page renders
   cURL Copy

   curl "{WEB_BASE_URL}/s/org/{organization_id}/events/fragment?city=Fort%20Worth&sport=Tennis&size=12"

2. Extract and inject the grid

   The response is an HTML document; the piece you want is the single element marked data-tgg-fragment="events". It carries data-tgg-total, data-tgg-page and data-tgg-size so you can render your own pagination.

   HTML (returned) Copy

   <div data-tgg-fragment="events" data-tgg-total="192" data-tgg-page="0" data-tgg-size="12">
     <div class="grid …">
       <!-- one rendered event card per event -->
     </div>
   </div>

3. Style it and wire the buttons

   Scope your CSS to [data-tgg-fragment], then add data-tgg-checkout data-event-id="…" to the Register buttons so they open the drawer.

Fragment filters (this is the SSR fragment vocabulary, not the JSON API's — see Event list for that one): city, market, zipCode, sport, activityId, eventType, q, minPriceCents, maxPriceCents, minAge, maxAge, genderPolicy, tag, dateFrom, dateTo, sort, page, size. Status is checked against an allowlist, so ?status= cannot reach drafts or cancelled events; ?sort=past and ?sort=all widen it to include completed. Visibility is a separate axis — the fragment forces public-only, unlike the JSON list above.

Chrome-free iframe pages Live

If you'd rather embed whole pages than build them, the server-rendered routes have an /embed variant with our site chrome stripped, sized to drop into an iframe on your layout.

An iframe is opaque to crawlers. If search matters, prefer fragments, which put the markup in your own document.

Event list Live

Every published event across every coach in your organization. Note the default includes events marked private — pass isPrivate=false for only the publicly-listed ones.

curl "{API_BASE_URL}/api/v1/organizations/{organization_id}/events?size=20&sportName=Tennis"

{
  "data": {
    "total": "20",          // string — parse it before you paginate
    "data": [ /* events */ ] // note: data.data, not data
  },
  "timestamp": "2026-08-13T16:44:41.360Z"
}

Event detail Live

Schedule occurrences, venue, the pricing plan with every purchase option, participation requirements, registration features, organizer, activity, FAQs, and the vanity slug. Accepts a UUID or a legacy numeric id.

{
  "data": {
    "event": {
      "id": "9f8e7d6c-0000-4111-a222-333344445555",
      "title": "Summer Tennis Camp — Session I",
      "eventType": "Camp",
      "status": "published",
      "registrationModel": "per_event",
      "timeZone": "America/Chicago",
      "pricingCurrency": "USD",
      "occurrences": [
        { "date": "2026-08-03", "startTime": "14:00:00", "endTime": "21:00:00", "status": "scheduled" }
      ],
      "venue": {
        "name": "Riverside Varsity Courts",
        "address": { "line1": "123 Main Street", "city": "Fort Worth", "region": "TX", "postalCode": "76109" }
      },
      "pricingPlan": {
        "purchaseOptions": [
          {
            "id": "dddd1111-2222-3333-4444-555566667777",
            "name": "Full Day Ticket",
            "priceCents": 64500,
            "priceCentsWithFees": 70950,
            "audienceType": "participant",
            "capacity": 50,
            "registrationCount": 12
          }
        ]
      },
      "participationRequirements": { "minAge": 5, "maxAge": 18, "genderPolicy": "any" },
      "registrationFeatures": { "capacityLimit": 100, "capacityMode": "hard_cap", "registrationOpen": true },
      "slug": "summercamp"
    }
  },
  "timestamp": "2026-08-06T17:57:02.785Z"
}

Companion reads

description fields contain sanitized HTML — render as rich text or strip tags. Every monetary field is an integer in cents.

Pricing & availability Live

The bootstrap the checkout drawer itself uses. Read it so your own page can't advertise a session the drawer will refuse.

Booking writes Planned

There is no server-to-server booking or payment endpoint today. This is the one real limit on an API-only registration integration, so it's called out rather than buried.

The parent-facing /ec/* endpoints the drawer calls are authenticated as the parent, not as a partner — they aren't a server-to-server surface and aren't documented as one.