Percents exposes enough identifiers and summaries to reconcile issuer state with Percents processing.
Start from the Percents auth_ or txn_ id, then use the audit chain to answer three questions:
- Did Percents receive and process the transaction?
- Which branded balance or cashback effects were created, posted, reversed, expired, or spent?
- Which webhook deliveries correspond to the effect?
| Endpoint | Use |
|---|---|
GET /api/v2/chg/{chgId}/rewards/summary | Compare aggregate branded balance and cashback totals. |
GET /api/v2/chg/{chgId}/rewards/activity | Review cardholder-visible activity rows. |
GET /api/v2/chg/{chgId}/rewards/expiring | Identify branded balance that is nearing expiry. |
GET /api/v2/chg/{chgId}/merchant/{merchantId}/balance | Reconcile a merchant-scoped branded balance. |
GET /api/v2/chg/{chgId}/transaction/{txnId}/reward-detail | Reconcile one transaction and its reward events. |
POST /api/v2/chg/{chgId}/transactions/reward-overviews | Reconcile many transactions by id. |
Webhook records have a stable webhookId and attempts are retried on the configured schedule. Issuers should store:
webhookIdtype- receive timestamp
- signature verification result
- processing status
- source ids from
data
When a webhook is replayed, the issuer should return success if the event was already processed successfully.
Percents uses a double-entry ledger to back all debt and liability changes resulting from cardholder activity, transfers, and expiration. The public API exposes the balances, reward events, and webhooks needed for issuer reconciliation.