Is there any way to implement conditional logic for payments in Swift? For example:
Say the user has agreed to have 10$ withdrawn from his bank account he connected to his app account if, on a specific day, he has not fulfilled a condition that can be tracked with the app.
If he fulfills the condition until 23:59, no money will be withdrawn. If he doesn't, at 00:00 on the next day, the 10$ are automatically withdrawn from his bank account.
I don't know of any app that does this and I'm not even sure whether an app like this would be permitted on the app store. I'm not even sure whether that's technically possible.
Would be thankful for any helpful input!
Using the in-app payments system (a.k.a. iOS in-app purchases which utilise the StoreKit2 or StoreKit API) this not feasible.
Explaining how in-app purchases work would be a bit tedious.
However, to put it simply, you can basically initiate either a one-time payment request, or a recurring payment request.
In each of these scenarios, the user may obviously either make the payment or decline, about which you would get updated in code.
The closest the system comes to what you are asking for is recurring payments (technically called the auto-renewable subscriptions).
However there is no way to ask Apple to conditionally deduct money based on whether the user has performed some action or not.
I'm pretty sure you should not be looking at the iOS in-app purchase system as a way to do what your are looking for.
You could use 3rd-party payments.
However, whether Apple allows this, would depend on what kind of condition you expect the user to fulfil. If it relates to a real world service or material, then you may be able to justify it to Apple, however, if it is a digital service, lets say an app based activity, such as opening the app a given number or times, or viewing the app for a given amount of time, then I'm pretty sure this would be in violation of the Apple App Store Guidelines and they would reject your app when you submit it for review.
To be honest without understanding the use-case a little more clearly it is a bit difficult to advise you on the technical feasibility.
Related
I am wondering whether to implement in-app purchase refunds (in case a user refunds). None of the in-app purchase tutorials seem to show how to do it, so I am wondering if that is for a particular reason.
By the way, the in-app purchase is a non-consumable (PRO version).
A big problem I can see with refunds for example, is that you shouldn't remove the PRO features if they don't have connection, but then someone can just use no connection with the app to never get PRO revoke.
My question is: Is there a seamless way to integrate refunds for non-consumables, and do many other apps handle refunds or not?
Thanks.
I believe the only way for a user to get a refund is to request it from Apple. If granted, the onus is on you to determine this condition. You will have to check receipts actively.
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-RECEIPT-HOW_DO_I_USE_THE_CANCELLATION_DATE_FIELD_
This states:
The Cancellation Date (cancellation_date) field is designed for use
with auto-renewable subscription, non-consumable and non-renewing
subscription products. This field is set when a customer contacts
Apple customer support for a refund and the transaction is canceled.
Depending on if your app has a backend or not will dictate a strategy to handle this. If you have a backend, a good method is to periodically check for receipt status (at some time interval of your liking). Note that if you have a large user base, you probably want to divide up the user pool piecewise to do this type of check.
If you don't have this as your option, then you need to make your app make this check.
Or ... you accept that this will happen. I've done work for a company that had a large subscription base and they never ran that check for cancellation/refund (I let them know about that weakness in the system).
OK I'm working on a app where the user purchases the app from the App Store, gets access to the app for a year, and then after the year has passed they are sent to an In-App Purchase screen where they can purchase a subscription for continued access.
(this is not the subscription model I'd implement if it were up to me, but the client insists that it follow this model)
In order for it to work, though, I need a reliable way to check when the app was purchased, in order to calculate when the first year of access ends. Following the suggestions in one of the answers in...
iOS App Purchase Date
...I've gotten the app receipt and I can find all the data fields that the documentation says there are, but there are also a few others including "original_purchase_date" (not the one in the IAP receipt array; the one for the app receipt itself). This would appear to be what I want. However this field is undocumented.
As far as I can tell, Apple security operates via a form of "Security Through Obscurity/Diversity", so it's been difficult to find further information about these undocumented data fields. My concern is that I might use the data from this field, and then discover that it was only there in sandbox mode and actual receipts don't have it. Worse, what if I reference that field and then Apple releases a new iOS update that completely discards that field from its implementation? Undocumented features are even less reliable than deprecated features, after all.
My question is this: is there a reliable source of information somewhere where I can find out what Apples intends regarding this field? Or better yet, is there another, safer way of achieving the system my client wants?
You have to implement it as a free app that requires a subscription IAP. Paying for an app cannot be its subscription cost.
Check rule 11.12 here: https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
Apps offering subscriptions must do so using IAP, Apple will share the
same 70/30 revenue split with developers for these purchases, as set
forth in the Program License Agreement
Implementing it the way your client wants will result in rejection.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
I am developing an app for a client, where he wishes the app to be able to have users to sign up and try out the app for 14 days, after which they have to make a purchase to continue using the app.
My client does not want to absorb Apple's 30% cut for using Apple's in-app purchase mechanism. Initially I suggested implementing a 3rd party payment gateway, but it seems that Apple does not allow app that unlocks app functionalities via a 3rd party payment gateway.
My question is this: if we submit the app that allows users to sign up and login, but only use the app for 14 days without any form of payment mechanisms in the app to allow the user to continue using the app, will the app be rejected? As I was thinking to just have the payment gateway on a website, and during user sign-up, send the user an email informing them that they can go to the website to make a payment.
I know that Apple rejects trial/demo apps, but this is technically a full fledged app where users that purchased via the website will be able to login and perform full functionality. I will also provide Apple with a test account that is fully functional.
Thanks!
Short answer: Apple will reject you if you allow signups and block functionality after a trial period without allowing IAP. Period.
I have first hand knowledge of this, shameless plug in 3..2..1.., Simple In/Out offers a 45 day free trial, after which users are blocked from using the app. In the early days, we escaped Apple's ban hammer by being small and using a blessed trial account that never expired. Apple would review using test account, never see rejection or blocked alerts and prompts to sign up on our website. That did change one day after requesting an expedited review. We got a lot more scrutiny and they rejected us for essentially steering users to our website for subscribing.
The IAP for trials and subscriptions other than magazines is pretty terrible. It is essentially designed for magazines, and that's it. So beware going in. What we eventually did was allow users to subscribe in the app using IAP. Our server manages who is subscribed and who isn't. It also manages which subscription they have (IAP or our own). There is a lot of weird receipt checks you need to do to manage the subscription from Apple. The user is also stuck if they want to change to a bigger/lower subscription plan. Which kinda works for us because the only way to do it is email us, in which we can convert from IAP (-30%) to our own (-2.5% for card processing).
The moral of this story is that if you plan on allowing users to create accounts inside your app, then you will most likely be obligated to offer subscriptions via IAP. If you want to avoid IAP, then you will also need to strip any references to your website from your app and description. They will bust you on meta if you try and steer them around the IAP process. Once we added IAP, we were allowed to point everyone to our website for "more information" in which we are able to convert more users to our own subscription rather than IAP. Right now, our number of our own subscribers vs. Apple is about 75:1. So we don't lose much over the signups we get from Apple.
I believe this should be perfectly fine as long as the 14 day "trial" is a fully functional version of the app.
Your model seems similar to Spotify. Pay for subscription on their website, but use the service in the app.
These resources may help:
https://news.layervault.com/stories/9695-how-do-apps-like-lyft-uber-airbnb-skirt-apples-30-cut-on-each-transaction
http://www.quora.com/How-does-Apple-define-digital-content-when-taking-its-30-cut
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.