Skip to main content

Paywall - iOS with backend managed subscriptions

  • 27 November 2023
  • 1 reply
  • 91 views

Hi everyone,

I am integrating Paywall in an iOS app. Looking for suggestions/recommendations. My use case is that I want to show users of the app a paywall and then create and update related records in my backend database throughout the subscription lifecycle. I want to do this so that I can check subscription/consumption status from the database when API calls are made to the backend. Below are my questions:

 

  1. How do I create these records in my backend service? This (very detailed and awesome blog) https://www.revenuecat.com/blog/engineering/ios-in-app-subscription-tutorial-with-storekit-2-and-swift/ gives an example of making an API call to the backend on successful purchase. Is there a way to do something like this when using Paywall? I am thinking to create the first subscription record this way and then manage updates by exposing a webhook
  2. Are webhooks reliable and real-time? Is there any recommendation to use them (or not) as compared to forwarding apple’s server notifications from RC to my backend API?
  3. How do I identify and map the server notification I receive to a user for which the notification was sent?
  4. How do I got about deciding when to show the Paywall? I read that it can be done using metadata but couldn’t really find any examples. My use-case would be to remotely decide when to show users a paywall. For example, I would want to show when users complete onboarding and once when they’ve used a key feature X number of times. But I want to be able to enable/disable either of these without a code update

 

Thanks in advance!

Hey @g-s-b2b95e,

  1. There’s nothing quite like you describe out of the box with Paywall, but there’s nothing preventing you from making customizations to the paywall that could make an API call to the backend on a purchase as you describe!
  1. Regarding webhooks - you can read about best practices here, but they are generally delivered within 5-60 seconds of an event occurring. You can decrease lag time by setting up Platform Server Notifications as well, they’re really best used in conjunction and compliment with each other. 
  2. The transaction ID included in webhooks is the same transaction ID used by Apple in their receipts.
  3. We’ve shipped a new feature we’re calling “Targeting” that sounds like it might help on this point, allowing you to assign a distinct Offering to a distinct audience of customers based on Targeting Rules you create: https://www.revenuecat.com/docs/targeting
     

 

Reply


Terms & ConditionsCookie settings