Example integrations

Four businesses, four different mixes

Scenario

A multi-sport camp operator

Runs 200 camps a season across a dozen cities. Has a marketing site they care about and a small ops team. They want registrations to happen on their own domain, and they never want to think about waivers or card data again.

https://riversidesports.com/camps

Both SDK pieces at once — our card grid injected into their page, and our checkout over the top. Their header, hero and filters stay theirs.

Product	Way	Why
Event listings	Embedded / SDK	Our rendered cards inside their own page, so the SEO stays on their domain without building card UI.
Express Checkout	Embedded / SDK	Visitors never leave the site, and the operator never handles card data.
Clear2Join clearance	Hosted	Comes free inside the checkout. Zero integration.
Org Parent Portal	Hosted	One nav link. Kills the "can I switch weeks?" inbox.
Customer Portal	Hosted	Their ops team builds events, runs check-in and reads revenue. No admin build.
Staffing	Not taken	They already have their own coaches.

Total build: a script tag, a server-side fetch for the card grid, and two links. Closest worked example: C · Our cards, your page.

Scenario

A university athletics program

Runs summer youth camps alongside the varsity season. No web developer on staff — the athletics site is managed by a central comms team with a long ticket queue. They need this live before registration opens.

https://gostate-athletics.com

Their athletics site — the pink nav item is the only change made.

my-v2.thegoodgame.com/s/org/…

Where it lands. Their camps, their logo, entirely our page.

Product	Way	Why
Event listings	Hosted	A link from the athletics site. No ticket with the web team.
Express Checkout	Hosted	Runs on our storefront page behind the Register button.
Clear2Join clearance	Hosted	Compliance matters here more than anywhere; it's built into the flow.
Org Parent Portal	Hosted	Parents self-serve instead of emailing the athletics office.
Customer Portal	Hosted	Coaches build their own camps without involving IT.
Staffing	API, eventually	Considering it for filling counselor gaps in peak weeks.

Total build: one link, maybe two. Closest worked example: A · Link to us.

Scenario

An officials / referee association

Assigns referees to games across a region. They already have a scheduling platform they like and they are not selling anything to parents. What they lack is a supply of background-checked officials and a way to prove clearance.

https://refassign.example.org/assignments

Not a single pink outline. Their own scheduler, unchanged. Behind each row: our jobs, our cleared-official pool, our offer states — reached entirely server-to-server.

Product	Way	Why
Staffing & jobs	API	Post assignments from their existing scheduler, search our cleared pool, send and negotiate offers. Nothing of ours renders in their product. Note this is the one scenario built entirely on an in-development product.
Clear2Join clearance	API	Push their own existing officials through clearance and gate assignment on the cleared status.
Everything else	Not taken	No registration, no checkout, no parent portal — none of it applies.

This is the shape that surprises people: the entire integration is server-to-server and there is no consumer-facing surface at all. Closest worked example: Staff from your own admin.

Scenario

A club with its own member platform

Year-round soccer club with a custom-built member area they've invested in heavily. They want their existing design system everywhere and sell season-long access rather than one-off camps — but they don't want to build payments or compliance.

https://members.riversidefc.com/sessions

Their member area, in their own design system — a session list they render from our API, not our cards. Only the checkout is ours.

Product	Way	Why
Event listings	API	They render sessions in their own components, inside their own member area.
Express Checkout	Embedded / SDK	The one piece they don't build — it keeps card data out of their stack.
Memberships	Hosted	Season passes as recurring subscriptions, with billing and renewals on our side.
Clear2Join clearance	Hosted	Collected in the checkout; cleared players carry it season to season.
Customer Portal	Hosted	Staff-only, so it never has to match the club's design system.
Org Parent Portal	Not taken	Their own member area already is the parent's home. They deep-link into it for waivers.

Total build: their listing and session pages, plus a script tag. Closest worked example: D · Build it all on our API.

The pattern

Two things fall out of those four, and they're the two most useful things to know before you scope anything.

The way is chosen per product

The club uses API for listings and SDK for checkout in the same page. The university uses Hosted for five things and API for one. Nobody picks a single lane.

Almost nobody builds checkout

All four leave the transaction to us, even the two with strong engineering teams — because that's what keeps card data and clearance capture out of their stack for zero effort.