I'm not a member of any Family in iCloud. I want to understand what happens when a user is subscribed through Family Sharing but also how to use StoreKit when the user is subscribed twice: as an individual who purchased the product and as a member of a family when the purchase is shared with him.
How can I test Family Sharing for an app offering a product with Family Sharing enabled? Is it possible to create a fake Family in App Store Connect and add testers to it?
Related
We have scenario where user needs to pay for every videos that are uploaded in backend/admin.
To achieve this we have to use Non-Consumable product by default but the limitation is to have the product created manually on appstore/playstore.
Consumable
Provide different types of consumables, such as lives or gems used to further progress in a game, boosts in a dating app to increase profile visibility, or digital tips for creators within a social media app. Consumable in‑app purchases are depleted as they’re used and can be purchased again. They’re frequently offered in apps and games that use the freemium business model.
Non-consumable
Provide non-consumable, premium features that are purchased once and don’t expire. Examples include additional filters in a photo app, extra brushes in an illustration app, or cosmetic items in a game. Non-consumable in-app purchases can offer Family Sharing.
My question is, according to business need we have to choose the Non-Consumeable product because it gives lifetime access to the item, but on appstore we have to create consumable product because it allows you to purchase again. i am confuse between consumable or non-consumable with the business requirement.
Pricing of the videos are same 25$
First of all, Non-consumable purchased once is based on AppleID, which means if you have multi-user and use same AppleID, it will restore automatically without buying again. In other words, it may become a risk to your business model. (Underground economy may use one AppleID to buy all movies and share the AppleID at a good price)
For your case, you may implement your requirements with followings steps:
Use Consumable product to buy for some coins(your server managed)
When user buy movie, consume their coins and provide movies
Your movies should be related with your app accounts instead of AppleID, so your server should sync the movies with app accounts
You may also use Consumable product to buy movies directly(description maybe like "25$ movies"), but it maybe contains an audit risk, for Apple may reject with reason "Using common product for purchase and product description is not detailed enough"
Just wondering if someone can clear this up for me as its kind of a grey area and not sure what to do.
I have a website that is split into frontend and api and has a subscription service provided by stripe on the api. I am now making apps in ionic for both apple and google stores but Im unsure of how the payments will work on the platforms, ideally i would like to just stick to using stripe but Ive been reading about both stores and this is where I need guidance.
From what I have read it seems to be that I have to use google play billing and apples alternative. Do I have to use these for the apps going into their respective stores or can I continue to use stripe within the apps? As i see it its a multi platform saas. So why cant I just send the card info to my api for charging?(I know theres alot of security involved and its not as trivial as I make it out to be)
Ive been reading conflicting statements from multiple sites and Im just not sure which is correct and the docs on google play billing make no reference to this. Its a multiplatform service so can I just send on the card details to my api
But what I have found is that apple have this
3.1.3(b) Multiplatform Services: 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.
Which to me states that I have to use Apple Pay and make no reference to my other payment methods for fear of being refused from the store.
I can't comment for Apple. For Google Play the best place to answer this sort of question is the Developer policy center. In the Monetization and Ads section it says
Developers offering products within another category of app downloaded on Google Play must use Google Play In-app Billing as the method of payment, except for the following cases:
Payment is solely for physical products
Payment is for digital content that may be consumed outside of the app itself (e.g. songs that can be played on other music players).
You should read all of the linked page and decide what category the stuff you are selling falls into.
I have payoneer account and i'd like to receive payments from app into this account.
Payments are not for physical goods. They are more like app content-unblockers.
Let's focus on Android and Google Play distribution case.
I suppose, payoneer is not designed for processing quick small payments, right?
I need these:
App should be able to set price according to misc factors.
Payments should be instant without credit card entering - i guess it called "Payments from Google Wallet". E.g. if i (app user) have google account and i have payment method in Google Play, then i do not need to enter my credit card number again.
Payments should be possible independently of user location (country)
So, can I use, say, Braintree to process payments with those requirements?
Will it violate any kind of Google Play policies (the fact, that i'm processing payments not through Google)?
The same questions about iOS
For Android : You can use third party payment seamless/non-seamless as long as their sdk supports Android platform. Google doesn't stop you from choosing any payment service.
For iOS : : It's million dollar question. Always refer to latest app store review guidelines https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
You can use third party payment gateway in iOS if you are selling physical goods/services outside of the app. For any in-app purchases you must use IAP.
For any in-app purchases if you use other purhasing mechanisms your app will be rejected.
Refer to section 3.1.1
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
Currently I am having one google play developer account.I want to Open New Account with same debit card which I used for my current account.all my details will be same as my old account.
In Short,can I create multiple Google play developer account with same credit/debit card?
Is it legal?
I also want to know that, If one of my account gets banned,will it affect second one,since both are created using same debit card.
It's fine, just be warned that if one is suspended, there's a good chance that both will br
No, you can not buy multiple accounts with the same Debit/Credit card.
Whenever one account is suspended/terminated then any other accounts with the same card will have the same actions taken.
Some days ago, a friend bought a console account, then after some time he bought another friend an account using same card. When the new friend's account was terminated, the first account was also terminated.
Our customers want to apply the following scenario for the app:
The user taps "Pay" in the app.
The app (or backend) gets the card info from the user's ApplePay account.
Card info is being used to perform a payment in another payment system.
I'm 90% sure Apple doesn't let to do this, but I can't find any docs.
This isn't possible: it goes against the whole point of having a payment system that obscures payment information from the merchant. Plus there's a million business reasons for the payment provider not to do this (and especially Apple, given that your client's requirement is likely to circumvent the huge commission they take on in-app purchases.)
There don't seem to be any docs on this (probably because it is so obvious that it's not an option) but there is this on the official Apple Pay website:
Your card number is never stored on your device, and when you pay your debit or credit card numbers are never sent to merchants. Apple Pay assigns a unique number for each purchase, so your payments stay private and secure.