Passing the User ID between an iOS app and Rails backend for In-App Purchases

Question

Created Jun ’21

Replies 2

Boosts 0

Views 3.9k

Participants 3

I'm building an iOS app whose backend is served by a Rails app. The majority of the iOS app is a wrapper around a Ruby web client.

Users will be able to access premium content on all platforms so I need to store subscription data against the unique user ID from my Rails database.

Right now I have it set up such that a user can make an in-app purchase for a subscription and Apple will send server notifications to my Rails server.

The issue is connecting a Subscription object on my Rails app with the correct user ID attached.

Right now, the user, even though they've paid, does not have any access to the premium features since the Rails server has not been able to mark that user as paid.

They also remain on the "Buy" page after a successful purchase.

Ideally, upon successful payment, they are marked as 'paid' in the Rails app and are then taken to a suitable page. Or, upon a failed payment, they are shown a suitable error.

@oscaretu's answer here — https://developer.apple.com/forums/thread/674738 — is really helpful (I can just assume the user has access to paid content until I can connect the receipt original_transaction_id with the unique user ID) but I still don't understand the idea of "asking a user to connect to the app" given they will already be in the app (having just made the purchase).

Should I be storing the Rails user ID in the iOS app independent of any in-app purchases? If so, how/where?

After the INITIAL_BUY notification, how do I immediately trigger a second request to my Rails server, somehow passing in the correct user ID from my Rails app?

To ensure a smooth user flow, how do I direct the user to another page upon successful payment?

Thank you so much to anybody who can take the time to help me out. I really appreciate it!

Boost

Answer 1

oscaretu OP

Jun ’21

Hello, @noddam.

In our case, we have to create a external subscription in other system that we have to bind to the one purchased in Apple. And to do that binding we need the userID in that external system, so we have to store the userID (that the app sends us when the user buys the subscription in the app).

When you receive notifications from Apple you don't have any information about the user. Allyou can use is the original_transaction_id, because that data is a common field that let you relate all the purchased derived from the "first" purchase notified by INITIAL_BUY.

Remember that after a subscription has expired, the user will be able to renew it from outside the app (during the purchase tests in the Sandbox, in iOS 14, it is under Settings->App Store (I have a Spanish version iOS, so I don't know the exact name, but the translation would be something like "Test environment account), so you should have a field in your database that let you bind an original_transaction_id with an user when you receive a notification.

Check my answer in thread https://developer.apple.com/forums/thread/680581 so you can see the suggested source code sample to get a summary of the subscription state.

In our case, when the user makes a purchase in the app, we send the userID, and the original_transaction_id, the purchased product to a URL in our backend server, and register that information in the database (using the original transaction_id as the database primary key).

When we receive notifications, using the auto_renew_product_id and the unified_receipt.pending_renewal_info we get the original_transaction_id afected in the notification. That original_transaction_id will be used to query the database, and get the userID related to that purchase.

Kind regards, Oscar

1

Answer 2

IRgEEK OP

Mar ’23

Hello. We have the same problem described in original question, but slightly different in that the issue for us is when a user subscribes by redeeming an offer code.

For subs they purchase directly from our mobile app, we know the user's id at time of purchase, create the association between the user and the new subscription transaction id and then use those identifiers we receive in app store notifications to update the subscription status for the user (essentially just as Oscar described).

However, if a user redeems a code for a free subscription via redemption url or by entering the code directly in the app store, bypassing our app, we receive an Notification of Type: OFFER_REDEEMED directly from app store and we don't have a transaction yet on our backend to know which user just subscribed to a new subscription using the redemption code.

Any suggestions/ideas/info on handling that variation is very much appreciated!

0