Thank you for the responses. I'd like to clarify my situation and ask more specific follow-up questions.

My current setup:

Product default price: Standard price (normally available for purchase) Promotion price override: Not for Sale (priceId: -2) Reason: The console requires the promotion price to differ from the default price, so this is used as a workaround to pass validation Actual purchase price: Provided directly by Apple App Store / Google Play
In other words, I'm using promotions not to change the price, but to control access for specific user segments and track purchase counts. Question 1: Is using "Not for Sale" as a promotion price override a supported pattern?

With the setup described above — where the promotion price override is set to Not for Sale (priceId: -2) — does BrainCloud's purchase counter and maxPurchases limit work correctly? Is this a supported use case?

Question 2: How exactly should promotionId be passed during purchase?

JasonL mentioned:

"As long as that payload contains the promotionId you received from GetEligiblePromotions, the promotion will be correctly attributed and the server-side flow will reach the counter increment logic."

However, in a standard IAP flow:

Call GetEligiblePromotions → receive promotionId User completes payment on Apple App Store / Google Play → store returns a receipt (binary/base64 data generated by Apple/Google) Call AppStoreVerifyPurchase (or equivalent) with that receipt
The receipt from step 2 is generated by Apple/Google — I cannot inject custom fields like promotionId into it.

So my question is: in which parameter and in what format should promotionId be passed in the verifyPurchase call? A concrete example of the API call with promotionId correctly included would be extremely helpful.

Summary: Question Is setting the promotion price override to Not for Sale (priceId: -2) a supported pattern, and will the purchase counter work correctly? In the verifyPurchase API call, which parameter carries the promotionId, and in what format?

It's been resolved. Thank you for your response!

Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.