I have a question related to an application I am currently developing.
I don't know if should use in app purchases or not.
The idea is that currently you can transfer money from a user to another just like Revolut does. For this you pay let's say $1 per transfer.
Beside this, the application makes queries every 6 months to get some info from a financial institution and each query is paid by me as the API is payment per request.
Now, if I want to have some plans in the application like free and premium and for premium let's say you can do free transfers between users (just like Revolut) and have a monthly query to the financial institution, do I need to use Apple's IAP and pay a 30% tax for each subscription or can I use a 3rd party payment gateway?
I really couldn't find any response on this on the guidelines and I am trying to figure out how Revolut for example can use their payment method in order to purchase plans ?!
Thanks!
For this you need to add apple's IAP only. You can just use payment gateways for taking direct payments from the client. For adding subscriptions you need to use IAP only.
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.
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
In my application, I want to take an order of food, drinks, etc (For Ex. Restaurant app) and deliver or serve them. My applications into I want to generate “CREDITS” using through payment. For Ex, 10$ = 100 credits. Using these credits, I want to accept food orders using through CREDITS (User give payment using CREDITS instead of MONEY).
So, above scenario, As per my knowledge IN APP PURCHASE (IAP) will not be use in app because physical goods are not selling using through IAP.
Another option is Apple Pay, but it is not release universally and limited for some brand. So, this is not an issue.
So, Can I use other payment gateways like PayPal, etc? Please let us know your prior experience or comments. Thanks in Advance.
Yes, you can use PayPal or any other online payment solution.
From my previous experience you can only use IAP if it's a digital goods that will be used within the app, and you're not allowed to use IAP for physical goods (and you can use whatever your heart desires).
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 doing an iphone application which involves payment mechanism when all the time user joining in a group.
For example: I am registered user .i can create a community ,and i can join in a community.To create and join i need to pay some money.
So,What is the best of doing payment in this scenario.
can i go for in-app purchase which apple provide? or can i go for any payment integrations methods like paypal sdk?
Which is the suitable process for doing payment every time to buy a product or to join in a community?
Here its not a feature i am buying once.it is like product i can buy many times.
I am in a way of searching for the solution.hope i can get here.
Thank you.
Refer to Section 11 of the following document (Apple's guidelines for app review)
https://developer.apple.com/appstore/resources/approval/guidelines.html
You can sell physical goods using Paypal, Stripe etc. which provide iOS SDKs to integrate payments within your app. But for selling in-app content/subscriptions, you must use Apple's In-app purchase in which case you'll have to share 30% of your revenue with Apple.