Chapter 25 — The Two Ticketmasters & the Host Checkout

Attend onboarding guide · ~8 min read · ↑ Back to contents

"Ticketmaster" has appeared in every chapter — but it's really two completely different ticketing systems under one brand, and the difference shapes the gnarliest code in the fan backend.

Archtics vs Host

	TM Archtics	TM Host
What it is	TM's enterprise back-office (season tickets, B2B)	TM's box-office / primary retail system
Status at Attend	everything you've seen so far — the most integrated vendor	wired on Flex v3 + Flow v3 only; not in production yet (certification cleared, contract in progress, no final key)
Inventory build	2–3 APIs	one API call
Cart model	one cart, many events	⚠️ one event per cart
Payment	native — card details forwarded, money settles to the team	Stripe — Attend charges the fan, remits to the team
Docs	static files, frequently stale (TM's own staff have older copies)	proper API portal

Integration history, for context: Archtics first, then Tickets.com, and SeatGeek very recently ("they're providing us new documentation with upgraded features").

The bombshell in that table is Host's cart model. When a fan's Attend cart holds 5 events with one add-on each, Archtics sees one vendor cart with 10 items. Host sees ten separate vendor carts that Attend masks as one. Nearly all the complexity in the cart/checkout code exists to hide that difference.

Checkout on Archtics: "very peaceful"

1. Validate — call shopping_cart, compare seats and prices to our cart (the self-correction from Chapter 24).
2. Checkout — one API call returns the cart items.
3. Payment request — pass the items + the method of payment. Money moves. Done.

Checkout on Host: "the nightmare"

Two systems must succeed in parallel: Stripe (our charge to the fan) and Host (the tickets). Reduced to its skeleton, Stripe works per order (create + confirm a payment intent, then capture it) and Host works per vendor cart (get shipping options → add shipping option → payment request → commit cart) — and the ordering of these steps is everything.

The full sequence, with the reasoning:

1. Create and confirm the Stripe payment intent — this verifies, with ~99% certainty, that the charge will succeed. No money moves yet. (Why first? If the card was going to decline, we must know before touching the vendor.)
2. Per vendor cart: get shipping options → add shipping → payment request — the billing step; on Host the invoice goes to Attend, because the fan pays Attend via Stripe. Still nothing permanent: any failure here just cancels all carts ("cart invalidated, start from scratch").
3. Commit every cart — the point of no return. Each commit puts tickets on the fan's Host account.
4. Capture the Stripe payment intent — now the fan's money moves.

And the failure matrix:

Failure at…	Consequence
Payment-intent confirm	"Payment failed — try another card." Nothing touched.
Shipping / billing	Cancel all vendor carts; fan restarts. Nothing permanent happened.
Commit (some carts already committed)	The committed ones go into tbl_checkout_refunds; a job retries the refunds every ~30 min (or the client refunds manually). Fan restarts.
Capture (after all commits)	The safety-net-on-safety-net. Steps 3→4 are milliseconds apart; "this has never happened."

Why involve Stripe at all? Because the alternative — using Host's own payment per cart — would mean charging the fan's card ten times back-to-back for one purchase. "No bank will even allow that." One Stripe charge, ten vendor commits.

The reassuring part: vendors are a 2–3% problem

After all that, the reassuring part flips the mood: per vendor, only two things are ever different — how to build inventory and how to sell it (hold + checkout). The catalog, get-inventory, snapshots, maps, programs, pricing rules — identical across vendors. Adding a whole new vendor touches roughly 2–3% of Flex: one inventory-build integration, one process-hold function, one process-checkout function.

That's also why the Flow product is tiny — "the entire Flow product is one third of what add-ons are in Flex": two tables (tbl_events, tbl_products — what to sell, for which event), best-available holds everywhere. (Possibly gaining seat-specific holds soon for wheelchair-accessible seating.)

Recap

• Two TMs: Archtics (everything so far, native payments, stale file-docs) vs Host (one-event-per-cart, Stripe, not yet in production).
• Archtics checkout = validate → checkout → payment_request.
• Host checkout = confirm Stripe PI → shipping/billing per cart → commit all carts → capture PI; partial-commit failures land in tbl_checkout_refunds for retry.
• Stripe exists on Host so one purchase is one bank charge instead of ten.
• A new vendor = ~2–3% of the codebase: build inventory + sell inventory. Everything else is shared.

---

Next → Chapter 26 — Payment Plans