Is the following feature possible and if so, how?
I'm planning to build a sports organiser phone app and I'd like to include a payments feature.
Some users will be the Organiser (admin) and they would need to collect money for games from other users, the Players. Each Player would have an outstanding balance, the platform would send reminder messages and effectively eliminate the need for manual work (and stress) for the Organiser.
Ideally, Player users would not need to enter any details about the payment recipient, as they would be pre-configured by the Organiser, for a quick and easy process.
Would, for example, something like PayPal be appropriate? Or something else?
Your insight would be appreciated.
Related
Is there any way to transfer money in between iTune Accounts within my application, actually I want to develop such app that is capable to do so,
so can anyone help me, or guide with with some proper references?
iTunes is a black hole, it will only take your money, not give it away. Transfering anything through black hole is little bit risky.
If you want to transfer money between two different users (and using app)
Register users to your service
Create a mobile site where the payment page is and open this page from within the app - Apple will probably ban your application otherwise as it is really jealous about any non-iTunes payment
Allow user to choose who will receive the money (friends list?)
Transfer money using PayPal. For PayPal money receivements, having an email address is enough.
Also check Apple Terms of Service for apps - they probably have some kind of clauses which would limit this type of applications.
If you want to get the Money out of Itunes,
i believe you could use this trick (hypotetic):
You create a fictive In-App purchasement via the Itunes-API for e.g 5€,
I-Tunes will take e.g 1€ and you as the developer will get 4€ transfered to e.g to your PayPal Account minus eg 0,50€ Paypal-Dues.
So now You as the developer will have 3,50 € at your Paypal.
Now you can Transfer this to the Appuser and he will get eg 3,00 € because of the Paypal-Dues.
In an app that is free, but has in-app subscription purchases I would like to allow a user with a paid subscription to receive x number of free months on top of the paid subscription if he refers someone that purchases a subscription.
For this to work it would have to be possible to track some sort of unique token through the Apple App Store in order to reliably assign credits.
To "Refer a friend" the app would allow the user to send an email to one or more people. This email would contain a link to the app store that also contains a unique key that I would generate to track the lead.
Is this possible?
Our app just got rejected yesterday regarding this kind of functionality.
We had an application which includes yearly subscriptions to access premium features. We also had a way for users to refer 5 friends to get a free access for life to our services. Apple rejected the app stating that this was against their rules for IAP.
Specifically, they referred us to the section 11.1 of the guideline which states :
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
Unfortunately, apple doesn't offer that functionality. One option is to offer 2 different subscriptions - paid and free.
Hide the free subscription portal until they refer someone - then allow them to see the free subscription option.
A couple problems:
The user will have to manually cancel auto-renew on their current paid subscription and then manually sign up for the free subscription.
I don't think you will be able to disable auto-renew on the free subscription option, so it would probably end up being permanent.
You could skip the free subscription official IAP and just make your own time-limited "back door" letting the customer continue downloading subscription content without verifying their App Store receipt. This would still have problem (1) above with the customer needing to manually cancel their auto-renew and then repurchase the subscription when their free time runs out.
My gut tells me this is going to be REALLY hard to pull off in a satisfactory way.
It would be much easier to reward one-time exclusive content for referrals. E.g. Give X for the first, Y after 5 referrals, Z after 10 referrals, etc. This is actually an easier value proposition to present to the users too; make a nice icon or something with an "Invite Friends to Unlock!" call to action.
I'm considering posting an app to the iphone app store, but I'm curious before I start paying them for the priviledge of posting the app, whether they provide instant payment notification to a url?
Generally, I've used paypal in the past for applications where right after payment my web site is secretly notified of a purchase. I take this notification, with the users email address and product purchased, to send the purchaser information required for the application.
Is this possible with apple? With the iphone app store? What about the upcoming mac store?
thx
No. Apple handles all contact with the customer, including delivery of the app. At the end of each day, week and month they give you summaries of sales of each product in each country. It's nothing like selling with PayPal. The iOS and Mac App Store are exactly the same in this regard.
The nearest you can get is having your app connect to your server when it first runs, although if you're doing this for no other reason than to track your users, you'll have to check it's allowed under the developer agreement.
First, no, you do not receive instant notification. You can grab a daily report on the web the following early morning (in the US), you can use the free app that Apple provides to retrieve the information, or you can use a variety of third-party tools to do the same.
Second, you will never receive any information whatsoever about the people who buy your app, so no, you can't send purchasers anything.
The Mac App Store appears to use the exact same arrangements.
If you use in-app purchase, you can get an instant notification to your server for the in-app purchase, but not for the initial download of the app.
If you just place a paid app in Apple's App store, you get no direct sales or customer information of any kind, only after-the-fact daily and weekly sales trend estimates, and monthly sales reports a few weeks later. Then Apple then pays you 70% of what they reported up to 45 days after the monthly close. You don't pay them. They pay you. And with over 300K apps in their store, and no other store doing anywhere near as well, they need no privileges granted from any developer. It's more like take it or leave it.
We have developed an application that allows a user to download audio content. The use of application itself is free, but we charge for the content. In our current business model, we accept payments using premium-rated SMS (which increases the in-app user's balance), however, Apple rejects the app since they do not allow this model for their applications.
Is there any other way (except In App Purchase API) we can accept the payments with?
Apple will only accept in-app purchases for this type of business model. Even then, you still have to submit each and every "in-app update" for approval at least a week prior.
Like Liam said, they want their piece of the pie too and they also don't want people slipping something past them (for instance, highly offensive content, pornography, etc.)
Per Apple:
You can create In App Purchases on both Free and Paid applications. Every product you want to offer in your store must first be registered with the App Store through iTunes Connect. When you register a product, you provide a name, description, and pricing for your product, as well as other metadata used by the App Store and your application.
There's no other way with this type of business model. More info here around page 116
Another option would be offering the same service via an ordinary website and then offer the app to allow users accessing their existing accounts. Take dropbox as an example - they offer paid memberships which you purchase on their website. The dropbox app itself is free but lets you access your dropbox account, for which you paid elsewhere.
In your case maybe you could offer "credits" for purchase (payable by premium-rated SMS) on your services website which the user could then spend by accessing his account from within the app.
This is less "direct" (requires the user to visit your website to pay for the content he will download later) and I wouldn't even bet on apple's approval (if the website appears to be merely a place for buying credits without further functionality, they'll propably reject the app too for circumventing in-app purchase), but then again, there are (propably) no alternatives. However, I'd talk with apple about this option before implementing it, to avoid wasting time and money. After all, in-app purchase is the way apple wants people to go if they want to spontaneously purchase content using only their device, so they'll defend it.
The easiest was to look at this is to work out why they refused the application, which is because it is not in their interest. You are selling a product to their customer and they are not getting any commission. In order for them to accept the app I would imagine that you will need to provide an in app purchase mechanism, but you could do this in addition to the Premium SMS as long as the app doesn't send the message
Is there a programatical way in which an In App purchase is refunded back to the user?
I have an application with a certain buyable feature. The user buys it but somehow doesnt like it. Is there any programatical way in which I can make the user get back his spent money?
I don't think it is possible. This is the same as with buying an app from the AppStore - you cannot say that you did not like the app, return it and get your money back. This is one of the reason why there are free lite versions of some apps. This allows users to check the app for free before they buy it. Maybe you could use the same mechanism in your app? Give some content for free and if the users see that it is what the need they could buy more of it.
No. The user will need to contact Apple Customer Services who will then decide whether or not to issue a refund. The refund will be taken from your apps earnings, I believe.