Here are our requirements:
Send money to our users' credit cards. This is a unique requirement that many payment systems don't support. We essentially need to be able to grant a bonus/reward (sort of like a refund but without a preceding purchase).
Avoid stringent PCI compliance requirements. We're fine with paying a 3rd party to store the credit card info; we'd rather not deal with quarterly audits.
Credit card form must be translatable into English, Chinese, Korean, and Russian.
Credit card form must appear within our site and look like the rest of our site.
Fees must be reasonable.
Apparently Moneris satisfies everything except #3. But that might be a deal breaker for us.
Know of any other gateways I should explore?
Generally, you cannot 'refund' a credit card that you have not charged a higher amount. Sounds like you probably have a very uphill battle.
Anytime you try to remit money to a credit card, you will be asked to reference the previous CHARGE transaction or you will not be able to process the credit transaction.
Any chance the people you need to pay could all become paypal members so they can be paid? Paypal has a very slick little interface to allow you to pay other paypal members in batches - real fast, real easy, real easy to code. Most folks will rush to join paypal if it means that what they have to do to get paid - all you need to know to pay them is their paypal login email address.
Instead of issuing charges back to a customer's card, have you considered placing credits on their account instead? It ends up being cheaper for you (no transaction fees!), and it encourages to keep the customer with you longer.
A change in this requirement would make it very simple to use something like Recurly.com, whee I work.
Related
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...
I'm working on an app-idea that enable users to sell goods and services through the app. For this to work I need to be able to pay users, much like uber drivers are paid for their rides or how snapcash transfers money from one user to another.
Does Apple have any framework to do this in iOS apps?
Does it have to be country specific maybe? So that every user register their bank account and my company takes money from one users credit card and makes a bank transfer to the receiving user.
Any input or pointers to where to find more info on this is much appreciated.
No, Apple does not have a framework to do this, unless you use Apple Pay (in which case it's not a P2P payment).
Your solution will have to be country specific and more. I.E. bank specific. You'll have to have deals in place with each bank you want your system to work with.
I believe you would like to have a checkout option on the mobile. If this is the case, there are lot of options available. It depends on country and what exactly you are trying to achieve.
Please more information to assist you.
I have an application in which i need to add a screen which will accept paypal information or credit card detail and then that will be passed to server for charge processing.
i have doubt whether this is possible or not, if possible then whether apple will approve it or not.
My requirements are
1) customer will buy a ride
2) driver will accept that and driver should get paid.
Customer will add credit card detail and send to server where money will be deducted
driver will ask for payout so driver will be asked paypal detail and sent to server and server will process the transaction pay to driver.
So its clear that we can not use in app purchase as its not buying the digital items.
Please suggest if there is any alternate way to achieve this
Thanks in advance
I'm looking at using Braintree for my app's financial services. Struggling with it, but might be good for you to look at as well.
I have a scenario, I am working in the phone gap iOS application which able a user to buy and sell a commodity. Take three persons A(Owner of the app),B(Seller),C(Buyer).
B wants to sale a commodity and C want to buys it. C agreed upon a common point and proceed with the payment. Now when the C pays for the commodity i want to shift 2% of the amount to the A account and rest of the payment to the B.
I am aware this is done over the websites and there are plenty of examples. I want to know few things:
Is it possible in phone gap application, does paypal sdk allow to do so.
how could i do the two transaction in one single go, in case i need to do both the things manually.
Is this thing can be automated or this will be handled manually at the back end.
Here is the link for the phone gap plugin that i am using for app.
If anyone could guide me to any doc which explains this or any helping material that will be a great help. I have been reading and searching over net but could not get any help.
Thanks in advance
1) It's definitely possible as it's just a matter of making API calls. The SDK should handle it for you, but if not you could always build the requests yourself.
2) You could do either a parallel payment (where the payer would see both receivers during checkout) or a chained payment (where the payer would only see the primary receiver during checkout.)
Most people doing this sort of thing like to hide the split, so I'll assume you want to do a chained payment. You'll make a request to the Pay API with a primary receiver set to the seller and the secondary receiver set to you.
You'll set the primary receiver amount the full amount and the secondary receiver to their amount accordingly. For example, if $100 is paid the primary receiver amount would be $100 (not $98) and the secondary receiver would be $2.
I would definitely recommend reviewing the Adaptive Payments documentation which has a lot of detail about chained payments and how it all works.
3). Both transactions will automatically happen when the payer completes the checkout.
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.