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.