I'm making a site for a coaching company, and they've requested that we somehow keep card information on file (I informed them that that is a big no-no, and most payment API's will handle that side of things for us) so that we can charge the cards 'on-demand'. For example, the person shows up to a coaching session, types in a pin, and it charges their card for one session.
Best case scenario- this also works for an online store as well for payment processing. Once the card is on file, they can create a card, punch in their password, and they are good to go.
We are currently using Authorize.net with Ruby on Rails. I'm still fairly new to the development world, and this is my first time needing to handle payment processing. As far as I have seen, there isn't as much documentation as there should be. They would prefer not to use Stripe, as it has high per-charge fees, and most of our fees are $8-$15, and they also want to avoid PayPal, as it has been known to freeze accounts for no good reason.
Storing credit card information on your side is not practical for two reasons - security and cost (PCI compliance). Your best option is to use Stripe or Braintree.
Both offer great libraries and work as payment aggregators (no need for a merchant account with a bank to start processing payments).
https://stripe.com/docs/api#cards
https://developers.braintreepayments.com/ios+ruby/sdk/server/payment-method-management/create
For Authorize.Net, you would use Customer Information Manager for secure data storage. http://developer.authorize.net/api/reference/starting_guide.html#customerInfoManagerID
I am making a web service where credit card information will be stored as part of a user profile and will be used to process payments.
However, I don't like the idea of saving the card information as raw text in a database. Instead, I would like to hash the card number in some way so that if a malicious person got access to the database, the users of the site will remain as safe as possible.
I imagine that it could work similar to how the password is hashed, but an important difference is that I need to be able to un-hash and send the credit card information through a 3rd party api.
How would I go about adding a hashed credit card to a Devise user in rails?
Thanks for any help
I would strongly recommend against storing credit card numbers in your own database. It's very difficult to meet the Payment Card Industry Data Security Standard - a.k.a. PCI compliance.
http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
Basically, even if the card numbers are hashed, you are still responsible to meet very high security standards. Only credit card processors and/or gateways (PayPal, Stripe, Authorize.net, etc.) typically store credit card information because it's part of their job to worry about meeting these strict PCI standards so you, as the merchant, don't have to worry about it. It's relatively easy to use their servers to store your customers' encrypted payment info and allow the customer to retrieve it again when they want to make a new purchase. Because you, as the merchant, are never actually able to get access the card info, encrypted or not, you're not responsible if the card number gets stolen - the processor is.
It's actually a great deal and a major selling point for most of these processors.
EDIT
Good news! It looks like Ordr.in has this service available and, from their FAQ, it looks like they're PCI compliant as well:
Is Ordr.in PCI Compliant for credit card processing?
Yes. We work with Braintree for PCI Compliant CC processing on all
transactions.
It looks like everything you need is here in the API docs - https://hackfood.ordr.in/docs/user#addCreditCard
From what I can see, it's pretty simple. The user uses your service as a third party to create an account with Ordr.in. The user can save a credit card to their account (all stored on Ordr.in's servers) and then when the user wants to make a charge, they just log in with their email and password. Seems pretty straight forward! I can't vouch for ordr.in personally, but they look pretty legit.
I have a client who recently changed the scope of a project I was building for them, to a marketplace.
Previously users had to pay a nominal fee to register for the site...I was handling credit card transactions using Active Merchant.
For the marketplace that they now want to build they want to build a simple escrow-type system...the payment to the seller gets released when the buyer receives the product.
This will be difficult for several reasons:
How will the system be able to determine when the item has been received? The receiver could simply lie about it. I know paypal does something similar, but they use the tracking number from the shipping company to determine this.
How do I go about depositing payments in the sellers account? It's easy to process the payment from the buyer, but how do I get this money to the seller?
For #2 I was thinking it might be possible to use some sort of paypal account to handle this...I haven't looked into any specifics yet. Any idea where to start?
Paypal may be able to handle #1 as well, if I am lucky.
Any suggestions?
We used PayPal Adaptive Payments for #2... still hunting for a solution to facilitate the transaction between User A and User B with the marketplace taking a %...
Would love to hear more answers!
In regards to #1 - I'd require some sort of signed receipt on delivery. That would depend on the value of the goods, at the lower range tracking receipt + some sort of reputation system to remove people who abuse the system has worked for me in the past.
In regards to #2, disbursements; I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
Balanced will allow you to collect funds into an escrow account and then disburse the funds as a separate action which allows you to split the funds up or group them together as required. Payouts are done via next-day ACH (US only) but we're building out international support.
Balanced has an excellent ruby gem since you're building in Rails and there's an ActiveMerchant plugin if that's what you are/have integrated with.
I am in my sophomore year of programming in general and Ruby on Rails more specifically. I have created several apps and finally have one that I would like to start charging for. I have never implemented something like this before and I feel like (from what I have read) most of the docs provided are a bit over my head. I don't mind diving in but before I did I wanted to get some opinion from those more experienced about what is the simplest way to implement a model for charging my User a month fee for use. Two notes:
My App contains Users already and I will be introducing a new section of the app which I only want to give access to those who pay.
I don't mind sending them to a third party page for payment.
From what I can find, it seems like both PayPal and Chargify do a decent job of providing help for this type of integration. What are your thoughts about which type of solution is best for a newbie to this space.
I'll admit I'm biased since I'm one of the founders of Chargify :-).
But before that I helped build 7-8 companies, most recently Engine Yard, and I really, really wish we'd had something like Chargify back then. I remember thinking, "Man, we need something like 'Basecamp for Billing'... it should be simple, sign up with a credit card, define products & pricing, and get going". So I found the Chargify/GrasshopperGroup folks and joined the team.
Chargify takes it up a level from what we found with payment gateway offerings and things like PayPal... with Chargify, you define products, prices, coupon codes, metered-usage units, etc., and let Chargify do as much as you want. The system emails your customers when their cards get declined or expire, and directs them to a URL to fix the problem, etc.
Billing gets complex as a business grows. I tell callers that if their needs are really simple, then they may indeed be okay with Auth.Net's ARB service or another like it, but as soon as your needs even begin to get less simple (ie, customers change plans mid-cycle and want proration), then Chargify really makes your life easier.
And as Rails folks ourselves, we're always working to make the service better, so you'll get more and more services as time progresses. And you can actually call us 24/7 and get someone on the phone! Our Level 1 phone team knows the product better and better each week and can send the call to Level 2 if they don't know the answer.
So, you're getting a good piece of software, plus a good team who's here for you to develop new features and provide support if you need it.
Sorry this sounds like an ad; it is, partly, of course. But it's also just a reflection of my frustration trying to build this at earlier companies, and my enthusiasm for being part of Chargify now and helping merchants not focus on recurring billing :-).
http://www.braintreepaymentsolutions.com/
At a previous place of employment, we used Brain Tree, and I only heard good things about it though I wasn't (and still aren't, but trying) a programmer at the time. It seems to be a little bit more expensive than the big guys - but has more freedom as well.
It might be worth looking into.
Charging System or Billing System?
Talking with a number of folks building businesses in the Ruby community, I thinks it's important to note that simply collecting customer payments and scalable billing are two rather unique animals. Today's SaaS companies are not always aware of the difference.
Hitting credit cards for $39.95 on a monthly basis is something most of the "payment tools" mentioned here do well. Yet, when one needs to incorporate a complex billing algorithm (charge model), client contracts, promotional codes, freemium, tiered, rollover or metered usage, or integration with other internal systems, They need more than a payment machine. They really need a "smarter" billing system that leverages a payment gateway, but does far more than simply hitting cards on a monthly basis.
Also, if one has a significant number of clients or volume a system that scales is key. For research check out more mid-tier billing systems like http://www.metanga.com or http://www.zuora.com.
To take payment you're going to need a few things:
A bank account to put the money in
A payment gateway
An SSL certificate (this can be tricky if you're in the cloud)
The beauty of products like chargify or braintree is that they give you a nice API for dealing with card events like expiry or failed payments and can sometimes also act as a payment gateway.
I integrated with cheddar getter (https://cheddargetter.com/) in an afternoon. There's a ruby gem (https://github.com/ads/cheddargetter) and they have a payment gateway service, but I haven't used that so don't want to comment on its value.
Payment is an annoyingly complicated process and you have to pay everyone down the chain, the hardest part is making sure your service is competitively priced but not priced in such a way where you're not making any profit.
Here's some more links you might be interested in reading:
http://www.activemerchant.org/
http://recurly.com/
I've used PayPal's Express Payments with ActiveMerchant before, because there's no buy-in cost; PayPal just takes their slice of each transaction, so I don't have to worry about paying fees to a ton of different providers. The downsides are well-documented, though, as well - specifically, if PayPal decides that you're doing something shady and decides to freeze your money, you're up the creek without a paddle. That's a calculated risk you have to evaluate, though.
You might look at Saasy if you don't want to roll your own full solution, though. It seems to integrate well with existing apps.
ActiveMerchant is definitely the way to go to get integration with PayPal or any of the creditcard gateways like Braintree (highly recommended) or Authorize.net (good and cheap). The SaaS Rails Kit, which I authored, uses it as the basis for a full recurring billing solution that you can integrate with your app.
Regarding your follow-on question about PayPal, ActiveMerchant makes it easy to use their API or IPN to get information back about the transaction status.
I've had a ton of experience with this and the first question that you need to ask yourself is "how important is recurring billing?" If recurring billing is a requirement then by all means use Chargify, Recurly or the like. They are all pretty good.
If, however, you are simply looking to outsource your payment process (as I typically am) so you don't have to deal with PCI compliance (which is a nightmare) then you have a lot LESS viable options IMO. You can use PayPal, Amazon or Google Checkout, but they all have downsides. PayPals user experience is terrible and many people get confused by it believing they need a PayPal account to complete the purchase. Google Checkout REQUIRES the user to either have or create a Google Account, which is ridiculous and Amazon is ok but like Google Checkout requires an Amazon account.
WePay is my personal favorite right now for outsourced billing but is very lean and you have to use their checkout process. Their staff and API is awesome though.
What I would LOVE to see if a Chargify-like solution that is focused on ONE OFF sales. Something that let's me host the entire checkout process on THEIR PCI Compliant server but allows me to customize not just the look and feel but form. If I wanted to ask for extra info, like a username and password, I can. If I don't need shipping address, I can remove it. If I only want the CC number, CVV and exp date without billing address I can do that, etc.
But to the best of my knowledge that does not currently exist. Don't use Chargify for one-off transactions. While they support it the checkout process is VERY clunky for one offs (displays things like $0 setup fee, which means nothing when someone is buying a shirt or one time downloadable material and is merely confusing).
Good luck!
We want to add billing capabilities to our rails-driven web application. I've come across two plugins that do that - Service Merchant (which is free) and SaaS Rails kit (which costs money).
Does someone have some experience with these plugins (or others with the same functionality)? which one would you recommend?
Thanks!
I looked at both of them and unfortunately neither met my needs.
You say that you want to "add billing capabilities" -- but how complex are your bills?
Subscriptions?
Multiple subscriptions possible per customer at same time?
Any variable monthly costs? (eg the customer pays every month, but the amount they pay varies depending on something.)
Any additional items that aren't monthly? (eg setup charge, consulting, etc)
Billing subscriptions in advance? (like the phone company bills monthly service.) Or billing in arrears? (Customer uses service, then you bill them.)
There are very expensive companies you can outsource this stuff to (~ $25K - $50K and up for initial setup). Eg www.zuora.com
Or you can roll your own and charge the credit card using ActiveMerchant. Be sure to store the credit card info at your card processor (eg Authorize.Net Customer Information Manager).
If you're venture backed, then consult your VC for ideas. It may be worthwhile for you to outsource the whole thing.
If you're a lean startup, use one of the low-end guys if you have a simple subscription model. If your billing is more complex than that, the right answer may be to roll your own.
Low end subscription billers: Chargify, recurly, Google for "subscription billing"
No experience with those plugins, but I highly recommend using chargify to do recurring subscription billing. You'll use their rest-based API to create 'subscriptions' and it handles all of the charges, emails, and canceling subscriptions for you.
You'll pay chargify per user on a monthly basis (but it's cheap), and you pay the credit card processor, but there's no setup fees to chargify to get started.
http://chargify.com/