we have created a publishing platform that is similar to Zinio,
We have a website where we upload magazines, and publish them to our mobile App on iPad
Apple is rejecting the App for the following reason:
Apps that use IAP to purchase items must assign the correct Purchasability type We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
Your In App Purchases are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Consumable In App Purchase type. Non-consumable products are only purchased once by users and are always available on all devices that are associated with that user's iTunes account.
We have Replied and Explained them Several Times the following:
We are using consumable type of in-app products since we have a lot and frequently released magazines with different prices therefore we cannot define the purchases to be non-consumable.
We have set pricing Tiers from $0.99 until $54.99 so that each magazine will be classified appropriately and assigned to a certain Tier.
our system has a lot of magazines where each one has many issue releases. Magazines issues are sold within an offer.
We have "single issue offers" (offers containing only one magazine issue) and "multiple issues offers" (offers containing multiple isses, eg: get 3 digital issues of magazine x for $19.99).
We are using the Tiers from 1 to 55 to assign prices for our offers. Note here that the in-app purchases are consumable but our system won't let the user buy an already purchased item another time.
The application will contact our server each time when the user attemps to buy an offer.
If the offer is already bought, the application won't proceed with the in-app purchase and the user will be shown that he has already bought that offer.
Anyone has an answer to solve this problem?
As apple is insisting that we should not use consumables and use non-consumables which is not logical, as we need to be submitting the app every time magazines has been added to the system.
Help is Much Appreciated
For magazines, you are unlikely to get consumable in-app purchase ability from Apple. They've made it clear in the past that the expectations for media, levels, and content of this type are expected to be present on all of the users devices.
However, based on your description of what you are trying to do, I'm not sure that this is a problem. Remember that consumables are not the same as subscriptions, in that a subscription gives you access to potentially more than one issue, whereas a consumable just means that is something that may not be available after you purchase it, I.e. that it might be consumed.
It sounds like the real problem here is a catalog issue. For episodic content, such as magazines, you don't want to hard-code your in-app purchases, instead look at the server-based model, as described in:
http://developer.apple.com/library/mac/ipad/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html
With this model, your server can return a list of product identifiers that meet certain criteria, so you don't have to constantly update the app.
Related
I have knowledge about in-app purchase, but stuck in implementing in app purchase in my case.
I have a list of videos coming from server when I click on any video I can download it in two formats, one low resolution and other is high resolution after in-app purchase. I have created two product identifier in itunes and have no any problem in implementing. But how will I keep track of the video and resolution I have purchased and also how will I use restore to get that product again if I purchased it once. Any advise will be highly appreciated.
I have a Windows Store app for a newspaper in the Windows Store. Each issue (one per work day) can be bought using in-app purchases. In Windows Store, it looks like i can define only 100 in app purchases. In my case, that is about 4 months of daily issues.
Is 100 really the limit? Has anyone found a way to add more?
I cannot find a way to add more in-app purchases to the app. The milit of 100 would be a really stupid constraint and I would need to remove to ability to buy old issues in order to add new issues.
Windows 8 doesn't support subscription-based purchases but it does support time-limited purchases.
One option is to let the user purchase "credits" that can be applied toward an issue. Similar to how Audible lets you purchase audiobooks with credits.
Here's the thing though. Newspapers make money off advertisements. The purchase price isn't for the content, it's for the materials that it costs to deliver the paper. A digital paper costs nothing to deliver so why are you charging for it?
The store does not support subscriptions. However you can just use a third party provider for this.
As mentioned in the 'Flexible business Model'
http://msdn.microsoft.com/en-us/windows/apps/hh852650.aspx
The Windows Store provides you with the freedom to choose the business
model that’s right for your apps. The Store provides full platform
support for free apps, trials (both time-based and feature-based), and
paid apps, as well as in-app purchases. You’re free to manage customer
transactions directly using your own or third-party services for
in-app purchases and subscriptions, or use the services provided by
the Windows Store. For apps that are supported by ads, you’re free to
choose the ad platform that best meets your goals.
Paypal is accessible via this api:
http://paypal.github.com/Windows8SDK/
or directly via a form post
How to Form POST to Paypal from WinJS iframe Windows 8 App?
Is it possible to sell consumable products via in-app purchase?
This looks to be fixed in Windows 8.1. http://msdn.microsoft.com/en-us/library/windows/apps/bg182887.aspx#two
Just to add my 2 cents to the answers:
There is a limit on the number of IAPs on Windows 8, and it is 200 (but has been removed in Windows 8.1). This might seem like plenty, but an app can easily have 10 or 20 different IAPs, which divides that number down to 10 purchases in 24h, which seems like a limit some users could very likely hit soon. To add two more complex ideas of a solution to this:
You could use analytics to get the maximum number of each in-app item users purchased in a 24h window and adjust the number of each IAP products per in-app item accordingly, i.e. assign more IAP products to most used in-app items, and less to items that are not purchased so many times in 24h.
You could have IAP products assigned to price tiers, i.e. define 50 products for $1.49 priced in-app items, 25 for $1.99 and so on..
For completeness, I'd like to quote #Chris Bowen's link to the workaround debate:
If the games are being XBL enabled they will have to use the built-in
Consumables solution.
The XBox Live, though, in my experience, is a very closed program.
The answer is no, but it is also yes.
Consumables, specifically are not supported. That is any in-app purchase you can make again and again and again and again. They are not supported.
However, durables (that you can purchase one time) can be set to expire in a single day. Many developers have created multiple durables, allowed them to be purchased in a day, kept a central record of their purchase somewhere, and let them expire so the user can purchase them again tomorrow.
So, no, you cannot set consumables.
And, yes, you can set expiring durables and act like daily consumables.
Consumables (e.g. buy a pack of gold coins for your character in the game, and allow the user to buy that pack multiple times) are not directly supported for Windows Store apps (though the Windows Phone SDK has ProductLicense.IsConsumable), but there is a type of workaround that you may find helpful, depending on the specific scenario.
However, support for in-app purchases of multiple different products is relatively simple to implement, shown in this article and sample:
How to support in-app purchases
Trial app and in-app purchase sample
what are the must have functionalities for an e-commerce web shop?
e.g.
unlimited categories and sub categories
multiple categories per product
multiple product images
product consumer ratings and comments
payment gateway integration
delivery service integration
Best Sellers
Newest Products List
discount facilities
promotional facilities (buy one get one free)
I know we shouldn't just link to elsewhere, but this link is within stackoverflow. I'll just quote it all here:
Do you need to build one at all? Most of this has been done for you in
various shopping cart packages
including google checkout,
oscommerce, and others, but if
you must take the plunge try to at
least think about the following...
Secure session for users
Storing 'items' in the cart via the session / cookies
Payment processing
what external systems do you interface with
what kinds of payments do you accept
what currencies do you accept
Some kind of dispatching system for when a purchase occurs
If a purchase occurs, who is notified to mail out the items?
where is the purchase logged?
Interaction with an inventory system of some sort
is the item in stock?
what to do when out of stock?
Total / shipping calculations
how much do you charge shipping for different customers/destinations
where do you want to ship / where will you not ship
A shopping cart is far more complex a
concept than it appears to be. The
specific answer to these questions
will depend on what kind of
organization you are working for. Big
company? Small startup? Family
business? High volume vs low volume?
Etc.
I'm looking into building a web app that allows multiple e-commerce stores to coexist on the same installation and lets allows each individual vendor manage their own products, pricing, sales reports, etc. I know that there have been a number of previous questions on the Stack regarding the best shopping cart software, but this is a bit of an unusual twist and I couldn't find it answered elsewhere.
Obviously, open source is better from a pricing standpoint, but I've got no problem with spending money on a quality product that meets my needs. The ideal package would allow each store to be uniquely skinned, would minimize the amount of time that it takes to get a new store up and running, and would include payment gateway and shipping integration.
I've run across a few things in my scouring of the web, but haven't found "the one" yet--I know that osCommerce sort of supports what I'm trying to do, but I'm looking for something designed with this functionality in mind. Any ideas?
Thanks!
Justin
I am at present looking into the same thing. After looking at all the different cart on the market I have settled on PHP Mall 2. I have had demos of X-Cart Pro, iscripts multicart and a few others.
There were only 2 that were any good at handling payments direct from buyer to seller without any added costs of have a mod done for that. They were PHP Mall 2 and iScripts Multi cart. iScripts Multicart didn't really have alot happening in the backend, and vendor shops were really just an about us page with their products showing.
I settled for PHP Mall 2 becuase each vendor can have their own website as such and can customise it to the way they want it. They can choose from a number of templates for their shop.
The part I really like about it is the payments system, there are a number of payment gateways out of the box and the vendor can choose which ever he/she wants. (because not everyone use paypal right!). Its also a fair bit cheaper than all the others and provides alot more from a site admin and seller admin side of things.
I was tasked with looking into a multi vendor cart for a project that was canceled. Before it got canceled, I felt that the below were strong contenders. This is not a comprehensive list but it's somewhere to start. The requirement for multi vendor was paramount, so the listed have varying amounts of CMS/blogging etc; so they are not necessarily apples to apples.
I did get to try out magento community and using information found here http://www.magentocommerce.com/boards/viewthread/145/ got what I felt was the correct experience for multi store/vendor for my purposes. Mileage may vary depending on requirements. It's a beast though and for some reason comparison doesn't indicate the multi vendor capabilities. My impression was that Magento was definitely for the technically minded, with a very high degree of configurability available. It's a meta system for sure. The average joe business owner wouldn't stand a chance with it. However, it might be a perfect for resellers.
http://www.x-cart.com/mall_solution.html
http://www.php-shop-system.com/products/iq-cart-for-joomla-our-new-cart-component-for-joomla.html
http://www.magentocommerce.com/product/compare
I am also in search of a multi-store solution. Magento Commerce is too expensive. OpenCart now supports multi-shop but only a single user can manage the stores. I would have preferred setting up multiple stores and have different users manage each store.
I've also been undertaking research within this area and discovered the following options;
For joomla = http://www.ijoobi.com, IXXO
For Magento = http://www.unirgy.com, MVDE
There is also an interesting product called MultiCart from iScripts, and the X-Cart Pro from Qualiteam.