Skip to main content
Solved

Questions about migratung from another service to RevenueCat

  • 4 March 2022
  • 3 replies
  • 199 views

I currently use Nami Paywall for in app purchases on Android and iOS only. I want to move to RevenueCat. I would like to know if I need to sync purchases receipts or import receipts into RevenueCat? 

I am not sure if Nami allows us to export data however I like to know if

1.) it’s required

2.) what are the benefits of import the data to RevenueCat

3.) scenes all of my users that made in app purchases are iOS and Android users (devices) would RevenueCat be able to pull in all of the data as far as previous sell history, trend information, active users when every a user launches the new app version of the app for the first time. 

 

Can someone please explain to me the most important things that I need to do. basically I just want to allow my existing users that have active subscription in the apple App Store and google play store continue to use there subscriptions as  seamless as possible. If possible I would love to have there purchase history once they launch the app for the first time. 

 

Last question If I have to import something (I only have 400 active users) how long would the import process take before everything is reflected in RevenueCat 

3 replies

ryan
Rank
Userlevel 5
Badge +9

Hey @Jerry Seigle, welcome!

Doing a server-side import of your data is not required, but it does have benefits. If you’re unable to get the data exported from Nami, don’t worry you can still start to migrate things over client-side. I’ll try to explain the differences below.

Pre-read: https://docs.revenuecat.com/docs/migrating-existing-subscriptions

Client-side migration:

This is essentially syncing the purchases from the device the first time one of your customers opens the next version of your app containing RevenueCat. The main drawback with this approach is you’ll never know for sure if all of your subscribers have actually been migrated. For example, if you have 400 active subscribers, the truth is maybe 10 don’t open the app for months or years (or never). Those subscribers never show up in RevenueCat. 

The impact this has is mostly all on the analytics side. Charts and Lists will show a lower number of subscribers and revenue than you actually have. However, it should not impact subscription status at all, since the customers that have not been migrated aren’t using RevenueCat for subscription status (they’ll still be on your old system). This does mean though that you should keep the old system around for these customers.

Server-side migration:

This is almost always the preferred option, if possible. I would hope Nami would allow you to export the iOS receipts and Android purchase tokens if you’re closing down your account. With a server-side migration you know for sure that all of your subscribers are in RevenueCat. The main benefits here are improved analytics in a single place, you can completely shut down the old system, and you don’t have any migration code in your app which could mean less chance for bugs.

 

The route you choose is up to you. I did a client-side migration with one of my apps because I didn’t have receipts and things are fine.

 

Last question If I have to import something (I only have 400 active users) how long would the import process take before everything is reflected in RevenueCat 

If you’re doing a server-side migration, I’d write a little script that hits our POST /receipt API and you’d be migrated in 400 API calls (very quick). We do bulk imports manually on our end but our queue is pretty backed up right now as we’re running some really large imports.

J
Badge +3

Lets say that If I don’t import anything or lets say that I over look one of the active users from the old system. When they launch the new app with RevenueCat what will happen. Would they have to purchase a new subscription or would they be able to restore their in app subscription purchases?  Also I reached out to Nami. There is no export feature. however I was told that they get all user subscription purchase information from apple App Store and google play store. Also my app only does yearly and monthly auto renewing subscriptions. 

 

Last question. I am not clearly user of what all information is require in the import. Is there documentation on getting this information directly from Apple App Store and Google Play store

ryan
Rank
Userlevel 5
Badge +9

Lets say that If I don’t import anything or lets say that I over look one of the active users from the old system. When they launch the new app with RevenueCat what will happen. Would they have to purchase a new subscription or would they be able to restore their in app subscription purchases?

Good question. Customers will always be able to restore transactions which will sync the current subscription on the device with their App User ID. Make sure you have a button to trigger the restore function somewhere that’s accessible for customers: https://docs.revenuecat.com/docs/restoring-purchases. 

 

Last question. I am not clearly user of what all information is require in the import. Is there documentation on getting this information directly from Apple App Store and Google Play store

The primary piece of information you need is the raw receipt file from Apple (called a Purchase Token on Google). This piece of information is only available from the device directly - there’s no way to export these from App Store Connect or call a server-side API to retrieve the info. I would expect that Nami should be storing these raw receipt files on their server after they collect them from the device. Without this piece of information there isn’t a way to do a server-side migration to RevenueCat. 

If you look at our POST /receipts endpoint, that is the required data to import to RevenueCat. If you don’t have it already saved on your server or are unable to export it from another service, then you’ll have to go the client-side migration route (since the required data only exists on the client). https://docs.revenuecat.com/reference/receipts

Reply


Terms & ConditionsCookie settings