I am new to rails and am starting to learn about how to integrate payment processing. I am trying to find some direction about where to focus my learning about payment processor integration.
From what I understand ActiveMerchant is an extraction from Shopify that allows you to easily integrate many of the major payment gateways such as Stripe and Braintree. I also understand that these platforms also have their own APIs for their specific services.
There seems to be obviouse benefits to using activemerchant if there is a possibility of wanting to switch payment processor in future or if you intend to use different processors accross different sites.
My question is what are the drawbacks of using ActiveMerchant as apposed to a specific API. Do I take more responisibility for security if I use ActiveMerchant and is it much more complicated?
My reason for asking is I do not want to focus my time and effort on learning a specific API when I could learn ActiveMerchant and use it accross all providers.
Thank you :)
I've only used ActiveMerchant once (for an e-commerce system), and used it because of its integration with the respective payment gateways we required
--
Case For Use
The problem you have with "native" APIs is that they have a habit of changing when you least expect it, making all that custom (brutal) work to originally implement them very difficult to debug when it suddenly blows up
I've found ActiveMerchant is a great "buffer" between Rails development & the payment providers. If Shopify are getting paid to handle payments for their users, surely it's a good thing that they'll provide an up-to-date gem with all their experience
Although you'll have to manage much of the integration yourself (still), ActiveMerchent certainly acts as a very reliable abstraction layer for accepting payments
--
Drawbacks
In my experience, the main drawbacks are that ActiveMerchant may not support some of the more "niche" features of particular API's (for example, currency conversion or similar). Although Shopify, by all accounts, are very liberal with the inclusion of functionality upon [pull] request, you still generally have to abide by their specs
Another thing to consider is that you may have to "bend" the API's to fit your application. In our company, we have a lot of different ways to create the wealth we need, and as such, we don't want to rely on "accepting payments" with our providers.
We like to create integrated experiences, which invariably means giving people the chance to purchase things like premium accounts, or in-app upgrades etc. When you get into the world of "micro payments" (which we're strictly not; we just have varying ways to attract buyers), you begin to have to make the APIs work by using very custom implementations
--
Coverage
From a developer perspective, the main benefit that ActiveMerchant provides is that you are "covered" with so many different payment providers.
Hawking back to my comments regarding API changes, this means that if you integrate your app with the ActiveMerchant interface correctly, you should be able to work with a multitude of many different payment providers
The list of supported providers is monumental - meaning that if you want to change your payment provider from Paypal to Stripe or something - you'll be able to do so by not editing your core code a huge amount
--
Resources
Finally, because ActiveMerchant is a base-standard, you'll get much more support than direct implementation with the various APIs. This is reflected in the likes of Railscasts:
Related
I'm at the point in my application where I would like to integrate a saas solution into my application using ruby on rails. So far everything has been good except I am unsure where to begin.
My Idea:
I would create a subscription.rb and plan.rb model. A user would belong to subscription and subscription would have many users. Next subscriptions would have many plans and plans would belong to subscription. I would then add role for each plan to limit a user from certain parts of the application maybe using cancan. After setting everything up I would integrate stripe into my application to handle the payment side of things.
The above is how I am thinking of setting this up. It may truly be the wrong concept but that is why I wrote it so you could get an understanding of what I am thinking. I know I could use third party services like recurly, chargify, etc but I am opening my eyes to see if this can be done using a similar a approach.
What technologies have you used or prefer to use when creating a saas application?
Is my approach wrong? If so what is a better way to approach this?
Any tips or advice for creating a saas application such as technologies, ruby on rails tools etc.
Take a look at the open source example application for a Rails Membership/Subscription/SaaS Site from the RailsApps project. It comes with a tutorial that explains the implementation in great detail. Here's the libraries it uses:
Devise for authentication
CanCan for authorization
Stripe for recurring billing
Twitter Bootstrap for front-end CSS
Using Stripe for billing makes implementation easy and reduces security risks as Stripe handles all the automated recurring billing.
The RailsApps example puts CanCan together with Rolify and uses roles that correspond with subscription plans to manage user access. It shows how to simplify the architecture so there's no need for the complexity of a subscription.rb or plan.rb model (though you could refactor that if you wanted to).
1) I use MongoDB as the db backend for the flexibility, RSpec for TDD, HAML/SASS, and RailsAdmin for a quick admin dashboard.
2) Its not necessarily wrong, but its up to you in terms of what you plan on allowing users to do.
3) So wait, have you already developed your tool or are you asking us to plan your tool. Also, what kind of Saas application did you intend to build?
Have seen some conversations revolving around this, but hoping for some current input as to perhaps the best libs and services available for Rails developers at the moment who are implementing a subscription membership based website.
I'm interested in any libs or frameworks with which you may be familiar through GitHub or elsewhere as well as what service has given you the best experience so far for clients and your own sanity? I'm leaning towards paypal and perhaps also including Google Checkout, however there are certainly a lot of other options.
I'd like for it to be clean and to appear as integrated into the website as possible while carrying the trust of a larger service provider such as PayPal and Google.
Additionally, these are mostly micro payments at around $1.00 USD. Sometimes purchases go up to $15 to $30.
EDIT: Since initial post I've found SaaS Rails Kit (http://railskits.com/recurring_billing/). Has anyone had experience with this vs Recurly? Doing some research as per the first answer, it appears Recurly is the superior option at this point for our model, however this Rails Kit may be an even better option if it has met some very positive experiences in comparison with other options.
The one I prefer: Chargify (soon to be available on heroku)
Another I know but haven't used: Recurly (soon on heroku too)
I've been programming for years, and I've also done a few professional programming projects. I recently had a friend ask about creating an e-commerce site, but I had to turn her down because I had never worked on a web application that can bill. I also might need to write a subscription-based web service in the future. My question is, how do I even get started with billing? I've never found a guide about this, and I barely know how bank accounts work since I don't manage my own one (I have an excuse for this since I'm only 16).
I don't know if the answer is language dependent, but if it is the languages I'm interested in are Python, C/C++, and Java.
There are lots of ways to go about setting up e-commerce sites;
If you don't have any experience whatsoever, and don't want to get into anything "complicated", i would suggest going with a customizable web "storefront" hosted by someone else, pre-integrated with credit card processing, etc. There are tons of options for these online. Just search google for "web storefront". Yahoo! even has such a service:
http://smallbusiness.yahoo.com/ecommerce/sellonline.php
Going beyond that, It's pretty easy to integrate with someone like PayPal. They have all sorts of options from the most basic (use a link to send someone to their site with query string parameters to let paypal know what the user wanted to buy):
https://cms.paypal.com/us/cgi-bin/?&cmd=_render-content&content_ID=developer/home
Beyond that level, you will need to signup for a merchant account, or other similar sort of service, like the one offered by authorize.net (who I like):
http://www.authorize.net/
There are components you can buy for most major web development platforms like .NET, JSP, etc. Perfect example is dotnetcart. These components provide out-of-the-box, easy-to-setup integrations with major CC processing companies, as well as out-of-the-box shopping cart implementations:
http://www.dotnetcart.com/
Finally, most merchant services / payment gateways provide web services for direct integration.
PS.) Never ever ever store CC numbers ; )
I would look at paypal's api to get started. You might not want to stick with them but it is a good starting place to learn about dealing with credit card clearing houses and such.
Here ya go.
You'll typically interface with a 3rd-party for doing banking transactions. One that I've work with in the past is Authorize.Net but there's plenty out there (PayPal is another fairly popular one with a decent API).
Basically, the best approach is to do as little as possible and let the 3rd party handle all the "hard" stuff (such as security, managing credit card details and so on).
I am investigating potential Rails plugins or Gems to help develop a SAAS type app. Specifically I am looking for help in two areas:
Restricting access to certain areas of the app based on the account's plan. For example, a bronze account allows access to some functionality, upgrading to silver unlocks access to new features and functionality. Basically, just controlling what accounts have access to what controllers.
Managing subscriptions, invoicing and taking payments. This app will be charging on an annual or quarterly basis, there's a 30 day free trial with no payment details needed up front, and I think the intention is to use PayPal Website Payments Pro (although that is not set in stone).
Given the above, can anyone recommend any Gems or plugins? I have had a look at the SAAS Railskit and I am not opposed to spending a bit of money. However, I'd certainly want to hear good things from people who have used it first, and also how easy it is to pick appart the Railskit and apply it to my own application (as I am not starting from scratch here - needs to integrate with Authlogic too).
Thanks in advance for your help.
Bruno Bornsztein offers a Rails engine that implements a SaaS site. Look for striped_rails on GitHub.
You might want to look at the open source example application for a Rails Membership/Subscription/SaaS Site from the RailsApps project. It comes with a tutorial that explains the implementation in great detail. It does what you describe using Devise for authentication and Stripe for billing.
My SaaS Rails Kit does integrate well with pre-existing apps... many of my customers do that. And the testimonials at the site are real. :) Plus there are many other similar testimonials that I haven't published -- a lot of good things have been said about it. :)
While there are quite a few different gems out there which do different things different ways, I would definitely suggest that you start with these:
activemerchant — I would use this for payment processing. It is honestly the best (and most extensible) gem out there, and its especially well-tested for PayPal usage, although I'd look elsewhere for SaaS billing because PayPal is utter crap.
declarative_authorization — This is probably the most extensible plugin for authorization, which allows different users with different roles to do different things. For instance, you can build roles for each plan.
You should also take a look at the following Railscasts:
"Declarative Authorization" - http://railscasts.com/episodes/188-declarative-authorization
"Authorization with CanCan" - http://railscasts.com/episodes/192-authorization-with-cancan
"PayPal Express Checkout" - http://railscasts.com/episodes/146-paypal-express-checkout
"Integrating Active Merchant" - http://railscasts.com/episodes/145-integrating-active-merchant
Hope this helps!
You would also need subdomain routes, for restricting your user into its own subdomain.
I'm trying to research how to add a subscription based pay model on an existing site of mine, but am running into a lot of conflicting information and caused me to be a bit lost.
All I need is a very simple way to set up recurring billing (per month) by credit card. I just need a simple solution, but am having a hard time finding the best practices of setting it up.
So far I understand that this is supported by Paypal's Website Payment Standards option. I just have a few questions regarding how I should implement it:
First, does Paypal require a user to register for recurring billing with Website Payment Standard?
I planned to use ActiveMerchant but I found some blogs that says ActiveMerchant doesn't support recurring billing from Paypal. is this true?
I found the SASS Rails Kit by railskits.com, which says it supports recurring billing with Paypal's Website Payments Standard. If I purchased this, would the code be clear enough to understand and implement in my own site, or is it kind of packaged deal for starter sites and not existing sites?
I found a lot of blog with help with recurring billing with ActiveMerchant, but using Paypal's Express Checkout. I read about Express Checkout on the Paypal site, but I still can't quite understand what it is, and how it's different from Website Payment Standard. Can anyone explain this in a simple way?
If anyone could answer even just one of these questions, I'd be very grateful!
**By the way, before it gets suggested, I have watched all of Ryan Bates' Paypal screencasts about Paypal, which are great for basics or buying items in a shopping cart, but I don't understand how it should work with recurring billing. Also, it seemed like he skipped some important steps in the video (e.g. the Paypal docs says after your app receives an IPN, you need to send back a confirmation of reception to Paypal, but Ryan does not do this in his screencast). I'm just trying to make sense of all this!
First, does Paypal require a user to register for recurring billing with Website Payment Standard?
With Website Payment Standard, you direct your customers to fill out their information on paypal's site. to me, that's kind of cheesy, but your mileage may vary. If you are going to be making some money, it's well worth integrating it into your site and upgrading to Website payments Pro, imo.
I planned to use ActiveMerchant but I found some blogs that says ActiveMerchant doesn't support recurring billing from Paypal. is this true?
It doesn't out of the box, but you have to create a new Module class that gets added into Active Merchant, plus the views and really, it's a lot of work. No should say to you that it's easy to do, because they are either liars or really good at programming.
I found the SASS Rails Kit by railskits.com, which says it supports recurring billing with Paypal's Website Payments Standard. If I purchased this, would the code be clear enough to understand and implement in my own site, or is it kind of packaged deal for starter sites and not existing sites?
Sure, it may be clearer, but if i recall, they use a referential transaction to 'fake' recurring billing, as of this august, when i wrote my solution. As for existing sites, you may have to gerry rig it into your existing app, or create it around it. TBH, the $2XX price tag scared me off.
I found a lot of blog with help with recurring billing with ActiveMerchant, but using Paypal's Express Checkout. I read about Express Checkout on the Paypal site, but I still can't quite understand what it is, and how it's different from Website Payment Standard. Can anyone explain this in a simple way?
Paypal Express requires you to have your own merchant account. A merchant account is where your money will end up and is the only for your customer's bank account to speak to your bank account easily.
Website Payments Standard uses Paypal's own merchant Account through your Paypal Account, in order to pay you.
Again, imo, pay the 30 bucks and go with Website Payments Pro.
Express Checkout is the same as Website Payments Standard. It is the method of redirecting your customers to PayPal to collect their payment info. There's a simple implementation of just creating a form that posts directly to PayPal, and you can optionally use IPN to get info about the transaction. There's also an API for Payments Standard, that lets you set up the transaction with PayPal behind the scenes, then redirect your customer to PayPal, then query PayPal via the API for details on the just-completed transaction. The SaaS Rails Kit (I'm the author of it) uses this API.
Website Payments Pro is PayPal's offering that lets you collect the payment info at your site and pass that info via their API to PayPal. You then get information about the transaction via the API. The customer never leaves your site. PayPal's TOS require you to offer Express Checkout even if you offer Payments Pro. Payments Pro costs $30 / mo. (as I recall) and requires you to fill out an application for a Pro account.
We're also developing a subscription based site and this looks pretty interesting - http://chargify.com/. Could save quite a bit of coding time.
If we are discussing how to do subscriptions using a Ruby on Rails /ActiveMerchant environment I am not sure why no one has brought up Freemium, which is a sister project to ActiveMerchant that focuses on subscriptions.
I use the SaaS Railskit, and Highly recommend it. The code is clean, commented and legible. It can be dropped in to an existing app, with minimal tweaking, or used as the foundation for a new app. I suppose it work fine if you just wanted to use it as a reference, or stand-alone payment processing app.
Hope that helps!
One other potential option is to hit one of the other recurring billing capable gateways like Authorize.net or BrainTree. I don't normally suggest Authorize.net because of their slightly gimpy development process (you have to request a test account if you want to do continual testing which takes about 2 days) but I've done integrations with them on several sites and it works reasonably well. Though they do have the same inane policy as PayPal of naming 19 products which all seem to do what you need but don't in reality.
The only bonus to this is that people don't have to be PayPal members in order to do the payment and I believe Authorize.net has lower fees but that may have just been our accounts; our sales guy was a killer negotiator.
active_merchant and the SaaS Railskit both support Authorize.net and BrainTree.
I wouldn't recommend buying the Railskit just to look at quality code that uses active_merchant though, I'm certain there are other places that you can look for free. Railskits are really designed to be used as a base and it's almost guaranteed to have a different set of assumptions about setup than you had planned on so if you've made it anywhere on your project merging the two would almost certainly be a pain. On the other hand, if you're still just starting the site the Railskit might well be a great way to start over with a really sane environment.
If you're using Paypal subscriptions then you will probably need a Paypal business account. Nothing scary it's just a case of supplying a business name to paypal and requesting your existing account to be converted over.
I also looked through a few Paypal subscrition solutions for rails and eventually just created my own.
I've written it up here Adding PayPal subscriptions to your Rails App with 1 Controller.
Question: First, does Paypal require a user to register for recurring billing with Website Payment Standard?
Yes, I believe so. Paypal wants the user to be able to cancel the payments as needed.
Question: I planned to use ActiveMerchant but I found some blogs that says ActiveMerchant doesn't support recurring billing from Paypal. is this true?
That's what I see, too. You can implement it through the Paypal SOAP interface, though. It's not too tough.
shameless plug:
I went through all the docs for Paypal and pulled out the good stuff for implementing standard and soap-based methods. You can find it for $8.50 on pragprog.com
/shameless plug: