Thank you for such a thorough response! If I’m understanding this correctly, if a site were to use auto-indexed user IDs (which is truly an anti-pattern these days), it could cause an issue because users on staging & production could have the same ID. However, if the servers use UUIDs (as is generally recommended), it should work seamlessly because RevenueCat will ignore server notifications for users who’s IDs are unknown.
In my case we use UUIDs, so it sounds like this should work.
Hello,
Yes, that is correct, your public API key is what steers your SDK requests to one of your projects. In that sense, you can almost think of your staging project’s API key as a “sandbox” key, and your production project’s API key as a “production” key. (This distinction doesn’t actually exist in real life, you just have to be careful about which API key you use in which build to make sure staging purchases don’t land in your production project or worse, production purchases don’t land in your staging project.)
Google Pub/Sub and Apple S2S notifications (I’ll refer to both of these as platform server notifications) use a completely different system. Whether a RevenueCat project receives a notification from them is purely based on whether you choose to connect that service to RevenueCat. So if you connect your Google Pub/Sub to your production project, that project will receive all Google Pub/Sub notifications, including sandbox notifications. Same with Apple.
But there is a workaround for your specific case here. Rather than ingest the notification as is, RevenueCat uses platform server notifications as notifications to refresh a purchase that we have in our systems. The flow looks a little like this:
- Google charges a user to renew a subscription.
- Google sends a notification via Pub/Sub with that subscription’s info to RevenueCat.
- RevenueCat notes the subscription’s unique identifiers and checks if we have that subscription in our system.
- If not, we ignore the notification.
- If yes, we refresh the subscription via Google’s API endpoint. Note that we do not rely on the notification for the subscription details, we always go back to Google’s APIs.
As you can see, step 4 is key. With your setup, your production project will only have production purchases, while your sandbox setup will only have sandbox purchases. So, if you connect platform server notifications to your production project, it’s true that notifications for sandbox purchases will be sent to the production project. But, since your production project doesn’t have any sandbox purchases in it, it will simply drop any notifications for sandbox purchases. Likewise with your sandbox project, it will drop production purchases.
So, in conclusion, you don’t have to worry about platform server notifications mixing your two environments together. Just make sure you remember to change your API keys when releasing a production build!