Making of a Web App: Part 12 – Payment Processing

Most of the Making of a Web App series follows a typical path from idea to implementation. In that path, payment processing and subscription management is one of the last items to be implemented. There is no reason to do it now for PlaybookIQ except that we need subscription (i.e. automatic recurring payment) capability for another project so I deployed it today.

For the technically inclined, here are some notes from that experience.

To implement credit card processing you need a merchant account, a payment gateway, and a secure website for collecting billing details. It can take some time to compare the merchant account and gateway options available to find the ones that are right for you. And the paperwork and setup tasks with your selected merchant account provider and payment gateway vendor can take several days, so keep that in mind when planning a project.

For these components we used our local bank, TrustCommerce, and Ruby on Rails respectively.

A Personal Relationship with Our Local Bank

When you have a good, existing relationship with a vendor I think it is important to continue with it. It is important to have someone to sit down with in person if you need help straightening out payment transactions. So we choose our local bank of ten years to provide our merchant account. They offer competitive rates and were knowledgeable and helpful in getting us set up with our payment gateway.

TrustCommerce.com

TrustCommerce is our payment gateway. Like our local bank, they are knowledgeable and offer competitive rates. They have an extensive open-source API library and good documentation. By connecting through their TCLink API we get the benefit of a failover system offers “virtually” 100% reliability (e.g. it has no single point of failure). Finally, they maintain the credit card information for recurring billing so we never retain credit card numbers on our servers. Instead, they create a six digit billing ID and that billing ID is our reference to the credit card details.

Ruby on Rails TrustCommerce Subscription Plugin

Here is Zack Chandler’s blog entry when he released the plug-in in October, 2006. Following the steps in that post and in the plugin itself, I was able to run the tests Zack included shortly after starting. When fully configured, the plugin makes easy to understand code like this possible:

#Create a $12.00 monthly subscription for Jennifer Smith
response = TrustCommerceGateway::Subscription.create(
  :cc =>        '4111111111111111',
  :exp =>       '0412',
  :name =>      'Jennifer Smith',
  :amount =>    1200,
  :cycle =>     '1m',
  :demo =>      'y'
)

if response['status'] == 'approved'
  puts "Customer profile created with
     Billing ID: #{response['billingid']}"
else
  puts "An error occurred: #{response['error']}"
end

The Devil’s in the Details

Though the plugin is great, don’t let it fool you into thinking that implementing the code around the plugin is easy. You still need to build the code to create and manage TrustCommerceGateway::Subscription objects, all the while ensuring everything is done under cover of SSL and with consideration for several other security issues. For example, don’t forget to include:

filter_parameter_logging :cc

in your controllers to ensure credit card numbers do not get written out to the logs.

As is usually the case with programming, implementation of the blue-sky-all-is-approved case was the easy part. Wanting to ensure all types of responses from the payment gateway were handled properly (and being hooked on TDD) I spent much more time writing and running tests than I did writing models, views, or controllers.

Questions?

Unlike with the Deprec setup, I did not write detailed notes. Yet, if you are a Rails programmer implementing the TrustCommerce Subscription Plugin and have any questions, send me an email and I’ll be happy to try to help out.