Youth Sports Payment Reconciliation and Refund Recovery Playbook

A daily and period-close operating playbook for reconciling registration intents, provider transactions, internal ledger entries, refunds, disputes, settlements,...

trigger="The platform accepts registration payments, issues refunds or credits, manages organization balances or payouts, handles disputes, or has unresolved differences between product records, provider evidence, and finance reporting." owner="One finance control owner accountable for the approved funds model and one senior engineering owner accountable for transaction, ledger, and reconciliation integrity." timebox="Daily transaction and exception controls, provider-aligned settlement controls, and a formal period close. The first implementation should establish the model and complete one reconciled period within four weeks." participants={["Finance", "Payment engineering", "Product", "Registration owner", "Support", "Organization operations", "Security", "Accounting or reporting owner", "Payment provider contact"]} prerequisites={[ "Merchant, funds destination, platform fee, provider fee, refund, dispute, negative-balance, payout, currency, and accounting responsibilities are documented.", "The team can access internal intents, attempts, registrations, ledger or balance records, provider transactions, webhooks, refunds, disputes, settlements, payouts, and bank or accounting evidence where applicable.", "Every production payment object can be mapped to an organization and commercial intent or placed in a controlled unknown-object queue." ]} outputs={[ "A transaction, settlement, and organization-balance reconciliation specification.", "A daily control report with coverage, totals, exceptions, age, and job version.", "A refund and dispute recovery workflow with permissions and evidence.", "A controlled exception queue and correcting-entry process.", "A period-close pack reconciled to provider and finance sources." ]} doneWhen={[ "Every relevant provider transaction maps to one internal intent and organization or an owned exception.", "Internal charges, refunds, disputes, fees, settlements, and organization balances reconcile by currency and period.", "Unknown and uncertain states have category, amount, owner, age, permitted action, and response objective.", "Manual corrections create approved immutable evidence rather than editing history.", "Finance and engineering sign the same period-close control pack." ]} />

Establish the funds-responsibility model first

Before running reconciliation, confirm who sells the programme, who is merchant of record, where funds settle, how the platform fee is calculated, who absorbs provider fees, who approves refunds, who owns disputes, how negative balances are handled, and which records are official accounting evidence.

Engineering cannot resolve an ambiguous commercial or legal responsibility by selecting an API mode. Finance cannot reconcile organization balances when product events do not preserve price, fee, and adjustment components.

Create a signed matrix by organization or commercial model. Version it and state effective dates. A change applies prospectively unless an approved transition says otherwise. Link provider account identifiers and internal organization identifiers through a controlled mapping.

Stop the process when funds responsibility or account ownership is unknown. A complete spreadsheet built on the wrong merchant model is not a control.

Define the three reconciliation loops

Transaction reconciliation compares internal commercial intents and attempts with provider charges, refunds, disputes, and reversals. It answers whether each customer action has one explainable financial outcome.

Settlement reconciliation compares internal clearing and payable balances with provider balance transactions, fees, reserves, currency conversion, and payouts. It answers whether money moved to the expected financial destination.

Organization reconciliation explains gross collections, discounts or credits, refunds, disputes, fees, transfers, prior balance, payout, and closing balance for one organization. It answers what the organization should see and why.

Do not combine these into one pass. A charge can be correct while settlement is pending. A payout can reconcile while one registration has an unresolved product state.

Build the canonical identifier map

For every commercial intent store organization, household or account reference, participant where needed, programme, price snapshot, currency, amount, idempotency key, inventory reference, provider customer, provider intent, provider charge, refund, dispute, balance transaction, settlement or payout, and internal ledger event references.

Provider identifiers are evidence, not primary keys for the product. One intent may have several attempts but cannot produce several successful charges without an explicit approved case. Reject reuse of an idempotency key with different content.

Build an unknown-object queue for provider objects that do not map. Record account, object, amount, currency, time, source, suspected organization, risk, and owner. Never discard an object because it is not recognized.

Create immutable financial events

Use append-only charges, fees, credits, refunds, disputes, adjustments, transfers, and settlements. A correction creates a new entry linked to the entry it corrects. Do not modify historical amount or organization to make a report balance.

Each entry includes effective and recorded time, organization, currency, intent, provider object, event type, account or balance, amount, source, actor or service, reason, and correlation. Enforce balanced entries or another approved mathematical invariant.

Keep currencies separate. Do not sum USD and another currency into one difference. Record conversion and settlement evidence explicitly.

Restrict manual journals. Require reason, supporting evidence, permitted accounts, approver, threshold, and post-entry reconciliation. Large corrections should use dual review.

Implement the daily transaction control

Select a provider window with overlap to catch late events. Page through every relevant object and record the provider account, API version, cursor, start and end, request count, and completion. A job that silently skipped a page cannot report success.

Compare:

internal provider reference exists and matches amount and currency;
provider charge maps to one intent and organization;
successful provider charge has paid or owned-exception internal state;
refund, dispute, and reversal appears internally exactly once;
internal paid state has provider evidence;
uncertain state age remains within the objective;
duplicate mappings and unknown objects are zero or owned.

