Theocacao: Ruby, the Payment Gem and Authorize.net

Ruby, the Payment Gem and Authorize.net

I found and installed the Payment gem for Ruby, and fortunately it's built for the payment gateway I'm using, Authorize.net. The problem is that it doesn't seem to handle the "fingerprint" fields that are described in the Authorize.net SIM guide. Here's an excerpt:

The following sample shows the above fingerprint input values and the order in which they are
placed to generate the transaction fingerprint. Input values must be ordered as shown in this
sample, otherwise the gateway-generated fingerprint will not match the merchant-generated
fingerprint, and the transaction will be rejected.

Example values for the fingerprint parameters are:

x_login = authnettest
x_fp_sequence = 789
x_fp_timestamp = 67897654

The guide also lists x_fp_hash as a required field. I looked at the source for both Payment::Base and Payment::AuthorizeNet, and neither have any code relating to these fields.

I just have to wonder, is nobody actually using the Payment gem? If it is being used, how are people getting around the requirement for sending a fingerprint during a transaction? In PHP, I used a library called simlib to generate the fingerprint fields.

Ruby, the Payment Gem and Authorize.net
Posted Oct 20, 2005 — 4 comments below

daniel — Oct 21, 05 447

Maybe ignorance is bliss, we just deployed http://www.autumnriderstees.com/, a rails app to sell biker t-shirts, and we use the payment gem, we don't setup the sequence or timestamp specifically. The orders get through and appears in the Authorize.net account without a problem. We get a confirmation authorization code back. In other words, it just works. I can look deeper into it if you want.

Craig Hockenberry — Oct 21, 05 448

I'm planning on using the Payment gem in an upcoming project -- I have looked at the documentation, but haven't actually used it yet.

From my experience with Authorize.net's API on other projects, there are a lot of features that can be ignored. I've never used the MD5 fingerprint and it's never stopped me from processing transactions :-)

I suspect that the Payment gem is only doing the ADC Direct response over a SSL connection. It's not bothering to verify the transaction results from the authorization source.

That's not a big deal, in my opinion. If you've established the SSL connection to secure.authorize.net, it's pretty much guaranteed that you're talking with the authorization source that you'd expect.

Daniel Lyons — Oct 21, 05 449

Same here. I implemented a custom "AIM" transport for my company last year. I don't remember anything about "fingerprints" and so we're definitely not using that functionality, but yet we're processing transactions every day, so it's clearly not a necessary requirement.

One thing I noticed was that the AIM implementor's guide was often vague about the distinction between recommended and required.

Fred — Apr 03, 06 999

Simple answer: x_fp_hash is not needed for AIM, which is what the Payment gem uses. However, this does need to be calculated for SIM.

Comments Feed

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.