Sandbox testing: login requirements, promo-code reset, and moving a setup to production

This article explains how sandbox testing works for Player ID login, how to retest promo-code redemption, and what must be recreated manually when moving a tested setup to production.

Sandbox login with Player ID

If a user cannot log in to the sandbox using a game Player ID, first verify that the player exists in the test/QA environment. Sandbox verification may point to the QA/test server rather than production data, so a production-only player may return a "player does not exist" error.

• Use a test build of the game.
• Log into the game on the test build first so the player is created in the test environment.
• Then retry Player ID login in the sandbox.

Retesting promo-code redemption in sandbox

If a promo code was already activated in sandbox and needs to be tested again, the activation can be removed/reset for that user. Creating a brand-new user is not always required.

When requesting the reset, provide the relevant player identifier used by the team for the sandbox cleanup.

Moving a tested setup from sandbox to production

After validating the flow in sandbox, some parts can be reused and some must be recreated manually.

• Attributes: create them manually in production.
• Campaigns: the campaign can be transferred, but verify afterwards that the expected attribute mapping/value is still correct.
• Redeem codes: create them manually in production.

Recommended rollout checklist

1. Validate the full flow in sandbox using a user created in the test build.
2. If needed, reset the sandbox redemption state for retesting.
3. Transfer the campaign to production.
4. Recreate required attributes manually in production.
5. Recreate redeem codes manually in production.
6. Run a final check to confirm the production campaign still uses the correct attributes.