Chapter 15 — Account Credit & Ledgers
Attend onboarding guide · ~6 min read · ↑ Back to contents
The last chapter showed how a fan gets into a credit program. This one shows how that credit is spent — and introduces the one concept behind a surprising number of "my credit disappeared" support tickets: the ledger.
Account credit: sourced from the vendor, stored per-ledger in Attend
Account credit is a spendable balance tied to the fan's account. The vendor is the origin, but
Attend keeps its own per-ledger copy in tbl_user_account_credit (userId + ledgerCode →
accountCredit), joined into the session at login alongside account groups — so the fan's balance is
read from Attend's table, not fetched live on every page:
Example (planned flow): a Warriors fan owes $200 for a pack and has $50 of account credit. Attend applies the credit and charges the card only $150.
⚠️ Status: the payment plumbing already accepts a credit amount —
paymentRequestforwardsaccount_creditto the vendor when it's > 0 — but the cart-checkout flow doesn't pass one yet (the "bank of credit" work is what wires it through end to end; it shipped in V2). Reading the balance and the ledger mechanics below are real, current behavior.
A program has to have account credit enabled for any of this to show up. And because the balance lives in the vendor, reading it and topping it up are vendor-specific API operations.
Buying credit: two very different methods
How a fan adds credit depends entirely on which ticketing vendor the client uses:
| Vendor | Method |
|---|---|
| Ticketmaster | A direct API — enter a card and purchase credit straight away. |
| Tickets.com | No direct API, so Attend uses a dummy-event trick: create a dummy event worth the credit amount → the fan "buys" it → it's immediately returned → the money lands as account credit. |
The Tickets.com path is another reuse of the dummy-event idea from Chapter 9 — there's no real event, it exists only to move money into a credit balance.
Ledgers: why credit sometimes "disappears"
A ledger is a record-keeping scope in the ticketing system — almost always per season (e.g. "Ledger 2026"). It matters because two things belong to a ledger:
- Events belong to a ledger, and
- Account credit belongs to a ledger.
And here's the catch: credit in one ledger can't pay for events in another. Credit sitting in Ledger 2025 cannot be spent on Ledger 2026 events.
When a team enables account credit, Attend asks them for the ledger name, then reads the balance from that ledger via the API.
The classic support ticket: a fan insists they have $500 in credit but Attend shows $0. Nine times out of ten the credit is parked in last season's ledger, and the team simply hasn't moved it into the current one. The credit isn't gone — it's in the wrong ledger.
Recap
- Account credit is a balance on the fan's vendor account (not Attend); reading it is live, but spending it at checkout isn't wired into V3 yet (upcoming "bank of credit" work).
- Buying credit is vendor-specific: Ticketmaster via direct API, Tickets.com via a dummy event that's instantly returned.
- A ledger is a per-season record-keeping scope; events and credit both belong to one, and credit can't cross ledgers.
- "$500 credit but I see $0" is almost always credit stuck in an old ledger.
That's Part 3
You now have the configuration layer end to end: suites (real seats sold as a block, priced per event or per event×suite), the flex program shapes (BYO, game packs, tiers, predefined), the events and venues they're built from, and the access-and-money rules around them — gating, account groups, account credit, and ledgers.
Part 4 drops one floor down: how this whole model is actually built in the Flex v3 backend.
Next → Chapter 16 — Programs in Practice: One Active, Many Published