Chapter 22 — The Cart That Mirrors the Vendor
Attend onboarding guide · ~7 min read · ↑ Back to contents
Everything so far ends at the same place: a fan with seats picked, ready to pay. This chapter covers what happens from there — Attend's cart, and the money logic at checkout. (This is the load-bearing core; the internals live in Chapter 24, and the vendor-by-vendor checkout mechanics in Chapter 25.)
First, the freeing realization
Here's the thing that makes the whole cart system smaller than it looks: the real transaction happens on Ticketmaster. This seat, this event, this money — that's all TM ever sees.
Programs, packs, tiers, minimums, maximums? TM has no idea they exist. A game pack is just Attend's way of saying "pick 5 events and we'll sell the seats cheaper" — implemented by choosing which price code and ticket type code the seats go out at (Chapter 21). Build Your Own, game pack, preset package — by the time the purchase reaches TM, they all look identical: events, seats, prices.
Two consequences worth burning in:
- Switching the active program can't break anything bought before — old purchases are TM transactions, finished and gone.
- It can't even break a purchase in flight. A fan mid-checkout when the program flips is fine: their request goes to TM as-is.
Attend's cart mirrors TM's cart
TM creates its cart when a seat is held. Attend keeps its own cart alongside, and tries to keep the two as parallel as possible — with one deliberate difference:
V3 creates the cart at initialize — before any seat is held. The fan picks events, Attend opens an empty cart listing them as pending. New in V3, and purely for abandoned-cart analysis: if the fan walks away, the team at least knows which events interested them. No functional effect.
From there the mirroring is straightforward: hold seats → both carts update (per-event status: assigned / pending, totals recomputed); go back → cancelled on both sides. Attend's cart also stores the structure TM doesn't care about (which pack, which tier) and runs validation checks — pricing mismatches, seats missing from or extra in the cart — and reacts if reality has drifted.
The money at checkout
Three things decide what the card actually gets charged:
1. All-in pricing. Fans see one number: base price + service fee = all-in price. V2 let every team choose its own display style and it was chaos; V3 standardized on all-in only, unless a US state law forces a breakdown.
2. Payment plans. At checkout, the backend resolves the payment-plan context: if a plan applies, charge the first installment now; otherwise charge the total — full mechanics in Chapter 26. (Origin story: Miami's payment system can't authorize over $25k, so suites needed installments. Rather than hard-code an exception, a full reusable payment-plan architecture was built — in about a week.)
3. Account credit ⚠️ (planned — not wired into live checkout yet; the upcoming "bank of credit"
work). The intended design: if the fan has credit (Chapter 15), credit is used first and the card
covers the remainder, sent to TM's payment API in one request ("charge this card $30, use $70 of
account credit"). (There are no cardPaymentAmount/creditUsed columns on the order today — this
flow isn't implemented in V3.)
Example (planned flow): a Knicks fan with $70 credit buys a $100 all-in ticket on a 2-installment plan. Credit would eat $70; the plan splits the remaining $30; the card is charged $15 today. (Illustrative — the credit half isn't implemented yet.)
The four APIs that matter
Flex can feel enormous. Importance-wise, it's four calls:
| # | API | What it does |
|---|---|---|
| 1 | Get catalog | the program + its events (what's for sale) |
| 2 | Get inventory | the seats/suites + the prices you're eligible for |
| 3 | Manage cart | hold/release; keep both carts in sync |
| 4 | Checkout | resolve plan + credit, pay on the vendor |
Everything else — cart subroutines, payment helpers, snapshots, configs — is supporting noise around those four. "If these four are good, we are good."
Recap
- TM is the source of truth: programs/packs/tiers are Attend-internal selection cosmetics; switching programs can't affect past or in-flight purchases.
- Attend's cart mirrors the vendor cart (holds, cancels, totals) but is created early, at initialize, for abandoned-cart data — and it validates itself against pricing/seat drift.
- Checkout charges the all-in price, split by payment plan if one applies. Account-credit offset is planned, not yet wired — when it ships, TM's payment API handles card + credit in one request.
- The whole product reduces to four core APIs: catalog → inventory → manage cart → checkout.
Next → Chapter 23 — Add-ons: Anything Can Be Sold
Quick reference: endpoint, status, and payment-branch lookup tables are in Cart & Orders — Reference.