So I’m creating an app for a guy who runs a local auction (a mini ebay meets craigslist if you will, but for more in person transactions). I’m doing it as a favor, but to also build my portfolio, so hey we both get something out of it. Now I’m running into a bit of a thinker on the “payment system”. The idea we came up with is when a seller completes the transaction, and confirms the sale, the money is held “by a middle man” until the buyer confirms the item (kind of like how Pay pal can release funds early if the buyer of an ebay item says it’s a good sale).
The client wants it set up this way so that he doesn’t miss out on his cut (10% of the sale)– as in I buy an item, meet the seller in person, then we just do an exchange there having used the app as more of a means to meet. I know Uber charges your card automatically upon GPS once you reach your destination, but it would be better to pull up the “buyer” portion of the app to confirm the sale, thus moving it from the middle man to the seller.
Aside from ensuring the client gets his cut, this can also build confidence that the “sale is funded” when the buyer is on their way.
Anyway, are there API’s out there that can help be build something like this for speedy transactions?
Not sure if this helps, but we will be using Parse as the back end.
Thanks!
There are several payment APIs for the iOS, and I can recommend Stripe which has everything you need. They have an excellent support and documentation for integrating with iOS. You can check the documentation here. Also it works really well with Apple Pay and it's implementation is no brainer.
Related
BACKGROUND
I'm helping a 3rd party host 3 apps that they paid me to write (they've given me access to their Apple credentials - created expressly for this app - in order to manage the iTunesConnect process).
Because of this, I get access to all of the sales data, etc. through iTunesConnect. We currently have all 3 apps released, two of which are first-time releases and one of which has been on the store for a few months and updated a couple of times. The first app was initially released with a $1.99 price point as an introductory price, which went up to $3.99 after about a month.
ACTUAL QUESTION
I just got my daily report from AppFigures.com (highly recommended, by the way; it's a relatively cheap way to get a good amount of automated data and analytics about app sales), and I noticed that app #1 had 3 refunds yesterday. We've only had 7 refunds ever, and all 3 of these refunds were originally purchased at the $1.99 price point. Therefore, this has made me very curious as to why they got the refund NOW. We had bugs earlier on that have subsequently been resolved by updates, so I don't understand why someone would have a legitimate reason to ask for and receive a refund at this point.
Please note: I'm fully aware that I'll never get the information to tie back directly to the user. I understand why, but it's a bit of a shame (and it's why we included a voluntary contact/feedback mechanism in the app itself). I'm just wondering if I can see from Apple the reason they selected for requesting the refund.
Basically, I'd like to answer the following question:
"Why did Apple think it was justified to refund this user's money?"
I'm guessing it would be a helpful piece of information for us; if there's something wrong with the app and we're not aware, this could help us fix it. Does anybody know how/if that information is available?
I did what Injuanj suggested and contacted Apple directly.
Here's their (completely unhelpful) response:
Thank you for contacting us about your Sales and Trends reports.
I understand that you are wanting more information regarding refunds.
You can find Refund information for your content by filtering your Top
Content dashboard to Transaction Type > Refund. Refunds will be
indicated as negative values.
Apple does not provide customer or refund information at this time.
If you have further questions regarding your sales reports, please let
us know. We're happy to help.
Best regards,
Julie
iTunes Provider Support
I already knew how to view my refund/return count, which is how I knew to send the email in the first place!
I didn't ask for customer information. I know Apple's not going to give that. Duh. I actually specified this in my original email.
I guess the real answer here is this:
Apple does not provide customer or refund information at this time.
I am building a webapp which requires users to regularly top up their account. To allow for this I am exploring the google wallet inapp payments api and have got this working fine. However, I would like users to be given the option to auto-top up when their account balance becomes low. I have looked at the subscription documentation but cannot see whether this is possible or not - it seems you can only have a subscription which draws money at regular intervals.
Is there a way to have a user pre-authorise this kind of transaction, and if so could you please point me to any documentation that would allow for this?
I don't believe so. The subscription feature is probably your best bet and should (unless I'm missing something) get you to the "same place".
A "pre-authorization" somewhat says, you'll come back at some later time to charge (aka "capture") the pre-auth. There is no API command that does that (capture/charge) in Wallet for Digital Goods. The process is immediate...
There (is) used to be one in the Google Checkout API where you are given 7 calendar days to charge a pre-auth. However, this product will be retired in November.
Consider following example. Let's say we have an app in which professional writers write stories from a web based UI. And then these stories become available for user of the iOS app as in app purchase items.
As you may know we need to create in app purchase products in advance. But in our situations it means that for each of the story created by the writers we will have to create a new IAP product and wait for Apple to approve it.
To circumvent this, I am planning to create generic "consumable" products in IAP like story worth $1.99, story worth $2.99, so on, so forth. Then in the Application UI I will show the list of stories of created by the writers and show corresponding prices for the stories as specified by the authors when they created the story. Once the user taps on the buy button, I will show the purchase for the generic consumable product of the same price and complete the in app purchase process.
Now the question is will Apple approve of such implementation? Does it fit with their IAP policy? I am asking as I couldn't find a guideline for a workflow such as this.
Another approach to implement this is by implementing an in app credit/currency system, like games use. Where people buy credits/coins and then they purchase items with coins. This is a tried and tested approach but it doesn't fit in my analogy of the app, hence the question.
What you want to achieve is perfectly feasible, the only thing is your purchasable content has to be dynamic. You will have to download the product IDs from a server rather than having them hardcoded in your app.
To refer to your example, I can imagine a table view being fed with a list of objects that would have the SKProduct ID stored on them. You would have to do this because, at the time of writing, you can't retrieve all the available product IDs for your app from Apple servers. I know it's a pain in the ass they didn't implement this feature but to be honest, if they haven't already I don't think they will ever do.
This is the method I'm referring to: initWithProductIdentifiers
You provide it with a NSSet with all the identifiers you want to retrieve, but if you provide an empty set or a nil, it doesn't reply with all the existing. You can file a bug with a Apple if you feel this doesn't work as it should. Please check this SO answer if you still have any doubts: link
Another important thing to note is, you will have to upload your products manually. Apple doesn't expose any API in order to have the process automated. This means, every time a writer uploaded something to your server, you would have to log in into iTunes connect and create a product. Plus, you would be limited to 10,000 products because that's the maximum amount of different products you can register with Apple. I'd also recommend you to have a quick read to the iTunes Connect guide, which has some important information like the one I just mentioned: iTunes Connect
Regarding 3rd party frameworks, like the aforementioned UrbanAirship, they will just save you from having to implement receipt validation on your servers. Apart from that, I don't see any major advantages.
Said this, I'd recommend you to reconsider your business model. Is it really worth it all the hassle of uploading the products one per one? Or is it better to go the subscription way, in which your users pay a fixed amount of money for downloading a number of articles per month. You could have different tiers, like, basic, premium (unlimited downloads) an so on and control the delivery of the articles from your servers. That's up to you, but for me the answer is pretty clear.
Pritam
For delivery dynamic content you should be using a Subscription, not a consumable. Using a subscription solves your problem by allowing you to charge for each update AND distribute new content at the same time.
You can looking into 3rd party services like UrbanAirship that will significantly reduce the amount of time you spend trying to dynamically deliver your content, track subscriptions and expirations, etc.
I have a very strait forward question (and yes I've looked though apple documentation to see if this has an answer but no luck... I may have accidentally missed it though)
Here's my plan:
The problem I've been trying to find a workaround for is that if the admin would ever want to add a product, he would have to log into iTunes connect to add it and also add it in a custom control panel. We, obviously, don't want to make him suffer that so I've been looking for a solution but I need you guys to tell me if it's allowed by apple. Basically I will take over most of the product handling on our servers and will only go to apple with the transactions. This means that apple will not have an in-app purchase set up for ALL the products... only one for each length of subscription (1 month, 3 month... etc) and a few consumable in-app purchases for the various prices of the issues/singles
Side note: I will be selling monthly issues that contain multiple singles for each day of the month. The user will be able to download a full month or a single day at a time if they like.
DEFINITION OF CONSUMABLE PURCHASE - products must be purchased each time the user needs that item. For example, one-time services are commonly implemented as consumable products.
So I will store all the information in our server about the products and if someone chooses to buy a single month's issue that was set to 4.99 (on our server, not apples) then the app will run the in-app purchase with apple that is listed for the 4.99 tier. Whenever a person opens the app for the first time, their app will send some information to our server and they will have a row set aside for them where all the information about their purchases will be recorded so that they can restore them if they switch over to another device.
If you guys think i'm safe in doing this, please let me know so that I can proceed. Also, if this method helps anyone, feel free to use it!
Thanks,
Matt
I think your restore process might be flawed. You talk about the app sending some information up to your server, but what is that information? There is no reliable way to uniquely identify a user across different devices.
If you want to continue on this path you'll want to make sure that your recovery and failover process is very solid. Try out every imaginable scenario. From an app store submission point of view, you'll want to consider a token/coin-based approach. Of course, Apple's guidelines are fairly loose and subject to change so it's always possible you'll get rejected, but tokens are certainly more solid than simply using the same generic in-app purchase.
In a token system, you would set up in-app purchases for different numbers of tokens that the user can purchase as a sort-of virtual currency only valid within your application. Then users can spend these tokens on any items that you dynamically create.
Server-side this means you'll need some way to store how many tokens a user currently has and a way to uniquely identify a user across devices, which is a fairly uncertain proposition. Instead of storing the number of tokens each user has, you could implement some sort of hashing algorithm that generates a hash from an in-app purchase receipt and then sends it up to your server. If the app crashes or the network dies after purchase but before sending your hashes up, next time they open the app you can recalculate all of the hashes, send 'em up, and if the server doesn't recognize a hash it just adds it to the database. Then if a user wants to restore their purchases you simply recalculate the hashes on the device using the in-app purchase receipts you'll receive and then send them up to your server and ask the server to figure out for each of those hashes, how many tokens the user has left. You could think of it like a gift card system, where each hash is one gift card.
Again, app store rules change and if apple thinks you're trying to game the system and not provide a useful experience they have the right to reject you. It could be worthwhile to open a Developer Technical Support request and see if an apple engineer can provide you with a better solution or tell you if the reviewers are likely to accept your application.
So I know that there are no promo codes for in-app-purchases in iOS. What I am wondering, is will Apple reject this mechanism:
Provide two in-app purchases, one at full price, say $9.99 and one at discount price say $7.99 (for the same thing)
When you click on the $7.99 one, you are first asked to input a coupon code to be allowed to use the discount price. This discount code would have been found elsewhere - bloggers giving it away, coupon sites, etc.
Thoughts?
I believe your proposed method would work because a) you are not linking to an outside site to purchase the product (i.e., you are still using the App Store iAP method) and b) there are other programs that use similar features (e.g., entering in your OpenFeint username to enable that service).
Good luck!
I really think only Apple can tell but it is a good chance that it is okay.
I sometimes just went ahead and called them and often I was lucky and had a real competent guy on the phone telling me answers to stuff like that right away sometimes I had someone more cautious but pointing me into the right direction within the legal contracts. And whatever they said at the end the very much shielded app approval team (no phone numbers, no e-mail addresses) will decide. The worst that can happen is that you have to resubmit your app without it. Costs you time but no more.
I always used this link for phone numbers I think they still work.
I had same problem... so I called to the apple developer IAP helpdesk and they redirect me to email the App Store Review section.
Next day they wrote me:
We understand that you would like clarification about a business model you are developing for your app.
We are unable to provide pre-approval or guidance on app ideas or concepts. After you have submitted your app, we will provide feedback during the review process, if applicable.
So I wish you luck... There is no one clear option 😔