I have the following business model and I'm not sure is it possible to manage it using IAP.
The user can create and share with others premium content. The rest of users may subscribe "the content" to get an exclusive access in a specific period of time. Price list might be the same per each specific groups of products.
Example:
User A1 creates premium content P1 (price 0.99$ per month sub)
User A2 creates premium content P2 (price 0.99$ per month sub)
User A2 creates premium content P3 (price 0.99$ per month sub)
User A3 subscribe (auto-renewable) to P1, P2, P3 (A3 is charged three times every month)
User A4 subscribe (auto-renewable) to P2 and P3 (A3 is charged twice every month)
The problem I met so far:
1) When the premium content is adding dynamically, each new product has to be added to iTunes List. It's not scalable what if there are 10000 different premium products?
2) What if I'd just define the list of all possible auto-renewable price tires, for example, 10 different tires - it's still not possible to charge user more than once for a content using the same product_id.
Generally, It could be handled by custom server solution supported by Paypal or Stripe. The problem is that selling digital good requires that the In-App Payment need to be used.
Adding 10,000 different IAPs is not scalable. Each new IAP also needs to be approved by Apple so this doesn't work.
It would be possible to create multiple subscription products at different prices. If you put them in the same subscription group, you would be able to initiate a new IAP to migrate the user from tier to tier without a gap in billing. I would suggest selling a smaller number of tiers (0-5, 5-10, 10+) rather than forcing the user through an upsell experience every time they added a single new subscription.
Related
I reached out to Apple Support to ask this:
Our users have to make purchases at different prices, and these prices are not fixed. We decide on these prices based on unit area and unit price. For example, let the unit price be 2 USD. Tom has 13 units of field and the amount he has to pay is 26 USD. John, on the other hand, has 38 units of field and the amount he has to pay is 76 USD. Each of our users has to pay different fees depending on the unit area in this way. In this scenario, which in-app purchase category would you recommend we choose, and what kind of in-app purchase structure would you recommend?
And they replied: "...it may be possible for you to have allow users to purchase tokens, which will then be redeemable against their own unit area."
Well, I had some more questions. My questions are:
1- Do the customers get the tokens in bundles? Can they pick an exact number?
2- Can we set these consumable tokens as expiring? For example when our users use their tokens on our services, we want them to utilize our services (that they get with the tokens) for one year. If they don't use their tokens, their tokens won't expire.
3- Can we set these tokens to provide monthly services as well?
4- Would it be better for our customers to get some tokens first (so that we don't confuse them with 2 different types of tokens: annually & monthly) and then when they pick whether they want to get our services monthly or annually, they will be asked to 'spend' their tokens at different amounts? Is that possible?
Thanks a lot!
Is it possible to change an in-app purchase from inside the app?
I have a tier based setup
Tier 1 - Tier 2 - Tier 3
Say Tier 1 price is $.99, then Tier 2 price is $1.99, then $2.99
Let's say a user bought Tier 1 for $.99, then I wanted to change Tier 2 From $1.99 to $1.29. ONLY IF the user only bought the first Tier.
How would I go about this? If I can?
Unfortunately, you cannot change the tier's price, only pick from existing once. Perhaps you could make several products with different prices and offer one or another depending on the purchase history.
For example, your Product X may cost $2.99 full price, but Discounted Product X would cost $1.99 and be offered only if the user has purchased other products.
I have implemented In-App Purchases in various apps before wherein we can set a price based on a specific Tier for a Product.
Now in this case, the price of the product depends on the number of people. For example, a video will Cost $ 0.99 for >20 students, for >50 students it will be $1.99 ,etc.
So, I thought of making different products for each such case.
Eg:
Product1. VideoForUpto20Students for $0.99. (Video course 1)
Product2. VideoForUpto50Students for $1.99. (Video course 1)
So if I implement it in this way then if the number of students increase, then I will have to create more product Identifiers for a same Product.
Again, I have a number of Video Courses approx. 40 ! That means, the total number of product identifiers for 40 Video Courses having 4 different prices will (40 * 4) = 160 product identifiers.
So, do I need to create different product identifiers for the same product to set multiple prices or is there any other alternative ?
Please help! Thanks in advance!
You will have to create different identifiers for every In-App Purchase unfortunately.
From the accepted answer here In-app purchase custom price:
As noted by other poster, you cannot have variable in-app purchases.
You have to select one of the provided price tiers.
While you aren't exactly making it so the price is changing a lot (since your idea isn't a delivery service), if it is going to change at all you are going to need to create multiple identifiers.
I know this is supposed to be simple but I'm having trouble coming up with a good, simple setup.
I'm building an app for a school. The school charges for things like pre-registration fee, supply fees, monthly enrollment, etc.
The most important aspect of billing is the monthly enrollment. Let's say it's $50 per month. I want to setup recurring billing (maybe with Stripe), but some people might choose to pay cash, or check or one-time credit card charge, instead of an automatic monthly withdrawal from their account.
Also, fees other than monthly enrollment, such as supply fees, books and such.
I was thinking about creating an Invoice setup, which I already have from another app (kinda like Freshbooks or Blinksale, [Item, LineItem, Tax, Invoice, Payment, etc]) but I thought that might be overkill.
So how would you set this up? Important points...
Ability to charge a monthly recurring fee and other one time charges
Able to track if item is due or if it has been paid
Track if monthly enrollment has been paid, MAKING A RELATIONSHIP between the payment and the monthly enrollment
I would just have a payments model. It would have a frequency (monthly, quarterly, half-yearly, yearly), payment status(paid or pending) and due date and type of fee(pre-registration, supply, etc)
If a guy opts one time payment in beginning, he would have all payments inserted and due date would be the current date and all the statuses would be paid.
If he opts for some fees to be paid monthly, he will have 12 records in payment table with frequency 'monthly'. The due date would be spaced one month apart each. The status of the last 11 records would be pending.
You can now track the list of payments whose due date is within next one month and take appropriate action.
I'm developing an app in Ruby on Rails where companies buy advertising campaigns. First they buy credits to their account on my site, then they buy the campaigns with the credits. The thing is the campaign is payed per view/click. A company reserves a budget of credits for each campaign and these reserved credits can't be used to buy other campaigns with. When a campaign ends and not all credits are used they will be un-reserved and available to buy more campaigns for.
How do I structure the models in the database and how to move/reserve/un-reserve the credits in order to periodically check for any credits that should be un-reserved in a background process?
Have a client/campaigns relationship. Each client has a number of credits. Each client campaign can withdraw credits from the client. As a campaign is viewed/clicked it withdraws credit from the client campaign.
A process periodically checks for lapsed campaigns. When it finds one, any remaining credits are deposited back to the client's main account.
All the money is kept in the company's account all the time. The goal is then to dynamically calculate how much of the funds that are reserved and how much that are not. This can be done if every campaign have a reserved amount attribute and a used amount attribute. When a user clicks on the campaign I withdraw money from the companies account and add them to the campaigns used account.