S2S Notification - No TRANSFER Event Received

Hey ​@rcuser1721,

Based on how you’re describing your set up, likely what occurred was that that the `INITIAL_PURCHASE` was sent with the RCAnonymousID attached, but then the anonymous ID and your provided Firebase user ID were aliased together and considered one user going forward - in these cases, no transfer event is sent. 

Additionally, if you only S2S notifications for refund events, it’s certainly safe to turn off tracking new purchases and just go forward with identifying users with your Firebase user ID from the start of their lifecycle. 

thanks for your response 👍 ​@kaitlin. In the doc I see

If not, it may happen that we first track a purchase for App User ID A from a server-to-server notification and later we receive the same purchase from the SDK or the REST API under a different App User ID B. In this case, no transfer will occur, and App User ID B will never get access to the entitlement.

It mentions that if I meet the 4 conditions, there should be a transfer event. Could you please help me understand when to expect a transfer? I was expecting it as the scenario seems to meet the criteria.

Additionally, if you only S2S notifications for refund events, it’s certainly safe to turn off tracking new purchases and just go forward with identifying users with your Firebase user ID from the start of their lifecycle. 

makes sense, thanks.

Hey ​@rcuser1721,

A transfer event will occur in cases where there’s a change in user identity that is not an alias. I think that the sentence you’ve quoted could probably be worded a little differently to be more clear, as a successfully implemented server to server configuration with “track new purchases” enabled won’t always trigger a transfer. 

Most commonly, if we receive a purchase from S2S and attach an anonymous ID, then receive the purchase from the SDK with a custom ID attached, these will be aliased, particularly in the case that this is the first time this custom ID has made a purchase. 

A case in which a transfer event would occur would be if the custom ID attached to the SDK purchase already has an anonymous ID aliased, as a custom ID can only have one anonymous alias. For example, if the user in the first scenario makes a second purchase. In this case, the purchase would transfer from the anonymous ID that was generated when the S2S purchase was received to the custom ID attached to the SDK purchase, and a transfer event would be triggered as well.

Let me know if that makes sense. A helpful thing to check out could be the table we have in our documentation for .login method alias behavior. Although the S2S process isn’t triggering a login call, the behavior around custom IDs and anonymous IDs is similar: https://www.revenuecat.com/docs/customers/identifying-customers#logging-in-after-configuration