Webhook Testing Guide
Purpose
This page explains the coupon test scenarios you can use when running the Activation SDK in test/debug mode.
Each seeded test offer simulates one coupon validation outcome. This lets you verify your app behavior and webhook handling without waiting for real provider timelines.
We provide a set of test-only coupon offers that simulate the main reward validation outcomes your app may receive in production. Each test offer maps to one scenario — such as accepted, rejected, extended pending, timeout auto-accept, or a late provider callback. Contact your Actual account team for a test receipt images for this test.
When your app runs in test/debug mode and scans the matching test receipt, the system sends the same style of RewardUpdate webhook events your integration should handle in production, but with compressed timing so QA can complete each test in a few minutes.
Important Notes
- These offers are only for test/debug mode. Normal production users should not see or qualify for these offers.
- Timing is compressed for QA.
- The default delay is about 1 minute per scenario step.
- A two-step scenario usually completes in about 2 minutes.
- The initial scan creates a pending promo reward.
- The scenario then sends the follow-up
pending,accepted,rejected, or audit-only update.
How To Run A Scenario
- Enable debug mode in the SDK, and ensure you are running either a whitelisted non-prod bundle ID, or that your app user is whitelisted as a test user (both require you to notify us in advance so we can make the changes in our backend).
- Open the offer wall and choose one of the test offers listed below.
- Scan the matching test receipt from the test receipt set.
- Confirm that receipt summary screen shows a qualification for that offer.
- Watch the client webhook endpoint for
RewardUpdateevents. - Compare the received status sequence with the expected scenario.
Timing Reference
| Event | Timing |
|---|---|
| Initial scan response | Reward is created in pending state when the receipt qualifies |
| First simulated provider update | ~1 minute after scan |
| Second simulated provider update (if applicable) | ~2 minutes after scan |
Exact timing can vary slightly depending on queueing and environment load.
Scenarios
Scenario 1: Happy Path
What this tests: Provider accepts the reward normally.
Expected sequence: pending → accepted after ~1 minute
Client expectation: Client should show the reward as completed or earned.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Astepro® Allergy | 41100589903 |
| Biotrue® | 310119035887, 310119039984, 310119039977, 310119035863 |
| Ocean Spray® Pure Juice | 31200020857 |
Scenario 2: Rejected Path
What this tests: Provider rejects the reward.
Expected sequence: pending → rejected after ~1 minute
Reject reason: REJECTED_QUALITY
Client expectation: Client should show the reward as rejected or not earned.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Nexium | 305732450421, 305732452425 |
| Mrs. Meyer's | 808124125094 |
| ARM & HAMMER® Deep Clean Laundry Detergent | 33200942276, 33200942269 |
Scenario 3: 24h Timeout Auto-Accept
What this tests: Provider does not respond before the timeout, so the system auto-accepts the reward.
Expected sequence: pending → accepted after ~1 minute
Accept reason: AUTO_ACCEPTED_24H
Client expectation: Client should treat the reward as accepted.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Nature's Bounty® | 074312011269, 074312020995, 74312009716, 74312590948 |
| Biotrue | 310119035887, 310119039984, 310119039977, 310119035863 |
| Dial® Body Wash and Bar Soap | 17000348896 |
Scenario 4: Extended Pending → Accepted
What this tests: Provider sends an extended pending state, then later accepts.
Expected sequence:
pending→pendingafter ~1 minute (reason:PENDING_MANUAL_REVIEW)pending→acceptedafter ~2 minutes
Client expectation: Client should keep the reward pending during review, then show it as complete.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Chobani® | 894700010984, 818290012814, 818290012845, 818290019707, 818290019714, 818290019721, 894700010144, 894700010434, 818290011817, 818290016935, 818290017048, 818290015488, 818290016928, 818290015075, 818290017963, 818290012357, 818290015082 |
| FIFA Degree Advanced and Whole Body Deodorant | 79400267009 |
| TruSkin @ Drug Stores | 850001641975, 850001641982, 850001641302, 850001641999 |
Scenario 5: Extended Pending → Rejected
What this tests: Provider sends an extended pending state, then later rejects.
Expected sequence:
pending→pendingafter ~1 minute (reason:PENDING_MANUAL_REVIEW)pending→rejectedafter ~2 minutes (reason:REJECTED_QUALITY)
Client expectation: Client should keep the reward pending during review, then show it as rejected.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Chobani® | 894700010984, 818290012814, 818290012845, 818290019707, 818290019714, 818290019721, 894700010144, 894700010434, 818290011817, 818290016935, 818290017048, 818290015488, 818290016928, 818290015075, 818290017963, 818290012357, 818290015082 |
| Ocean Spray® Zero Sugar - 6pks & 3L | 31200013835 |
| TruSkin @ Select Grocery Stores | 850001641975, 850001641982, 850001641302, 850001641999 |
Scenario 6: Extended Pending Timeout Auto-Accept
What this tests: Provider keeps the reward pending too long, so the system auto-accepts it.
Expected sequence:
pending→pendingafter ~1 minute (reason:PENDING_HOLD_PERIOD)pending→acceptedafter ~2 minutes (reason:AUTO_ACCEPTED_EXTENDED_PENDING)
Client expectation: Client should keep the reward pending first, then show it as complete.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Aleve® | 25866591998 |
| TruSkin @ Walmart | 850001641975, 850001641982, 850001641302, 850001641999, 850001641678 |
Scenario 7: Late Provider Callback
What this tests: The system auto-accepts the reward first, then a late provider rejection arrives afterward.
Expected sequence:
pending→acceptedafter ~1 minute (reason:AUTO_ACCEPTED_24H)- A simulated late rejected callback is received after ~2 minutes — audit-only, does not change the final reward state (reason:
REJECTED_AFTER_AUTO_ACCEPT)
Client expectation: Client should keep the reward accepted. A late provider callback should not reverse the reward.
Test offers:
| Product | Qualifying UPCs |
|---|---|
| Aleve® or AleveX™ | 25866591578, 25866592247, 25866592261 |
Merchant Promotions
Merchant promotions qualify at the retailer level rather than at the individual product level. Unlike the PVP coupon scenarios above, there is no specific UPC or product to match — any receipt from a qualifying retailer qualifies the promotion.
What's different in the webhook:
qualified_promos[n].productsis always an empty array ([]), even whenstatusispendingoraccepted. This is expected — do not treat it as an error.- All other
RewardUpdatefields behave identically to standard promo rewards.
Test offers are available for the following retailers in test/debug mode:
| Retailer |
|---|
| Walmart |
| Target |
| CVS |
| Publix |
| Kroger |
How to test:
- Enable debug mode in the SDK and ensure your bundle ID or user is whitelisted as described in How To Run A Scenario.
- Open the offer wall and clip one of the merchant promotion offers for a qualifying retailer.
- Scan a receipt from that retailer with a total of $10.00 or more — merchant promotions require a minimum spend of $10 to qualify.
- Confirm the receipt summary screen shows a qualification for the merchant promotion.
- Watch your webhook endpoint for a
RewardUpdatewithreward_type: "promo". - Verify that
qualified_promos[n].productsis an empty array ([]) in the payload.
Expected webhook sequence: pending → accepted after ~1 minute (same timing as Scenario 1).
Contact your Actual account team for the current test offer names and a matching test receipt image for each retailer.
What to Verify When Testing
- Did the offer appear only in test/debug mode?
- Did the scan qualify for the selected offer?
- Did you receive the expected
RewardUpdateevents? - Did the app display the correct reward state after each update?
- Did the app keep the reward as accepted in the late callback scenario (Scenario 7)?
- Does the app have enough logging to support users asking why a reward is
pending,accepted, orrejected?
Known Caveats
- These flows are for test/debug mode only.
- Timing is approximate and can vary slightly by environment.
- The exact receipt-to-offer mapping should be taken from the test receipt spreadsheet/document.
- The late callback scenario (Scenario 7) is intentionally audit-only after auto-accept. Clients should not expect a second client-facing rejection update that reverses the accepted reward.