Skip to content

Rewards Club — Reconciliation

Access prerequisites

  • Permission (module): viewRewardsAudit
  • License/Feature: REWARDS_CLUB
  • Menu container: GENERAL → Rewards Club group

What it is / when to use

Operations and audit dashboard for the club. The ops team opens it when they need to understand, for a given period: how many events arrived, how many payouts were issued, how many are stuck (pending) and how many failed, as well as inspecting which events had problems and why (with an expandable payload).

Use it for periodic closing (24h/7d/30d or a custom range), to investigate pending items, and to validate the program's health after changes to missions.

Prerequisites

  • Permission: viewRewardsAudit (dual permission: CPM enum + dynamic module in the DB).
  • License/Feature: REWARDS_CLUB.
  • Dependencies on other screens: the data reflects activity generated by Missions and the Program configuration.

Step by step

  1. Go to the menu Rewards Club → Reconciliation (/rewards-club/reconciliation).
  2. Choose a period preset (24h / 7d / 30d) or enter a custom range (from/to).
  3. Read the KPIs and the success rate (paid payouts / total).
  4. In the problems list, click a row to expand the payload and see the reason (reason) and the mission involved.

Filters and columns

Filter / ColumnWhat it showsData source
Period (preset/custom)Analyzed windowPresets 24h/7d/30d or from/to dates
Events received (eventsReceived)Total captured eventsReconciliation KPIs (RCS)
Paid payouts (payoutsPaid)Settled grantsKPIs
Pending payouts (payoutsPending)Grants stuck and waitingKPIs
Failed payouts (payoutsFailed)Grants that failedKPIs
Success ratepaid / (paid+pending+failed)Calculated in the UI
Problems listEvents with pending/failed payoutgetProblemEvents(from, to)
Problem detailoutcome, reason, mission and payloadRewardsRawEvent.matchedMissions + payload

Actions and modals

  • Change period / Apply range: reloads KPIs and the problems list for the new window.
  • Expand row: shows the event JSON and the reason for non-payment.

Business rules / cautions

Attention

  • Pending and failed indicate payouts that were not completed — investigate before assuming a user was paid. Common causes: pool without balance, user not approved, anti-fraud cap reached.
  • The event status (PAID/PENDING/FAILED/PROCESSED/ERROR) is rendered as colored pills; "neutral" indicates results that do not fit the main categories.
  • Idempotency: payouts go through FinLib, which is idempotent by externalId. An event marked as error does not necessarily mean the user did not receive: when reprocessed, E00021 ("already processed") is treated as success. Therefore, re-executing/recalculating is safe and does not duplicate grants.
  • Financial values: all totals travel as BigNumber strings — no rounding.