I am developing an music application that charges user per songs are played. I have an a registration functionality that helps user to sign up and register their card with some files: name or card, card number, expire date etc.
I am concerning if getting card info will be rejected by Apple. My assumption is the songs I buy are approved by Apple.
I am really appreciated with any suggestions.
In order to handle branded credit cards from the major card schemes (Including Visa, MasterCard, American Express, Discover, and JCB) your system/backend should be PCI DSS compliance (The Payment Card Industry Data Security Standard), Which is a proprietary information security standard to ensure security of the stored/transmitted card information over the open network. Of course Apple will reject your app if you are not PCI compliance. This is an expensive process and it needs constant supervision and maintenance of the backend server. Still if you wish to handle your customers' cards by yourself, Get started from here.
There are few workarounds. You can simply use third party service providers such as Paypal or Zooz payments instead of handling customer card information by your own.
Also you can go for Apple in-app purchase which is the native mechanism/framework for payments handling. Infact i recommend to go with Apple in-app purchase so you don't have to worry about any card information handling and there is really less work to implement.
All the above payment options i mentioned here are supporting Subscriptions, One time payments, etc...
Related
I am using Algorand blockchain for NFT transaction on mobile app. The app is in react native and on the app I am selling/buying NFT's. Apple rejected my app saying that I need to implement in-app purchases. How would I go about doing that?
How to implement a cryptocurrency payment gateway? Does apple's in-app purchases support cryptocurrency payments?
I can't find any helpful resource to resolve this issue.
Apple's in-app purchases do not support cryptocurrency payments.
However, they do support cryptocurrency cards that are linked to Apple Pay. Lots of these exist, e.g. Coinbase. There are also rumours that AlgoFi may release one too.
The payment is converted into fiat before the transaction, so on your app it would be like handling a fiat payment. You can then theoretically use this fiat to buy $ALGO, and then use that for the transaction. The UX would ultimately look the same for the end user and it would seem like they are using the existing cryptocurrency in their wallet. But like a commenter said this is not reliable.
Apple does not allow apps that have any payments outside of their payment system. This means that currently an app cannot write to the blockchain at ALL unless payments and gas are relayed. You can work around this by developing an NFT marketplace app that allows users to view their NFTs and explore others, but if they want to do any transactions they are redirected to the mobile website.
So you have three options: trusting that the fiat is successfully taken out of the user's account and buying $ALGO, waiting for the payment to go through which means the transaction may take weeks, or directing to a website for all blockchain transactions.
In one of our application, we are going to introduce digital content purchase mechanism with crypto currency. So here are my doubts:
1) Is it durable and achievable?
2) If yes, is Apple going to allow this kind of implementation and accept it to iTunes?.
The criteria is 'if goods cannot be used in the app'. Only then you can use a system other than IAP (including a system like Crypto Currency)
Digital Goods which are ment to be used within the App must be purchased trough In-App Purchase. If you use any other mechanism, then your app will be rejected.
From the official docs
If you want to unlock features or functionality within your app, (by
way of example: subscriptions, in-game currencies, game levels, access
to premium content, or unlocking a full version), you must use in-app
purchase. Apps may not use their own mechanisms to unlock content or
functionality, such as license keys, augmented reality markers, QR
codes, etc. Apps and their metadata may not include buttons, external
links, or other calls to action that direct customers to purchasing
mechanisms other than in-app purchase
Someone has asked similar question on Apple Thread also. have a look at the following thread
Answer on the second question: if you want to implement some kind of purchases in your app you also should follow items from the review guidelines:
From the official docs:
3.1.5 (a) Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.
3.1.5 (b) Cryptocurrencies:
Initial Coin Offerings: Apps facilitating Initial Coin Offerings (“ICOs”), cryptocurrency futures trading, and other crypto-securities or quasi-securities trading must come from established banks, securities firms, futures commission merchants (“FCM”), or other approved financial institutions and must comply with all applicable law.
I have this problem. I'm making an iOS application in Swift that sells user images and videos. I've got my own server, so all media is saved there. But now I've come to a point where I need make possible that user can buy some content from another user using a credit card or PayPal account. Other users can be found on a map, they have added their payment information to their profile (it's not visible to others) so that transactions could be made.
I've done some research on this topic and I know that a powerful tool for payments in Swift is Stripe. However, as far as I read about it, users can only pay to one account that you register. Basically, they can make purchases as if buying from a store. But in my case, I need to provide the possibility to pay to another user.
Also, I need to integrate PayPal. For this I found API's like Auth0 and PayPal API, but can't seem to find any more information on inter-user transactions.
And there is In-App Purchases option, of course, but I'm not sure if I can use that in this case, because most of my purchases will be done from a Web App.
Can somebody please help me, by giving some tips on how to move forward from here and implement this payment system?
There are several considerations to take into account, the three most important being price, ease of implementation and availability. I'll briefly discuss each point of the 3 options you mentioned:
Stripe:
Implementation: Stripe has a native SDK for iOS and has a functionality called Stripe Connect which enables payment between users directly, without having the money to go through your account, yet allows you to take a cut of the transaction if you'd like:
https://support.stripe.com/questions/can-i-enable-my-users-to-receive-payments-from-others
https://stripe.com/docs/connect
Price: Stripe has a starting fee of 0.3$ and takes 2.9 % of the full amount.
Availability: Currently Stripe is only available in 9 countries worldwide and available as a beta in another 15 countries:
https://stripe.com/global
PayPal:
Implementation: PayPal has a native SDK for iOS, but a very fractioned history of SDK libraries depending on how complex functionality you need (Which Pryo's answer underlined). Paypal has something called Adaptive Payments which allows for peer-to-peer payments:
https://developer.paypal.com/docs/classic/products/adaptive-payments/
Price: PayPal has a lot of mixed information about pricing (currency conversion, cross border transfer, etc.), but roughly it is a starting fee of 0.3$ and another 3.9 %.
Availability: PayPal is available in 203 countries/markets around the world:
https://www.paypal.com/webapps/mpp/country-worldwide
In-App Purchase:
Implementation: This money will always go directly to the developer, so this means you will need to implement some sort of service which takes money from your account to the final user. So the flow goes: buyer -> you -> receiver.
Price: Apple will take 30 % of the total amount.
Availability: In-App Purchase is available in every country where you would be able to distribute the iOS app.
Conclusion:
Don't use the In-App Purchase option for user-to-user sales, it's simply too complex and expensive out of the three options.
PayPal has a strong brand that people trust and is available in many countries, which makes it a stronger candidate than Stripe, but IMHO I would choose Stripe due to its simplicity and cheaper pricing.
If you want to implement in the swift Paypal has already SDK, which you can use to make between users to make simple payment:
https://github.com/paypal/PayPal-iOS-SDK
or if you need some more advanced feature like (third-party, parallel, and chained payments ) you can check old MPL library by Paypal:
https://github.com/paypal/sdk-packages/tree/gh-pages/MPL
For the In-App Purchases payment can be made by valid app store user only and there is mostly no facility of inter-user in general case in-app payments are made to app owner
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.
My iOS app got rejected because we charge users with Stripe's payment service, and Apple requires us to use IAPs for payments.
We deleted the Stripe reload balance module from the app. Now the only way to recharge it is for the user to go to the website and make the payment. Does this solution work or does the app still have to use IAPs?
Apple has explicitly requested any submission to go through their iAP for any payment. Your rejection is expected and normal. You have two choices, asking a user to pay through iAP or accept the payment on your website. Both works, but you can't and can't explicitly ask your user to pay you directly.
Let's take Dropbox as an example. You can upgrade Dropbox account on their website. It works. But Dropbox isn't allowed to encourage you to do the upgrade in the app itself (unless the payment goes through Apple). That is, you can't do something like a button in the app that takes you to the payment form on your website. If a user knows how and where to do it on the Dropbox website without being told to do in the app, good, Apple doesn't take that 30% commission.
Unless your service is popular, most users wouldn't be bothered to goto your website and give you their credit card number for a purchase. You should consider just giving the 30% commission to Apple, you'll get more sales.
You are required by Apple to use IAP, and can only use IAP, if you are using the purchase to unlock code in the app. You may use other payment systems only if you are selling real world goods and services or, in certain circumstances, files that are being downloaded from your servers. If you use other payment systems they must be used outside of the app. This is explained in the app review guidelines, section 11.
Note that requiring the use of IAP for sales of code distributed by Apple may not be an issue under anti-trust laws. But in any event, if the "market" is smartphones then Apple is not a monopoly player since their market share is limited.