"Making of a Web App: Part 12 - Payment Processing": comment by Scott Meade

Fri, 13 Jul 2007 12:43:43 EDT

Thanks, Zack, for checking in.

As Zack points out, with the gem available this is not just for Rails programmers but for any Ruby system.

"Making of a Web App: Part 12 - Payment Processing": comment by Zack

Fri, 13 Jul 2007 01:28:50 EDT

Glad to see the plugin is getting some good use… there is also the gem at http://trustcommerce.rubyforge.org

"Making of a Web App: Part 12 - Payment Processing": comment by Scott Meade

Wed, 11 Jul 2007 18:38:39 EDT

Good point James. Using the BillingID that Trustcommerce generates, we can modify subscription information without having to know the credit card number.

"Making of a Web App: Part 12 - Payment Processing": comment by James

Wed, 11 Jul 2007 14:36:16 EDT

Scott,

One of the most difficult scenarios I’ve run into is how to upgrade/downgrade an existing customer. I prefer not to ask for credit card details a second time in an effort to cancel the first and create a second recurring payment schedule. Being able to alter an existing recurring payment is often not easy to do with some solutions.

How have you dealt with this?

"Making of a Web App: Part 12 - Payment Processing" by smeade

Tue, 10 Jul 2007 00:21:00 EDT

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.

Synap Software comments on Making of a Web App: Part 12 - Payment Processing

"Making of a Web App: Part 12 - Payment Processing": comment by Scott Meade

"Making of a Web App: Part 12 - Payment Processing": comment by Zack

"Making of a Web App: Part 12 - Payment Processing": comment by Scott Meade

"Making of a Web App: Part 12 - Payment Processing": comment by James

"Making of a Web App: Part 12 - Payment Processing" by smeade