Thank you for the responses. Based on the discussion, we've implemented the following:

Product default price: standard App Store price Promotion price override: "Not for Sale" (priceId: -2) — workaround to pass console validation requiring a price difference Purchase verification: server-to-server (S2S) VERIFY_PURCHASE, no explicit promotionId in the request Promotion gating: via GetEligiblePromotions() on the client

We're observing that the purchased counter increments correctly after purchase, and the promotion does not reappear after app restart.

We believe the reason automatic attribution works without calling CachePurchasePayloadContext() is that we set Apple's appAccountToken (a UUID embedded in the StoreKit 2 signed transaction) to the brainCloud profileId before initiating the native IAP purchase. When brainCloud receives the JWS receipt during S2S VERIFY_PURCHASE, it can extract the appAccountToken, identify the user, look up their active promotions, and increment the counter automatically.

Two quick questions:

Is this understanding correct — does brainCloud use the appAccountToken in the StoreKit 2 JWS to perform automatic promotion attribution, making CachePurchasePayloadContext() unnecessary in this flow? When we extend this to Android (Google Play), there is no equivalent of appAccountToken in the receipt. What is the recommended approach to ensure promotion attribution works correctly in that case — should we call CachePurchasePayloadContext() before the purchase, or is there another mechanism?

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.