Classify differences by type. Missing internal, missing provider, amount mismatch, currency mismatch, state lag, duplicate mapping, unknown object, stale uncertainty, and webhook gap need different recovery.

Verify webhook coverage separately

Reconciliation should not assume webhooks are complete. Compare provider objects and event history with accepted webhook receipts. Verify signature result, provider event identifier, target object, receipt time, application time, transition, and error.

Stripe publishes webhook signature guidance. Preserve the raw request for verification and avoid logging secrets or unnecessary payment data. Other providers have different event contracts.

Test duplicate and out-of-order delivery. A duplicate is acknowledged without another financial effect. An event for an impossible transition enters the exception queue. Unknown objects remain visible.

Track provider event lag and oldest unapplied accepted event. A responsive endpoint is not evidence that downstream application succeeded.

Reconcile paid registration integrity

For every successful charge, verify registration, inventory, price snapshot, financial event, organization, and confirmation. For every active paid registration, verify the expected provider and ledger evidence.

Classify paid-without-registration, registration-without-payment, amount mismatch, duplicate registration, released inventory after paid intent, and confirmation-only failure. Product and finance owners approve recovery rules.

Repair from durable intent and provider evidence. Do not charge again. When inventory cannot be honored, create an owned customer recovery case and approved refund path. Preserve the original failure.

During registration peaks, run this control more frequently and prioritize stale uncertainty by amount and customer impact.

Operate refunds as a state machine

A refund request records original intent, organization, components, requested amount, remaining refundable balance, reason, policy, requester, approver, and inventory or cancellation relationship. Calculate from the historical price snapshot.

States include requested, approved, submitted, provider pending, succeeded, failed, cancelled, and reviewed. Stripe notes in its refund documentation that provider balance and processing can affect timing. Model pending rather than presenting immediate finality.

Partial refunds allocate deterministically across approved components. Internal credit creates a liability and consumption trail, not a fake provider refund. A refund and roster cancellation are linked but separate decisions.

Reconcile refund amount, currency, provider object, balance transaction, internal event, organization statement, and customer communication. Alert on age and repeated failure.

Operate disputes and negative balances

Ingest each dispute with original intent, organization, amount, currency, reason, deadline, provider status, evidence, owner, and outcome. Alert before the response deadline and restrict evidence to the relevant participant and transaction.

Move value into the approved dispute or reserve account. Apply organization or platform responsibility transparently. Do not silently reduce an organization payout without an explanation tied to the case.

Model negative balances, reserve, payout hold, recovery, and write-off explicitly. Define who can release a hold. A bank-account change near a payout or unusual refund volume requires enhanced review.

Reconcile final dispute outcome back to ledger, provider settlement, organization statement, and customer case.

Reconcile settlements and payouts

Import provider balance transactions and payout manifests. Map charges, refunds, disputes, fees, reserves, conversions, and adjustments. Reconcile the manifest total to the provider payout and internal clearing balance by currency.

Link the payout to bank or accounting evidence where the approved process supports it. Record timing differences separately from unexplained differences.

For connected or split-payment models, verify destination account and transfer relationship. An internal organization identifier is not proof that money reached the intended provider account.

Do not close the period while a material payout difference is unowned. Keep provider-estimated and final settlement states distinct.

Produce the organization statement

Build each line from immutable financial events. Show gross collection, discounts or credits, refunds, disputes, platform and provider fees according to policy, transfers, prior balance, payout, and closing balance. State period, timezone, currency, and version.

Every line drills to controlled evidence. Preserve issued statement versions so later corrections can be explained. Do not regenerate history from current programme configuration.

Review a sample with organization finance owners. Confirm terminology and fee responsibility. A technically balanced statement can still be misleading if labels do not match the approved model.

Record delivery and access. Statements may contain household and transaction information and need scoped, expiring access.

Operate the exception queue

Every exception has category, amount, currency, organization, intent, provider objects, age, risk, evidence, owner, response objective, and next permitted action. Sort by financial and customer consequence as well as age.

Automate deterministic resolutions. A human action uses a product operation that previews effect and creates an immutable event. Do not resolve by editing rows or deleting provider events.

Close only when independent evidence agrees or an approved adjustment, write-off, or correction explains the difference. Preserve detection and resolution.

Review aged and repeated categories weekly. A growing queue is an operating signal and may justify stopping a feature or provider rollout.

Recover after outage or data restore

Restore into an isolated environment without production payment or messaging credentials. Select the provider and internal windows around the recovery point. Rebuild identifier mappings, webhook receipts, intents, registrations, and financial events.

Reapply provider evidence idempotently. Never replay historical charge commands. Distinguish facts from commands and external effects.

Run transaction, registration, refund, dispute, settlement, and organization-balance reconciliation. Check duplicate provider objects and outbound messages. Test access and privacy before reopening.

The finance owner and engineering owner sign the recovery pack and rollback point. Keep production actions frozen until acceptance passes.

Close the financial period

