I am building a webapp which requires users to regularly top up their account. To allow for this I am exploring the google wallet inapp payments api and have got this working fine. However, I would like users to be given the option to auto-top up when their account balance becomes low. I have looked at the subscription documentation but cannot see whether this is possible or not - it seems you can only have a subscription which draws money at regular intervals.
Is there a way to have a user pre-authorise this kind of transaction, and if so could you please point me to any documentation that would allow for this?
I don't believe so. The subscription feature is probably your best bet and should (unless I'm missing something) get you to the "same place".
A "pre-authorization" somewhat says, you'll come back at some later time to charge (aka "capture") the pre-auth. There is no API command that does that (capture/charge) in Wallet for Digital Goods. The process is immediate...
There (is) used to be one in the Google Checkout API where you are given 7 calendar days to charge a pre-auth. However, this product will be retired in November.
Related
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.
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
So I’m creating an app for a guy who runs a local auction (a mini ebay meets craigslist if you will, but for more in person transactions). I’m doing it as a favor, but to also build my portfolio, so hey we both get something out of it. Now I’m running into a bit of a thinker on the “payment system”. The idea we came up with is when a seller completes the transaction, and confirms the sale, the money is held “by a middle man” until the buyer confirms the item (kind of like how Pay pal can release funds early if the buyer of an ebay item says it’s a good sale).
The client wants it set up this way so that he doesn’t miss out on his cut (10% of the sale)– as in I buy an item, meet the seller in person, then we just do an exchange there having used the app as more of a means to meet. I know Uber charges your card automatically upon GPS once you reach your destination, but it would be better to pull up the “buyer” portion of the app to confirm the sale, thus moving it from the middle man to the seller.
Aside from ensuring the client gets his cut, this can also build confidence that the “sale is funded” when the buyer is on their way.
Anyway, are there API’s out there that can help be build something like this for speedy transactions?
Not sure if this helps, but we will be using Parse as the back end.
Thanks!
There are several payment APIs for the iOS, and I can recommend Stripe which has everything you need. They have an excellent support and documentation for integrating with iOS. You can check the documentation here. Also it works really well with Apple Pay and it's implementation is no brainer.
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
We are prepping for the release of a large web application that has been in development for the past year. We are about to start the process of integrating ActiveMerchant to handle recurring subscription fees for the service.
I am looking for any advice regarding best practices considering our requirements (listed below) and any additional heads-up for common pitfalls or specific issues I should be giving special consideration. The payment gateway we will be using is PaymentExpress as it's one of the few supported gateways that has recurring billing and doesn't have any special conditions for companies operating outside of the USA. The business behind this application is based out of the UK.
Users of the application create an account with a sub-domain where they can access and customise the application and their data. Below are some of the requirements/features that might have an effect on how billing works:
All users get a 30 day trial
There are different plans, including a free one
Higher priced plans have larger limits on the amount of data (e.g. users, projects, etc) they can have in their account
Billing period will be monthly, beginning after trial
There will be discounts/coupon codes to get a percentage off the normal price for a year on plans, etc.
Plan pricing will change as features are added
Specific hurdles I can foresee will be things including the following:
How to handle downgrading when they violate the plan limits for lower level plans.
Behaviour when credit cards expire or payments don't go through (a read-only mode enforced, perhaps)
When plan pricing changes, we want to honour previous prices for existing users for a time period (such as 6 months), then start charging higher rates. If the plan price decreases, it will take effect immediately.
Other advice that would be helpful would be anything regarding flow of the application. How should billing forms be presented to the user? When should credit card information be required? How should invoices be sent, stored, and accessible?
I should disclose that we plan to base a lot of the code base off SaaSy. SaaSy is designed to be used as a separate Rails app that handles all the signup and account management side of things. However, this doesn't work for us since we never planned for this from the beginning and it would be a tedious process to adapt our application to work like that. Consequently, we'll be pulling code and ideas from SaaSy and merging them into our app, a considerably less tedious task.
One thing I wanted to add: keep in mind you don't need to use the recurring billing feature that is built into the gateway. In general these systems are legacy and very difficult to deal with, we get spoiled in the rails world.
You get a lot more flexibility just using them for one purpose (to bill a credit card, and perhaps also store credit cards for PCI compliance). Then roll your own recurring billing in your rails app with a cron job, a date field for when they are paid through, and amount each person is paying (in case they used a coupon) etc.
One small example: sometimes people will cancel a monthly subscription in the middle of the month. They want to make sure they don't forget to cancel before the next payment. Most gateway recurring billing that I've seen will instantly terminate the account (or send you a message indicating this). In reality, the user has paid through the end of the month and should be given 2 more weeks of access. You can do this if you have rolled your own recurring billing in rails, but not if you are using the gateway recurring billing. Just a small example.
RailsKits has a Software as a Service kit that should do what you need. It has built-in support for free trials, upgrading, downgrading, plan limits, etc., and it supports PaymentExpress (and some others).
I've researched it a bit for a project I'm doing, but I haven't purchased it yet so I can't vouch for it. However, I have seen a few blog posts praising this kit.
While the RailsKit is relatively inexpensive when compared what it would cost you to implement all of its features yourself, there are a couple open source versions out there that aim to accomplish the same thing. The one I remember off the top of my head is called Freemium.
EDIT: I forgot to mention that Ryan Bates said in his most recent Railscast that his next episode or two will deal with recurring billing, so keep an eye out for that. He usually does one episode per week, and the five he's done since December 22 all cover handling payments of different types.
Peepcode has a PDF for sale(70 pages) that details various aspects of payment processing and industry practices for this. It may be worth checking out:
http://peepcode.com/products/activemerchant-pdf
I'm also in the middle of setting up a subscription based website and these are our current requirements. They may help you regarding best practice:
Users will be able to choose one of
the subscription plans.
Users will be required to enter their
credit card details to sign up to
their chosen plan.
All major credit and debit cards must
be accepted including Maestro and
American Express.
Each plan will have a 30-day free
trial so users' credit cards should
only be charged after the 30-day
period expires. However, the validity
of credits cards should be checked at
the time of sign up.
Users will be emailed a few days
before their credit card is charged
to notify them that they will be
charged soon unless they cancel their
account. If they cancel their account
within their 30 day free trial, their
credit card should not be charged.
After any free trial period, users
will be charged in advance for their
use of the system - ie they will
pre-pay.
Users will be charged automatically
every month for their chosen plan.
Each month, users will be sent an
email a few days in advance to notify
them that they will be charged. Once
payment has been made, users will be
emailed an invoice showing that their
payment has been received.
Users will be able to upgrade or
downgrade their accounts at any time.
When users upgrade/downgrade, their
next subscription charge will be at
the new rate. Users will only be able
to downgrade their accounts to a plan
that can handle their data. For
example, if they currently have 10
active projects they can't downgrade
to the Basic plan because the Basic
plan only allows 5 projects. They
will have to delete or archive 5
projects before you they can
downgrade to Basic.
Users will be able to log in to their
account and change or update their
credit card details.
Users will be able to cancel their
account at any time. There will be no
further subscription charges after a
user has canceled their account.
However, users will not be refunded
for part of the month they have
already paid for.
All parts of the payment system must
be 100% PCI DSS compliant; including
any 3rd party systems.
The payment system must support
automated notification and retry of
failed subscription renewals.
The payment system must support
discount vouchers with expiry dates.
Credit card details must not be
processed by or stored on our servers
they should always be processed/stored by our 3rd party
payment processing partner. We do not
want responsibility for securing
these details and complying with
legal rules and regulations.
Users will be able to log into their
accounts and see a full billing
history including dates and amounts
paid. We will also need to be
able to log in to a system to see
customer payment plans and payment
history. This will be essential for
customer service.
We've also been looking at http://chargify.com/ which looks like it could save a lot of coding time.