# QuestX event-validation sample

Status: offline engineering example. QuestX publishes this about its own integration. No participant, real campaign, payment, eligible activity or redemption was tested. The fixture values are neutral example points, not money or a conversion rate.

## Reproduce

Download adgem-postback.ts, verify.mjs and fixtures.json into one directory. Use Node.js 25.6.1 and run `node --experimental-strip-types verify.mjs`. No dependencies, network calls, accounts or production credentials are used. The hard-coded secret is public test data and must never be used for a live integration.

Signature code is copied without alteration from quests-economy commit 946eab6d, apps/api/src/modules/offerwall/networks/adgem-postback.ts. SHA-256: 3741dab47340ad39aaff3322b16ba4dc3f3e1cae526600ab4203061654ec0c68. The runner verifies the hash, a valid HMAC, tampered amount, missing signature and wrong key.

## What the other fixtures mean

The local replay checks seven explicitly synthetic records: pending, failed, credit, duplicate credit, reversal, duplicate reversal, unmatched reversal. It models an audit expectation, **not the production points ledger**. An unmatched reversal stays unresolved rather than silently counting as a new success. Pending and failure records do not increase the fixture balance. Duplicate records have zero balance effect. A reversal returns the example balance to zero.

## Mapping to supported production code

`OfferwallAggregatorService.handlePostback` validates provider signatures, calculates configured points, validates UUID identity and deduplicates using provider transaction/source IDs with ledger evidence. It returns credited/points/reason, including invalid_signature, unknown_provider, zero_points, non_uuid_user and duplicate. A duplicate acknowledgement is not another successful activity. Pending is a reporting state in this example, not a claimed return value of handlePostback.

`handlePubscaleChargeback` is a separate provider-specific reversal path with IP/signature checks and a points-ledger debit. AdGem signature validation does not establish PubScale reversal safety. This sample does not test restart persistence, database concurrency, real signature delivery, fraud decisions, cross-provider IDs, reversal ownership or actual settlement. Verify those on an authorized staging installation before a campaign. Do not call live callback endpoints with these fixtures.

## Consumer eligibility and redemption evidence to collect

Record the actual campaign and version, jurisdiction, age/account/device requirements, allowed activity, start/end times with timezone, attribution prerequisites, completion/approval window, point terms, available reward methods, minimums/fees, expiry and reversal conditions as shown to the member. Preserve a permissioned terms snapshot. Do not infer eligibility from signing up or seeing an offer.

Record consented participant scope, test timestamps, expected outcome, actual activity confirmation, pending/failed/reversed states, ledger reference and redemption result. Redact private user IDs and payment details. No real journey is available for this publication: eligibility, credited points, redemption and final settlement remain unverified.

## Keep acquisition cohorts separate

Consumer: signup received → terms checked → eligible confirmed activity → approved ledger credit → requested redemption → confirmed settlement. Business: partner inquiry received → feasibility/permission/budget review → qualified inquiry → approved integration. An outbound click, signed fixture or accepted form is not real activation, qualified demand or settled reward.