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.
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:
- URL of gateway.
- HTTPS communication with gateway.
- Credentials to identify merchant (eg. terminal ID, merchant ID, etc.)
- 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
From: “Chris G.” [email protected]
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
There is also ActiveMerchant
http://home.leetsoft.com/am/wiki
Current supporting Authorized.net and Moneris, with LinkPoint and
TrustCommerce under development.
-eric
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 R. [email protected]
Reply-To: [email protected]
Date: Wed, 21 Dec 2005 23:28:25 -0600
To: [email protected]
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.
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/
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?
I don’t know about international support specifically, but
TrustCommerce is an excellent outfit, with good Ruby support.
We used this on a different project and it worked great. The customer
went
with Authorize.net just because of this reason.
Please feel free to contact me