The period pack includes scope, provider accounts, currencies, API and report versions, window, coverage, object counts, totals, internal balances, provider settlements, bank or accounting evidence, organization statement totals, exceptions by category and age, manual entries, refunds, disputes, and approvals.

Reconcile subtotals to source totals. Explain timing, reserve, and conversion differences. Do not net unrelated categories into one small variance.

Freeze the report version and queries. Later corrections create a new version with reason and impact. Finance validates accounting treatment; engineering validates system integrity and coverage.

Store the pack with controlled access and retention. It should be reproducible by another authorized reviewer.

Use one daily control report format

Create the daily report from the reconciliation job and exception system rather than assembling it manually. The header states business date, timezone, provider accounts, currencies, organization scope, job and code version, provider API or report version, start and end cursor, pages retrieved, and completion time. A reviewer should be able to tell whether the job covered the intended population before reading the totals.

For each currency show opening unresolved items, new intents, provider successes, declines, uncertain outcomes, registrations committed, refunds requested and completed, disputes opened and closed, settlement movements, unknown objects, manual entries, and closing exceptions. Report counts and amounts separately. Never combine currencies into a platform total without an explicit conversion view.

The report lists exceptions by category, materiality, organization, owner, age, and response objective. It highlights changes from the prior report and items that crossed an escalation threshold. A zero-exception result still includes coverage and reconciliation totals so the reviewer can distinguish a clean day from a job that processed nothing.

Finance reviews money and responsibility. Engineering reviews technical coverage, state transitions, idempotency, and job health. The reviewers record acceptance or questions. Corrections produce a new report version with a link to the original, not an overwritten file.

Retain the report according to the approved financial and security policy. Restrict household and participant detail to drill-down cases. The routine report should use organization, intent, and provider references sufficient for authorized investigation without becoming a broad personal-data export.

Security and fraud controls

Tokenize card data through the provider and minimize payment data handled by the platform. Use the current PCI SSC document library with qualified compliance owners to determine applicable requirements.

Separate view, refund, dispute, payout, bank-change, journal, reconciliation, and break-glass permissions. Require step-up authentication, reason, and dual review above thresholds.

Alert on unusual refunds, bank changes, provider account mapping, credential use, unknown objects, duplicate idempotency, manual entries, negative balances, and exports. Protect provider secrets and rotate by environment.

Financial audit does not justify exposing participant or guardian data broadly. Use opaque references and scoped case access.

Operational and security consequences

Finance and engineering operate one control, not parallel spreadsheets. Finance owns the funds model, thresholds, period approval, and accounting interpretation. Engineering owns intent, event, ledger, job coverage, idempotency, recovery, and technical evidence. Support and operations use approved case actions.

Security controls must remain usable during incidents. Provide safe refund, correction, hold, and reconciliation operations so teams do not seek database access. Break-glass remains logged and reviewed.

Monitor both counts and amount by currency. Ten small mismatches and one large mismatch are different risks. Track oldest uncertainty and exception, not only queue size.

Any material financial-integrity or credential incident can stop new payment actions while existing evidence is reconciled. Define the stop authority in advance.

Failure modes and stop conditions

Stop or restrict payment actions when provider account mapping is uncertain, idempotency is broken, duplicate charges occur, ledger invariants fail, reconciliation coverage is incomplete, bank details changed without verification, or material unknown objects have no owner.

Do not retry a timed-out charge blindly, mark pending refund as complete, delete an unmatched object, edit a historical amount, combine currencies, or close a period from webhook counts alone.

If the reconciliation job fails partway, retain cursor and coverage, rerun idempotently, and mark the control incomplete. If provider data changes after initial reporting, update through a versioned close process.

Rollback code or configuration through the tested release path, then reconcile every external effect created during the affected window.

Acceptance checklist

"Merchant, funds, fee, refund, dispute, negative-balance, payout, currency, and accounting responsibilities are approved.", "Every provider account and object maps to an internal organization and intent or an owned exception.", "Financial events are immutable, currency-safe, attributable, and mathematically validated.", "Daily transaction control records provider coverage, pagination, totals, job version, and exceptions.", "Webhook receipt and application are reconciled separately from provider truth.", "Paid registrations, inventory, price snapshots, charges, and ledger entries agree.", "Refund, credit, instalment, dispute, reserve, and negative-balance workflows have explicit states and owners.", "Settlement and payout manifests reconcile to clearing balances and finance evidence.", "Organization statements derive from immutable events and preserve issued versions.", "Exception actions preview effect, require reason, and create correcting evidence.", "Recovery blocks external effects and reconciles before reopen.", "Finance and engineering sign one reproducible period-close pack." ]} />

Primary references

Final handoff

Store the funds model, identifier map, ledger event catalogue, reconciliation specifications, daily reports, exception register, refund and dispute cases, settlement manifests, organization statements, recovery tests, and signed period packs together.

The control is complete when every movement can be explained from customer intent through provider and internal evidence to organization balance. A matching total alone is insufficient when the path, coverage, or owner is unknown.