Google Play Billing allows get notifications about subscriptions that users make in the app. There is a doc describes how to use this feature https://developer.android.com/google/play/billing/realtime_developer_notifications
But the doc says only about subscription not about one time purchases that users make in the app within google play.
I can't find any information related with notifications about single purchases, not subscriptions. Is anyone know how is it possible to get notifications about purchases?
They don't offer it. You will get email from Google Play for one-time purchase.
I think that the Google documentation was updated. Because in this link that you shared, we can see that the information about one-time purchases (or product purchases) is on the OneTimePurchasing tag.
Also, we must pay attention to what the documentation says:
If this field is present, then this notification is related to a one-time
purchase, and this field contains additional information related to the
purchase. Note that this field is mutually exclusive with testNotification
and subscriptionProductNotification.
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
I'm developing an app that allows users to subscribe to each other's content via paid subscription. For example, user A can subscribe to user B's channel for $5/month and I take a small fee from the transaction (user B gets the remainder).
Apple policy states that all in-app digital purchases and subscriptions must be done with Apple In-App Purchase, but does this include digital user marketplaces? I'm in the middle of implementing Stripe but I'm not sure if this is allowed.
If I have to use the In-App Purchases, does this even support my model?
Thanks!
If you want to facilitate the transaction through your app, then yes, it needs to be done through an in-app purchase. You can use Stripe for users that subscribe on your website, but you can't direct users there to make a purchase from your app.
Apps that operate across multiple platforms may allow users to access
content, subscriptions, or features they have acquired elsewhere,
including consumable items in multi-platform games, provided those
items are also available as in-app purchases within the app. You must
not directly or indirectly target iOS users to use a purchasing method
other than in-app purchase, and your general communications about
other purchasing methods must not discourage use of in-app purchase.
With in-app purchases, you'll need to facilitate the payouts yourself. This could be difficult since you'll probably want to wait until Apple pays you before you distribute (usually 1+ month after purchase), and you'll have to track refunds and cancellations. If your app is available globally there's also the fact that you'll get paid out different $$ for the same subscription depending on the country it was purchased due to tax differences.
Also, since you can only be subscribed to a single product within a subscription group, you won't be able to have a user subscribe to channel A and channel B with 2 subscriptions.
Really, the best solution for this type of marketplace is to use something like Stripe Connect as you've figured out. However, you'll have to process this purchase outside of your app and not direct users there from within your app.
A solution to use in-app purchases could be to switch from a subscription to a consumable purchase to unlock content for a specific period and manage the expiration date yourself. This would allow a user to make multiple purchases to unlock multiple channels. The downside is that this won't auto-renew, which may mean less revenue for you. You'd still have to handle the payouts yourself, but it would be simpler to manage one-off purchases then dealing with all of the nuances of iOS subscriptions.
We are building a subscriptions based video on demand platform that lets our subscribed users to access films from a variety of devices including iOS, Web etc.
So no matter from where the user has subscribed, they should be able to access the content from any & all devices that we support.
Since I need to maintain user's state at a central system (so that all devices can query & allow/disallow access to paid-content).
I have read through multiple documentation re: iOS In-App Purchases & have determined we are a good fit for auto-renewable subscription category.
I have already integrated subscriptions via Roku & using that as a reference. For users who are subscribing through the Web, I have also integrated payment processors like Amazon Payments, Stripe & PayPal - the transactions for which are triggered by the Subscriptions Billing platform that I have already built.
My server (or an endpoint essentially) needs to be able to receive following bits of information preferably directly from iTunes and not from my app.
Notification when a user subscribes successfully to one of my products
Notification when iTunes sucessfully renews a subscription i.e. if user is subscribed to a monthly product then at start of next month, I need to have notification from iTunes that user has been successfully charged for upcoming month
Notification when iTunes successfully refunds a user for whatever reason
Notification when a user cancels a subcription directly from iTunes (not from the app). I know in this case it will mean that it stops the auto-renewal, but I still need to know that this has happened.
Notification when a user un-cancels the auto-renewal.
Does iTunes support any of these actions via Webhook or Push or IPN (instant payment notifications) etc? I havent come across it, if it does.
I know that there is something called as Validating Receipts but that seems to be not a good solution for me, since I need to know ASAP rom iTunes that one of the above flows has happened.
What, if any, are the workarounds to get this information? I am afraid that getting this info from my app is neither timely nor guaranteed to get it.
If you're expecting a direct feed from iTunes, you need to reevaluate your requirements. The in-app purchase ecosystem simply doesn't work that way. You may have the option to write your own subscription processing system (requires an outside payment processor) but whether Apple will approve it will depend on the exact nature of your content. From your description, you have mutually-exclusive requirements.
If the immovable requirement is that you use iTunes, you will need to validate receipts and forward those results to your server.
The app I'm working on was recently rejected by Apple for containing an auto-renewable subscription. They recommended that we switch to non-renewing subscriptions for our content.
The one thing I can't quite wrap my brain round is how to restore a purchased subscription to a shared device. Apple recommends we don't use user login - something we would like to avoid ourselves. I did come across one solution where unique codes were used between the two devices - to validate a purchased subscription, through a server. But I believe that could be easily pirated, as in theory friends or employees within a company could share these unique codes with one another and avoid paying the subscription charge.
I can't really find much on Google about this, and was curious to know if anyone has been able to successfully implement a non-renewing subscription?
To paraphrase the advice we received from Apple when dealing with these issues:
Per the iTunes Connect Developer Guide:
...subscriptions must be provided on all devices associated with a
user. In App Purchase expects subscriptions to be delivered through an
external server that you will provide. You must provide infrastructure
to deliver subscriptions to multiple devices.
Apple consider user registration to be appropriate but won't allow you to make it obligatory. So registration must be optional and the user must be able to register at any time — including to allow them to share a subscription they've already bought between devices.
So it sounds like we may have received slightly different advice. Is it possible that Apple only told you not to require user login in general, separately from the requirement for distributing the subscription to all devices?
My app implements the iOS auto-renewing subscription to access premium content. I haven't yet submitted this for approval, because I want to know what subscriber information I'll be able to access once users purchase subscriptions. I need this information so that iOS app subscriptions integrate with a separate business database handling subscriptions on other platforms.
My reading of the typically-cryptic Apple docs is that name, e-mail and zipcode are available but only if the user explicitly opts in. But I'm not clear how to request that this information be asked for during the purchase process, or whether there's additional information I can ask for.
So here are my questions:
Are subscriber name, e-mail and zipcode the only pieces of information available via iTunes Connect?
If (1), is this information available only through opt-in?
If (1) and (2), how does the opt-in process work?
I think so. Although I've never received this info, based on the dialog below, I can only assume you don't get more info than they list.
Yes. You can't require the information. You'll only get the information if the user opts in.
You don't have to request that the user be prompted. In fact, you can't prevent the dialog from appearing when the user first subscribes to your auto-renewing subscription.
From Marco Arment's post on The limited world of auto-renewable subscriptions:
There’s no way for a developer to opt out of this data collection and
disable this dialog. If you sell an auto-renewable subscription, your
customers will be told that you want their personal information, and
you will be given that information [...] whether you wanted it or not.
Please read the rest of his post to see why you may want to steer away from ARS. Apple may reject your app if you're not a magazine or newspaper.
This is what the dialog looks like: