Implementing credit card payment systems has been one of my least favorite coding projects, but things have gotten much nicer since I first started. I'm just starting again with my new company, and I will be continuously updating this post with my progress. I'm hoping to capture every single decision I've made to help other people get going and also as a reference for myself the next time I need to do this.
10/20/11: Choosing a Merchant Account and Gateway
After looking at a few different payment gateways, I've decided to try Braintree, mostly because of their awesome-looking, well-documented Ruby gem, but also because I've seen them at various Ruby/Rails events (speaking and sponsoring), and because I've heard good things about them from Figure53 and friends at LivingSocial. I also really like their "transparent redirect" feature, where credit card numbers never enter our system at all.
We also need a merchant account to go with the gateway. Since we're doing all of our banking with BB&T so we've decided to get a merchant account with them as well. Their rates seem competitive (much cheaper than Braintree's merchant account, probably because they have to partner with a bank and are charging a markup over the bank's fees). We also want to deepen our business relationship with the bank vs. shopping around for the absolute cheapest rates (something that can be done with FeeFighters).
We're doing the paperwork with BB&T right now. Next step will be to start integrating the braintree gem into our codebase, creating the payment screens in our system, etc.
10/25/11: Considering a Switching to Stripe
After posting the above, Gabriel Weinberg and other friends on Twitter suggested I check out a Braintree competitor, Stripe. Stripe seems to offer even more of a "one-stop shop" for payment systems than Braintree, and it has similar Ruby bindings and "transparent signup" features. So for me it comes down to pricing. A commenter from FeeFighters also suggested their Samurai gateway.
Both Stripe and Samurai look great when your volume is relatively small: their lack of monthly fees means your processing costs are lower. I'm building a subscription-based app, so I removed Samurai from consideration; not having to write a bunch of proration code, not having to worry about accidentally billing someone twice, etc., is a huge benefit of Braintree and Stripe. I'm sure Samurai will add it soon.
Once you get up to higher volumes, Stripe and Samurai become more expensive than Braintree plus a merchant account. I did some spreadsheet modeling and determined that using Braintree plus our BB&T merchant account becomes cost effective once we have 50 customers, which is about as many as we would need to really have traction.
I'm tempted to use the cheaper short-term solution now, but since I don't want to have to switch this around later once we get to 50 customers, I've decided to stick with Braintree and our own merchant account.
I also considered using Authorize.net, which seems slightly cheaper than Braintree, but the overall look and feel of their website is not developer friendly. Whereas all of the other sites I've mentioned look like they've put a big priority on making the developer happy.
11/4/11: Finished Initial Integration
I had a fairly easy time integrating the code with Braintree's sandbox. I was greatly helped by this testing technique that uses the wonderful VCR gem, so I could run my integration tests against real Braintree responses without having to hit their API every time. I also found inspiration from Braintree's example Ruby applications.
I'm using the Transparent-Redirect customer creation method to create a customer and store their credit card in the vault (so the credit card number never touches my systems at all; the only thing we store is a payment token referring to the credit card stored by Braintree). In a separate step I use the subscription creation API to create the monthly recurring charge.
My biggest struggle was in figuring out how to wrap the transparent-redirect response from Braintree in an ActiveModel-compliant object, so that when the user entered invalid data I could render the form like any other Rails form, with inline errors and so forth. I came up with a hack which I'm a little too embarrassed to post here but if you want it email me. In hindsight I should have just used this custom form builder.
Subscribe to:
Post Comments (Atom)
9 comments:
Looking forward to your updates. I am also right in the beginning of this process for ToolSpinner. We also will be with BB&T.
Hey - Sheel from FeeFighters here. Thanks for the plug. You have valid rationale for everything in this article EXCEPT using BB&T for your merchant account. BB&T doesn't do any processing themselves - they outsource it to First Data. You can find First Data directly on the FeeFighters marketplace for a much better rate. We also have a gateway that is super easy to integrate with http://samurai.feefighters.com. We have a $25 monthly fee, then it's 2.3% + 30cents. There are pros and cons vs. Stripe... the biggest thing is that it gives you a migration path for when you want your own merchant account... you won't need to reintegrate. Ping me if you want to try it out... feel free to search the twitterverse for thoughts on FeeFighters/Samurai too :) We have lots of satisfied customers, including some very notable ones.
Cheers and thanks for including us!
Sheel
Hi Sheel, after you wrote this I took a close look at Samurai. I think it's really cool and the cost is very competitive, but since I am building an app that uses subscriptions heavily, I can't use Samurai, because you don't seem to have an API for that. Both Braintree and Stripe have awesome subscription systems where they handle recurring billing, prorating, etc. I will definitely keep an eye on Samurai for future projects, though!
Mike - that makes sense, we don't have a solution for subscription billing just yet.
Just looked over Stripe, they hold your money for 7 days. That's as bad as Paypal and negates one of the primary benefits of using a full up merchant account solution. Ugh.
Did you run into any issues using VCR and Braintree's sandbox? I'm currently testing our integration and running into issues where the customer_id as recorded does not match later requests to build a subscription. I'm considering hard-coding the customer_id only for env test.
Hi Jonathan, I didn't have any problems but that was awhile ago. Unfortunately the project I built this for is now defunct so the code hasn't been exercised in awhile.
Hey Mike,
After looking at both a little over a year later, stripe seems to be the clear winner. Braintree still requires a 2.9% +$.30 per transaction, which is the same amount as stripe. The big takeaway I see is the need for a payment gateway. Braintree requires a payment gateway and charge about $49 per month + $.10. Stripe eliminates the need for the payment gateway and in the long run you save.
I could be viewing this wrong though? Just my thoughts, thanks again for a very informative blog, keep it up :)
Post a Comment