Here is the Setup:
1. App is a race car game where user has different cars they build.
2. User can buy new parts for each of their cars.
3. Upgrades are onetime, non-expiring purchases.
4. One upgrade is for one car only.
4.a. if user wants to upgrade tires for two cars...the user makes two purchases of product ID "nrp_tire_lvl3_199"
1. User is managing two cars (A, B, and C).
2. User wants to upgrade tires on car B.
3. User makes purchase of "nrp_tire_lvl3_199"
4. Our server receives the Web hook notification of the purchase.
??? How can we tell the server which of the User's cars to apply the upgrade to? How can the Server know to apply the upgrade to Car B?
Best answer by ryanView original
This is actually a tricky problem to solve. In a perfect world it’s straightforward and additional context can be passed in the same API call as the purchase. The problem is that mobile apps rarely operate in a perfect world.
If the API call is interrupted due to a network error or the app is closed during the request, it could be dropped. This means the additional context would need to be cached, and re-matched with the correct line-item in the receipt to be re-tried later. There’s also the possibility that the customer redeems an in-app purchase through a promo-code, gift card, or some mechanism outside of your app. This means that it’s possible to see a purchase without any additional context.
Because of these known edge-cases, I’m not sure that there’s a way to accomplish this with 100% certainty 🤔.
You would need a solution that can operate with only the context available from Apple and achieve the result you want.
Here’s the one we came up with before your reply.
We had a crazy idea where we would set a Subscriber attribute before calling the “.purchase(SKU)” API.
An example would look like this:
If I understand the system properly, the web-hook event our server would receive would now include the subscriber attribute we need to match the transaction with the car.
I see two important points of failure with this approach.
Using subscriber attributes could work, but I would still have a system in place to handle edge case scenarios where a purchase is received without one of these attributes - you’d probably have more control here if you used your own database to manage this type of state.
You should never use subscriber attributes themselves to unlock any features or content, since they are writable through the SDK. However, it seems that your approach is safe since it would require a subscriber attribute and a purchase to get access.
The first to come to mind are what I mentioned above. Know that you could still get a purchase without one of these set, and know that it’s possible for them to be manipulated from the client.
Yes, the body will remain the same across retries. The payload is created when the event is generated and the same payload is sent for retries. However, this doesn’t mean that the customer might make an additional purchase between the retries and fire off an additional webhook event.