Does someone have a clue about how implementing pricing template from PlayStore through RevenuCat ?
I have a pricing template for an app on playStore.
I charge 3$ for US customer.
I charge 6€ for europe ones.
Is it handled automatically on revenuCat ?
Do we need to upgrade our RevenuCat account to access a premium feature handling this ?
And by analogy : How AB testing on pricing can be handled given the fact we use RevenuCAT ?
Related
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
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
This is the first time i am trying to create an application in which money in involved . I will give premium some features to user once he pays on the apple store.
I heard something about In App Purchase , that by implementing it we can take money form the users.
My major query is: What should be the best procedure to upgrade the application loaded with new features (like we get all powers in games.)?
Should we involve some kind of file download after money transaction or we she unhide it from existing application.
My concern is the best approach that should be applied ? If i am thinking in a wrong direction then please assist me with the correct path for this kind of scenario.
Thanks in advance.
In case of an 'upgrade' or 'unlock' based on an in-app purchase, it would be best to provide the complete application to the user and block the features while the app is in demo mode. So, you will have to check each time whether the app is 'upgraded' when the user attempts to use a premium feature.
Involving some download after the user makes the purchase will be tedious to implement, but this is also based on what you are trying to provide with the purchase.
Read up on in-app purchases here.
I'm building an app that will provide users with an evolving directory of companies in their local area (location-based) that manufacture green/sustainable products. I want companies to be able to add themselves to the app by purchasing a subscription using in-app purchase. This would be a 1 year subscription.
Just read this in the iOS Standard Agreement: 2.3 Content and services may be offered through the In-App Purchase API on a subscription basis (e.g., subscriptions to newspapers and magazines). Rentals of content, services or functionality through the In-App Purchase API are not allowed (e.g., use of particular content may not be restricted to a pre-determined, limited period of time).
If the service is only for a year, does this preclude me from doing the above? Anybody have any insight on any of this? I'd appreciate your input - I can't get any info from Apple. Thanks.
My guess is that you are not allowed to do that. As you really cannot restrict who subscribes for a year – it might be any user – you probably cannot offer this. The IAP doesn't provide any content or service to the user other that a listing. As you probably need an external data source (e.g. a web application) I would suggest moving the subscription there. This is just my opinion and I am no lawyer so I might be completely wrong here.
You can do it. See the image below. You just have to choose the right option.
You can find it itunesConnect in the app detail section.
For your case I suggest Consumable is appropriate and have to maintain a check that wether its been a year or not since the last magazine purchase or what so ever your scenario is.
My team and I are going to write an app for an organisation where the user can donate to this organisation. The app itself is not the problem, but we don't really know how we can handle this.
Our first thought was that we could make the donations like if you purchase an item in a game for real money. But there are 2 problems:
There are only fixed amounts like 99c and so on
Apple gets 30%, and we want the user to know who gets how much. The developers: 10%, The Organisation 90%. But if Apple gets 30% of ALL the money, and people see that, they may not donate for that reason. I wouldn't either.
Our second thought was that we implement a webthingy (don't know how the element is called atm) in our app, which simply works like Safari and we direct them to the donation page or something, but how does the organisation know that the donations are from our app then?
Is there any other way we can handle this? I think people will be able to donate via credit cards and PayPal.
Edit, I found this:
21.1 Apps that include the ability to make donations to recognized charitable organizations must be free
21.2 The collection of donations must be done via a web site in Safari or an SMS
The app will be free, and it is fine if it has to be via SMS or Safari, but HOW does the organisation know the donations coming in, are from the app?
Update:
US non-profits can accept donations via Apple Pay:
Starting November 14, 2016, nonprofits based in the United States can use Apple Pay to provide a simple and secure way to accept donations from within their app and website. Similar to using Apple Pay to buy goods and services, users can donate without entering their billing, shipping, or contact details.
The App Store guidelines go on to say:
Acceptable
...
Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.
Unacceptable
...
Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
My old answer, below, predated this revision in the charitable giving policy.
As you note, section 21 of the App Store Review Guidelines says:
21.Charities and contributions
21.1 Apps that include the ability to make donations to recognized charitable organizations must be free
21.2 The collection of donations must be done via a web site in Safari or an SMS
You ask how you know if they're from your app: For Safari use a unique URL or include a HTTP parameter that you append to the URL when you invoke Safari, which their web server code will capture. As other have suggested, you might want to log the initiation of the transaction for your own reconciliation purposes, too. For SMS, I assume you'd have a dedicated SMS number for app donations.
But HOW does the organisation know the donations coming in, are from the app?
Make a new page on the organization's site that has a URL that isn't linked to anywhere and non-indexable by search engines (robots.txt).
In your app, make a UIWebView set to a URL on your own servers that redirects to the page you make in step 1. You should also make this URL non-indexable.
In that page
Check that the referrer is your page
Check that the user agent is whatever UIWebView sends
Have the page log whatever happens somewhere (date/time, donation amount, etc) -- to reconcile with their data
When a successful donation is made, it should record that it came from this page (and therefore, your app)
Someone could fake that they used your app by making the appropriate request, but why would they. Even if they did, you should probably get credit for that donation anyway.
You can't use IAP for any virtual good that are not consumed in the app as far as I know, apple will reject your app if you try it. (However i've seem some exceptions to that)
try www.stripe.com, they have the best payment interface i've seem so far.
someone even made an iOS SDK to help you with the implementation https://github.com/briancollins/stripe-ios
I don't believe Apple will allow you to use in-app purchases to accept donations. Marco looked into this with his Instapaper app and couldn't do it (now he charges for server searches). You actually have to provide something for the money. Your best bet is to develop a web app that uses a private api to process the donation. That way you can know for certain where the donations are coming from.
Ah, nevermind, you can accept donation on a free app. Missed that. Still, using a private api in a web app is probably your best bet.
From April 2020 you cannot donate inside the app. Apple teams say you can't donate inside the IOS app if you are a nonprofit organization. you must redirect the user to Safari or on your website for donation or using SMS for donation.
Otherwise, You can use Apple Pay for donation like in App Purchase if you are profit Organization
soo if you are a nonprofit organization and you want to donate, please follow these steps.
I am using Flutterwave SKD for donation. You can use as you want like Stripe and PayPal etc.
1: I am using the Flutterwave Php SDK for donation. just download the PHP SDK of your payment gateway from your Payment gateway DOC.
2: create a webpage for payment on your web end and from your app open this webpage into Safari, And pass user ID with URL parameter so you can keep the record of which user donate us and how much.
like (PageWebUrl/userID) (https://www.mywebPageLink.com/donation/userId=20)
3: When a user successfully donates save the data into that user-id and redirect the user to your app.
4: call an API to retrieve the donation data for your app.
Coooool Done...