Idea

For the sake of our backlog item, what's the intent if you pass in a bundle that has a Random Result Table as part of its definition? Is the goal to have it tell you what item it will result in, and then attach that information to the item so that when the coupon is finally redeemed, it must still be that item? Or should this return something like "?" for those items?

[Necro]

Looks like the real use case here is "have coupons that are 1x per account". This is something we'd like as well (right now, we're doing server-side validation on the coupon to make that work, but it would be way better to have that as a flag, or tag on the coupon (we have some coupons where we'd want the player to only be able to redeem one of a group of coupons, but that's less important)

Okay, I'm hearing two different things here:

1. The original post is requesting the ability to check what the coupon is for without redeeming it, so that you can decide not to use the redeem API, as the player already has the item. We are planning on adding the ability so specify that a player can only ever have N of any given item later on, but even with that, this would still be valuable, since you still may want to not "waste" the coupon.

2. The ability to have coupons be multi-use (currently, they are one-use), but limited to one use per player. Since you could technically get an item via more than just the coupon, I'd prefer to have this feature request be specific to 1. We do have a backlog item for making coupons multi-use, but please do feel free to add a separate feature request for that, if you'd like to vote on it.Thanks!

Sorry I never followed up on this --

"have coupons that are 1x per account"

^ Yesh -- this is it. For example, using coupons as game keys. I'd have to redeem the coupon in order to see that it's a duplicate of an item the player already has. On our side, we can reject it, but on PF's side, the coupon would still be consumed.

1. Correct

2. I'd also prefer #1.

Massive necro, but I have a use for this exact feature.

Our app+game actually embeds PlayFab coupons into physical QR codes that are shipped with physical vinyl figures.

I want to test the coupon redemption in a test or debug context... but I have no way of seeing what bundle the coupon in question is associated with, without actually redeeming it.

It would even be great just to have a "debug" flag in the RedeemCoupon request, where it would return the item data but not actually claim anything.

We have tens of thousands of coupon codes already, just for the beta, and there will be a lot more generated later on. We COULD store a separate, parallel table containing every generated coupon code along with its intended reward, and do logic on that table in a test environment, but honestly, that feels very silly and redundant when PlayFab is already acting as the authoritative source of coupon state and associated data.

As it stands, I'm forced to have an extremely fake alternate flow for testing, where I'm not even able to tell the user what item the passed-in code was for, and where everyone can claim the same test-coupon. In production, I can derive a lot from a combination of the response of the RedeemCoupon call and the user's own PlayFab data, but there's no good way to warn a user that they're about to waste a coupon on a redundant item... All I can really do is store the redeemed coupon somewhere and hope we can compensate them with virtual currency or something later on down the road.