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
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 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.
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
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.
My app needs the ability to pay different merchants, so essentially I'm acting as a middle man. A user would fill up their cart from one merchant and then I'd present them the whole paypal interface and then that particular merchant would get paid. So first question: is that possible? Or is it only possible for MY account to get paid? If I had 10 merchants, I'd like to directly send them the payment amount (and have them pay the transaction fees).
The other question is discounts. Say a merchant creates a discount of some kind, is it possible with the mobile SDKs to apply these discounts?
My app is for iOS at first but will be quickly followed by an Android and then a web version of it. I don't really care which SDK I use so long as it can meet all my feature needs.
If none of this is possible with any of the SDKs, are there any out there that might accomplish what I need? Thanks.
It sounds like you're describing chained payments. You can utilize chained payments by integrating with classic MPL. The new Mobile SDKs will support these kinds of payments in the future, so keep on the look out!