A paid pool moves real money between the commissioner and the entrants. OfficePoolGolf does not touch any of it. The platform tracks who owes what, who has paid what, and what each winner is owed at the end — and the commissioner moves the actual funds through whichever payment app the group uses. This guide walks through the full workflow, the payment statuses, the payout flow, and the practical patterns that keep paid pools clean.
OPG never handles money. The platform tracks payment status and payout amounts; the commissioner transfers funds off-platform. Birdie pools get the ledger; Eagle and above add bulk actions and lifecycle emails.
The principle — track on platform, transfer off platform
This design is deliberate. Office pools are small-dollar peer-to-peer transactions; involving a payment processor adds fees, KYC requirements, and legal exposure that outweigh any convenience the integration would provide. The two-screen pattern — OPG tracks, payment app transfers — keeps the platform free and the commissioner in control.
The commissioner does need a payment-app handle that the group can pay to. Most office groups already share one. The pool's payment-info card (Par and above) displays whichever handle the commissioner enters, and entrants pay directly to that handle.
Setting up payment info during pool setup
The wizard's payment screen asks two things from the commissioner: the entry fee amount and the payment handle the group should pay to. Both are optional during draft mode; both are required before the pool can publish if the entry fee is non-zero.
The payment-handle field accepts whichever app the group uses. The platform does not prescribe a specific payment app — the field is a free-text handle that the commissioner types in, paired with a label naming which app the handle is for. The pool page renders this back to entrants as "pay your entry fee to [handle] on [app]." Entrants see the handle as soon as they submit a roster.
A commissioner who runs multiple pools can copy a previous pool forward and the payment info comes along. The copy-pool feature available from Birdie up saves the payment-info typing on the second pool of the season.
The payment status state machine
Every paid pool's ledger uses five states for each entry. The states form a small state machine the commissioner walks each entry through.
Unpaid is the initial state. The entry exists; the entrant has submitted a roster; the entry fee has not arrived. New entries land here automatically.
Submitted is the entrant-attested state. On Birdie-and-above pools, an entrant can mark their own row as "payment submitted" once they have sent the funds through the payment app. This is a self-attestation only — the commissioner has not confirmed receipt yet. The row visually signals "the entrant says they paid; the commissioner still has to verify."
Confirmed is the commissioner-attested state. The commissioner has received the funds in their payment app and clicked through the ledger to mark the row confirmed. This is the terminal positive state — the entry is settled.
Rejected is the exception state. The commissioner expected payment but the funds did not arrive in the right amount or from the right account. The row stays visible as a flag; the commissioner can move it back to submitted (the entrant resends) or unpaid (the dispute restarts).
Waived is the comp state. The commissioner has explicitly let this entry play without an entry fee — usually a courtesy spot, a comped entry for a coworker, or a make-good for a prior issue. The row is settled but the entry fee is not in the pool, so the payout pool size is the entry-fee total of the non-waived entries.
The ledger view on the commissioner dashboard shows every entry's current state in a single table with one-click status changes. Birdie pools get individual status changes; Eagle and above get bulk-action affordances on top.
The end-to-end flow
Set up the payment handle
During pool setup, enter the entry-fee amount and the payment-app handle. Both render on the pool page. Once the pool publishes, the entrants see the handle as soon as they submit a roster.
Entrants submit rosters and pay directly to your handle
Entrants submit their rosters through the platform, then send the entry fee to the commissioner's payment-app handle through whichever app they prefer. The platform tracks the roster; the payment app handles the funds.
Entrants self-report on Birdie and above
When an entrant pays, they can mark their own row as "payment submitted" on Birdie-and-above pools. This is optional — many entrants skip it — but it shortens the commissioner's reconciliation work by surfacing which entries claim to have paid.
Commissioner confirms each payment as funds arrive
The commissioner cross-references the payment app's transaction list against the ledger. Each matched entry moves from unpaid (or submitted) to confirmed. Eagle pools support bulk confirm — mark every submitted entry as confirmed in one click — which speeds the work on pools with many entries.
Lock and play
Once the pool locks, the ledger continues to fire reminders for unpaid entries (Eagle and above) right up to the start of the tournament. Late payments are allowed up until completion — the commissioner can confirm a payment a day before the final round.
Tournament completes and payouts surface
When the tournament reaches
completed, the platform calculates each winning entry's payout amount from the configured payout structure and the actual pool size. The payout-tracking table (Eagle and above) shows what each winner is owed.Commissioner sends payouts off-platform
The commissioner sends each winner their payout through the same payment app. The payout-tracking table lets the commissioner mark each payout as paid, closing the ledger for the pool.
Tier differences on payment management
Par displays the payment handle on the pool page but offers no ledger. The commissioner tracks payments outside the platform — on paper, in a spreadsheet, in their head. This is fine for ten-person pools where everyone is in the same room.
Birdie adds the full ledger. Each entry has an individual status; the commissioner can toggle states one at a time; entrants can self-report. Birdie also enables individual reminders — a one-click "your entry fee is outstanding" message to a specific entrant.
Eagle adds bulk payment actions, the commissioner dashboard, lifecycle emails (pre-lock warnings to unpaid entrants fire automatically), and payout tracking. The bulk actions are the dial-up that makes a fifty-entry paid pool tolerable to run.
Albatross adds broadcast announcements and richer commissioner analytics, which surface payment trends across multiple pools the same commissioner is running. Most paid pools do not need this depth — Eagle is the sweet spot for serious paid leagues.
Practical patterns for clean paid pools
A few patterns hold across most paid pools:
Confirm payments in batches, not in real time. Checking the payment app every time a self-report fires is exhausting. Most commissioners do a sweep once a day during the open window — twice on the days before the lock — and clear every confirmed payment at once. Eagle's bulk-confirm makes this a single click for a pool with many submitted entries.
Be explicit about the entry-fee deadline. The pool's lock deadline is the structural deadline; communicate it as the payment deadline too. "Pay by Wednesday at five or your entry will not be eligible" is clearer than "pay before the pool locks."
Use rejected sparingly. Most "payment did not arrive" cases turn out to be the commissioner missing a transaction in the payment app's list, not the entrant skipping payment. Before marking a row rejected, search the payment app one more time. Rejected rows create awkward conversations the commissioner does not want to start without good reason.
Send payouts within a week of completion. Payout latency is the single biggest factor in whether the group runs another pool next time. A commissioner who pays out within 48 hours of completion runs a tighter ship than one who waits a month. Eagle's payout-tracking table holds the commissioner accountable to themselves on this.
Common questions
What happens if an entrant pays the wrong amount?›
The platform records the entry fee at the pool level, not at the entry level — every entry owes the same amount. If an entrant pays less than the entry fee, the commissioner has two reasonable responses: ask for the difference and keep the row unpaid until it arrives, or mark the row waived and let the partial payment stand as a comp. The second path is friendlier for very small shortfalls (five cents off because of a payment-app rounding quirk); the first is the right call for meaningful shortfalls. The platform does not enforce either response — the commissioner picks.
An entrant insists they paid but I cannot find the transaction. How do I resolve it?›
Three checks: confirm the payment-app handle the entrant used matches what the pool page shows (some users copy a stale handle from a previous pool); confirm the payment app's transaction list goes back far enough to show the date the entrant claims (some apps default to a short window); confirm the payment did not get sent to a similarly-named handle that does not belong to you (this happens with very common payment-app handles). If all three checks confirm the payment never arrived, the row stays unpaid and the commissioner has the polite conversation with the entrant about resending.
For where free vs paid sits in the broader picture, read Free vs Paid Pools. For edge cases that involve payments — disputed payouts, cancelled tournaments — read Handling Disputes and Edge Cases. For the host workflow as a whole, read The Commissioner Guide.