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.

[jongdae.won]

Hi brainCloud team,

Thank you for the detailed explanation.

Based on your answer, I understand that Redemption Code should not be treated as the source of truth for production reward fulfillment / recovery state, especially for shared or multi-use codes.

For our current implementation, we are handling it like this:

• Redemption Code is used for campaign validity, shared-code redemption, and reward metadata.
• The Redemption Code custom metadata contains only a rewardDataId / rewardId.
• The actual reward content is resolved on our server from our RewardData.
• Reward fulfillment is executed by our server reward pipeline.
• Separately, we store a per-user claim state in a BrainCloud User Entity / Custom Entity.
• That claim state records statuses such as Redeeming, Redeemed, Granting, Granted, RedeemFailed, and GrantFailed.
• If redemption succeeds but reward fulfillment fails, we keep the claim state as Redeemed or GrantFailed and allow our server to retry the fulfillment step without requiring the user to redeem the shared code again.
• If the claim state is Granted, we block duplicate reward grants.

So in our design:

• Redemption Code owns code validity and whether the user has consumed the shared code.
• Our separate claim entity owns fulfillment state, retry state, and audit/recovery information.
• Redemption Code redeemed records are not used as the production recovery source of truth.

Does this align with the pattern you recommended?

Also, as a follow-up, we are currently calling BrainCloud from our server for multiple steps: claim state update, redemption, reward grant, and final claim update. We may consolidate the BrainCloud-side claim/redemption operations into a CloudCode script to reduce API round trips, while still keeping reward fulfillment in our server pipeline.

Would that be a reasonable approach?

Thanks again.