Several years ago, before PHP introduced their built-in pfpro functions, I rolled my own crappy interface, which of course delegated to the commandline payflow client. I could certainly do the same in Ruby today. Thinking back on it, I realized at the time, and realize again now, that delegating this functionality to a commandline app is a security risk unless you're the *only* user on the server. What we should really like to see is a library similar to PHP's pfpro library, wherein the financial transaction data gets SSL treatment before leaving our apps, and communication happens directly between our apps and the payflow server. I know a guy who's written some C/C++ Ruby extensions, and he might be willing to pull this off for a price. If I end up hiring this out and getting it done, I will make it available to the community, of course. I'm not sure how timely it'll be, as I won't need this library until next summer when I plan rewrite our ecommerce system. Hunter... do you work directly for FatWreck? If so, your organization and mine have worked together before ;-) Please feel free to contact me off-list, regardless. Everyone else... if you have experience using Payflow Pro's service and would be interested in seeing a native Ruby library, I'd love to hear from you, too.
on 2005-12-22 06:31
on 2005-12-22 08:13
David, First of all, thanks for the willingness to share ... that's how we all get to where we need to be. =) I am going to voice what I believe is needed... Rather than focus on a particular payment gateway (ie. PayFlow Pro), we should work toward an open, extensible payment module. Something that could easily be tailored for any one of the various gateways that are available (ie. Authorize.net, PayPal Processing, RBS Lynk, etc.). The protocols of these various providers, for the most part, are very similar and usually differ only in the names and formatting of the particular variables that are passed to the gateway. They usually follow the same processes: 1) URL of gateway. 2) HTTPS communication with gateway. 3) Credentials to identify merchant (eg. terminal ID, merchant ID, etc.) 4) Order details. Sure, some gateways offer more options and that's where customization would be required. I've only recently begun working with Rails (and Ruby) and find the framework/language/community/workflow amazing. There should be some way to release updated gateways, as they become available. For instance, I am currently working with my processor (RBS Lynk) to get the API that's necessary to communicate with their gateway. It's going to cost a pretty penny but it's worth it for us, as we can reduce our clients' initial investments and reappropriate portions of the savings toward additional features, etc. I guess the only problem may be ... how do you design something like this that would fit most developers/gateways? It may be a case similar to that of the login generators ... how do you please everyone and still have a useful feature/plugin? -Chris
on 2005-12-22 08:58
From: "Chris Grant" <firstname.lastname@example.org> > > Rather than focus on a particular payment gateway (ie. PayFlow Pro), we > should work toward an open, extensible payment module. Something that > could easily be tailored for any one of the various gateways that are > available (ie. Authorize.net, PayPal Processing, RBS Lynk, etc.). The > protocols of these various providers, for the most part, are very > similar and usually differ only in the names and formatting of the > particular variables that are passed to the gateway. Found these on rubyforge, haven't tried them yet: http://rubyforge.org/projects/paypal/ Library aiding with Paypal IPN from web applications. http://rubyforge.org/projects/transact/ A simple yet powerful means of creating and submitting transactions to secure payment gateways. Currently supports the Linkpoint gateway. PayPal and authorize.net support forthcoming (takes so long to setup a test account with them it's ridiculous). Sounds like transact is hoping to become the sort of module you're describing. Regards, Bill
on 2005-12-22 15:32
There's also the payment gem, which is designed to do what you indicated you'd like in the original email (abstraction of multiple payment gateways). Currently works with authorize.net. http://rubyforge.org/projects/payment/
on 2005-12-22 16:00
There is also ActiveMerchant http://home.leetsoft.com/am/wiki Current supporting Authorized.net and Moneris, with LinkPoint and TrustCommerce under development. -eric
on 2005-12-23 01:16
Fortunately, this application is dedicated to its own server. YouÂ¹re right though, I wouldnÂ¹t feel great about this on a shared server. The other Rails based commerce site we did, we had the customer use Authorize.net explicitly because of the Ruby integration... SEE MERCHANTS!! RUBY SUPPORT WILL WIN YOU CUSTOMERS! From: David Rose <email@example.com> Reply-To: <firstname.lastname@example.org> Date: Wed, 21 Dec 2005 23:28:25 -0600 To: <email@example.com> Subject: Payflow Pro (was Re: [Rails] FatWreck.com - New Rails Site) Thinking back on it, I realized at the time, and realize again now, that delegating this functionality to a commandline app is a security risk unless you're the *only* user on the server.
on 2005-12-23 01:19
We used this on a different project and it worked great. The customer went with Authorize.net just because of this reason.
on 2005-12-23 09:02
I contacted Authorize.net, but it seems they only allow US businesses. Does anyone know of an international payment gateway that would be easy to integrate with a Rails app?
on 2005-12-23 15:25
I don't know about international support specifically, but TrustCommerce is an excellent outfit, with good Ruby support.