Should Redemption Code be used as the recovery record for failed reward fulfillment?

[jongdae.won]

Hi brainCloud team,

We are considering using shared / multi-use Redemption Codes for operational rewards.

The main issue is not code distribution itself, but recovery when reward fulfillment fails.

Our desired flow is:

User redeems shared Redemption Code
→ reward fulfillment is attempted
→ if reward fulfillment succeeds, user should not receive it again
→ if reward fulfillment fails, we need a way to retry or recover
We would like to know whether Redemption Code is intended to be used as the source of truth for this kind of reward claim / recovery state.

Questions:

For a shared / multi-use Redemption Code, if a specific user already redeemed the code, can that user’s redeemed state be reset or deleted through any supported API or operator flow?

If reward fulfillment fails after redemption, is there a BrainCloud-side retry or recovery mechanism that allows the same user to receive the reward later?

Can customRedemptionInfo or fulfillment status be updated and used as a persistent per-user record of reward fulfillment success / failure?

If the only reset method is marking a user as a tester and deleting the redeemed record manually in the portal, is that intended only for testing and not for production operations?

For production operational rewards, would BrainCloud recommend:

shared Redemption Code + Fulfillment Script retry,
single-use personal codes per user,
a Custom Entity / external claim ledger,
or another pattern?
Our concern is this case:

RedeemCode succeeds
→ reward fulfillment fails
→ the user cannot redeem the same shared code again
→ we need an auditable retry/recovery path
We want to understand whether Redemption Code can own this recovery state, or whether we should manage claim status separately outside of Redemption Code.

Thanks.

[JasonL]

For a shared/multi-use Redemption Code, a specific user’s redeemed record can only be reset or deleted through the tester-only deleteRedemptionForTester() flow, so there is no supported production operator/API path for non-tester accounts, and the tester reset should be treated as a QA/dev tool rather than a live recovery mechanism.

If reward fulfillment fails after redemption, it does not provide an automatic recovery or re-execution path that restores the same user’s redemption state in production; synchronous failures record a failed attempt, async flows can end in Failed on timeout, and any retry is only possible if the code type’s maxRetries still allows another user-initiated redeemCode() attempt.

customRedemptionInfo can be used as a persistent per-user audit field if your fulfillment script writes it back, since it stores the script response on the user’s code record. However, it is not designed to be updated later through a direct external API after the fact.

The tester reset is explicitly intended for testing/cleanup only, not as a production recovery operation.

For production operational rewards, the safest pattern is a shared Redemption Code for claim detection, plus a separate Custom Entity for the fulfillment state, which provides auditable handling of pending/fulfilled/failed/retrying without relying on the Redemption Code record as the source of truth.