Chapter 26 — Payment Plans: Splitting Big Money
Attend onboarding guide · ~7 min read · ↑ Back to contents
Chapter 22 mentioned payment plans in one paragraph. Here's the full machine — born because the Miami Dolphins' payment processor cannot authorize anything over $25,000, and suite purchases routinely are. Rather than hard-code an exception, a reusable plan system was built (in about a week — the team already knew the V2 implementation).
⚠️ Status: built, not yet live. The charging code is still in testing; the recurring-charge job isn't running in production yet. What follows is the design as implemented.
What the fan sees
A $50,500 suite on a $25k-per-installment plan: $25,000 today, $25,000 next month, $500 to finish. "No interest, no fees, automatic payment on the same card."
Per program, a config says whether plans are enabled and whether they're required — required means the fan cannot pay in full (the Miami case: nothing over $25k can go through anyway, so full-pay isn't offered).
Two schedule flavors
Fixed — the plan lists literal dates (the V2 model): "installments on June 20, July 20,
August 20." The wrinkle is daysPriorToCharge: a date within that window of "now" drops out, and
the plan shrinks — a 4-installment plan quietly becomes 3, then 2, then stops being offered at
all. (A flag can flip that behavior to "don't shrink — withdraw the plan instead.")
Dynamic — no dates, just a cadence: daily, weekly, biweekly, monthly, monthly-first, monthly-last (and as of this week, every-N-days). A cadence alone is dangerous — "if your bill is $1,000, I can take your installments to 1,000 weeks" — so at least one terminator must be set:
- total installments ("five payments"), or
- end date ("paid off before opening day"), or
- installment amount ("$25,000 per charge" — the Miami terminator).
Either flavor can add a first-installment carve-out ("$X now, the rest split equally"). Plans can also be gated like everything else — pack, package, minimum events, minimum/maximum cart total.
How the later installments actually get charged
This is the clever (and Archtics-only) part. TM applies money to an order top-down, line item by line item: pay $200 against five $100 events and the first two are paid, the third is half-paid, the rest pending.
So at checkout, Attend charges installment #1 through the normal payment request, then creates an invoice on the fan's TM account for the remainder. Each later installment is charged against the invoice — same payment API, different parameters. TM's own books always know exactly which events are paid off.
The ledger on our side (tbl_payment_plan_installments) tracks each installment's due date, amount,
status, and — when charging fails — a failure code, reason, and append-only history. A recurring job
will pick up the dues daily. (That job is the not-yet-live piece.)
Why not just schedule N card charges? Same answer as the Host checkout: "no bank will allow 10 payments back to back." The invoice makes the remainder one well-defined debt on the vendor's books instead of a pile of future card transactions.
Recap
- Payment plans exist because Miami can't process >$25k; per-program config = enabled + required (required ⇒ full-pay never offered).
- Fixed = literal dates that shrink as they pass; dynamic = cadence + a terminator (count, end date, or per-installment amount); optional first-installment carve-out; fully filterable like pricing rules.
- Installment #1 is charged at checkout; the remainder becomes a TM invoice, charged installment-by-installment — TM applies money to order line items top-down.
- Not yet live: the charging code is still in testing; the recurring job isn't running yet.