> For the complete documentation index, see [llms.txt](https://help.openloyalty.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.openloyalty.io/implementation-guide/data-and-go-live/testing-and-uat.md).

# Testing & UAT

Testing an Open Loyalty implementation end to end — test data, functional and failure scenarios, webhooks, performance and user acceptance — before go-live.

Each module checklist in this guide ends with validation scenarios. This page turns them into a test plan and adds what cuts across modules: test data, failure and retry tests, webhooks, performance, and business sign-off.

## Environments and test data

* Test on **staging**. It has lower throughput and no SLA, and shouldn't hold real personal data — see [Environments & access](/implementation-guide/plan-and-foundations/environments-and-access.md).
* Create **test members** with a recognisable identifier range and domain (e.g. loyalty card numbers `9990000001…`, emails at a domain you own). Give them the profiles your scenarios need: birthdays today, members in each tier, members in each segment, migrated and new members.
* For data migration, rehearse with an **anonymised** copy of production data — see [Data migration](/implementation-guide/data-and-go-live/data-migration.md).
* Keep a list of the test members and what each one is for; reset or recreate them between test rounds.

## Functional scenarios

Start from the **Validation** list on each module checklist you're implementing, and turn each line into a test case with inputs and the expected result:

| Area                                                    | Validation lists                                                                                                                                                                                                                                                                                                                                                                                                    |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Members, transactions, custom events, wallets, webhooks | [Members & profile](/implementation-guide/module-checklists/members-and-profile.md), [Transactions](/implementation-guide/module-checklists/transactions.md), [Custom events](/implementation-guide/module-checklists/custom-events.md), [Wallets & points](/implementation-guide/module-checklists/wallets-and-points.md), [Webhooks & CRM sync](/implementation-guide/module-checklists/webhooks-and-crm-sync.md) |
| Engagement                                              | [Campaigns](/implementation-guide/module-checklists/campaigns.md), [Challenges & missions](/implementation-guide/module-checklists/challenges-and-missions.md), [Referrals](/implementation-guide/module-checklists/referrals.md), [Badges](/implementation-guide/module-checklists/badges.md), [Tiers](/implementation-guide/module-checklists/tiers.md)                                                           |
| Rewards and gamification                                | [Rewards & coupons](/implementation-guide/module-checklists/rewards-and-coupons.md), [Fortune wheels & lotteries](/implementation-guide/module-checklists/fortune-wheels-and-lotteries.md), [Leaderboards](/implementation-guide/module-checklists/leaderboards.md), [Segments](/implementation-guide/module-checklists/segments.md)                                                                                |

Before sending test traffic for a campaign, check its outcome with [campaign simulation](https://help.openloyalty.io/campaigns/campaigns/campaign-simulation). Time-based rules (birthdays, anniversaries, monthly leaderboard prizes, expiry) need test members whose dates fall inside the test window — plan them in advance.

## Failure and retry scenarios

These catch the bugs that only show up in production traffic:

| Scenario                                                   | Expected result                                                                                             |
| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| The same transaction is sent twice (retry after a timeout) | Recorded once; the second gets the duplicate document number `400`, which the integration treats as success |
| The same custom event is sent twice                        | Processed once; duplicate `eventId` `400` handled as already processed                                      |
| A balance adjustment is retried                            | Added once; duplicate `externalTransferId` rejected                                                         |
| Open Loyalty returns `429` or `5xx`                        | The integration retries with backoff and logs the payload                                                   |
| A `400` validation error                                   | Not retried; logged with the payload for fixing                                                             |
| A profile update made in the channel                       | No update loop between channel, Open Loyalty and CRM                                                        |
| A webhook endpoint is down for an hour                     | Missed events are recovered by reconciliation                                                               |
| A fortune wheel draw fails                                 | Retried on the same spin; no second spin bought                                                             |

## Webhooks

* Subscribe staging webhooks to a staging endpoint and run every member journey: check each expected event arrives once, with a valid signature, and updates CRM.
* Send a request with a wrong signature and confirm it's rejected.

## Performance

* Staging isn't sized for load tests. If your launch or campaigns will produce peaks — a promotion, a migration, a push notification to all members — estimate requests per second and request a performance test and, if needed, a limits increase from Open Loyalty support in advance.
* Load-test your own integration layer and webhook endpoint too; they're usually the bottleneck.

## User acceptance

* Business owners run the member journeys on staging through the real channels — join, earn, see the balance, redeem, receive messages — and confirm the experience and the numbers.
* Marketing confirms every campaign, reward and message against the agreed rules.
* Record sign-off per journey, and list anything accepted as a known issue or moved after go-live.

## Checklist

* [ ] Test members exist for every scenario, including date-based ones.
* [ ] Every module's validation list has been turned into test cases and passed.
* [ ] Failure and retry scenarios have passed.
* [ ] Webhooks have been tested end to end, including a wrong signature.
* [ ] Expected peaks are covered by a performance test or a limits increase.
* [ ] The data migration has been rehearsed and reconciled.
* [ ] Business sign-off is recorded per journey.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.openloyalty.io/implementation-guide/data-and-go-live/testing-and-uat.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.