Ordering of intial purchase/user attribution request and first RTDN request

[huwcarwyn]

Thanks so much for this package firstly - so much effort and the code looks really nicely architected.

I'm wondering how you ensure that a user is securely associated to a purchaseToken before any RTDN request hits your app. Here are my thoughts:

• user completes purchase, the app itself then sends a request to my laravel server with purchaseToken where I create a subscription record for the user in some initial, inactive state.
• RTDN message then comes through with notification type of (4) SUBSCRIPTION_PURCHASED
• I then update the subscription record created in step 1, marking it as active.

I can see ordering of events mattering a lot here, where my app could receive and start processing the SUBSCRIPTION_PURCHASED RTDN before the first request from my app happens.

Is this a common issue? How do you handle this flow of associating a user to a purchaseToken? I don't want to rely on the RTDN messages to do this step as I don't think it's possible in a secure way?

Thanks in advance :)

[huwcarwyn]

Apologies btw - I see this has been discussed once or twice, excepting my concerns about the ordering issue, so I guess my question should really be scoped to anything past the bullet list!

[imdhemy]

Hi @huwcarwyn
Thanks for you nice words!

Both Google Play and AppStore provide a mechanism to attach a masked user ID to each purchase. The android/iOS developers need to collaborate with the backend developers on this.

Mobile App

• Google Play: setObfuscatedAccountId
• App Store: appAccountToken

Backend

• Google Play: You need to send subscription:get request to get the obfuscatedExternalAccountId.
• App Store: You will received the appAccountToken in the V2 server notification.

This is the suggested flow from the providers, I hope this answers your question.

Note

Regarding the deprecation notices you see in the documentation, I'm actively working on supporting the new workflows, and I welcome any contribution you may have.

[huwcarwyn]

hmm I see - so during the initial request my android app makes post-purchase, I generate an anonymous ID which I set as obfuscated account ID of the user.

I still see a potential ordering issue here - what if my server receives the RTDN SUBSCRIPTION_PURCHASED call before the request from my android app to my server is able to set this obfuscated ID?

This scenario may never happen, it's just something I can imagine happening when you have a race between the android app to associate my user to a purchase, and Google sending an RTDN notification to my server..

[huwcarwyn]

Ooooh I get it now! This obfuscated ID is set on the initial purchase request, so theoretically you could use this to match to the user no matter which request happens first since it's going to be set way before any request has arrived...makes sense now!

For other readers in my boat:

• Generate an obfuscated ID attached to your user (my case is easy, I have a hash-slug derived from the User's ID)
• Set this obfuscated ID in your request purchase (below example is using expo-iap)

  request: {
    ios: {
      sku: productId,
      appAccountToken: 'user-123',
    },
    android: {
      skus: [productId],
      obfuscatedAccountIdAndroid: 'user-123',
    },
  },
});

• Any RTDN subscription notification from google will have this obfuscated ID attached, allowing you to match the user in your laravel app to the user the RTDN notification is about.