#railscast

i am now depressingly intimate with navigating paypal's dev, docs and sandbox site. here is the workflow of how paypal works:

you create a paypal button on your site which uses a POST route to their site with a bunch of site-specific information, including a notify_url attribute which upon completion of transaction routes a notification back to your site asynchronously.

using SSH i encrypted this using a certificate that is pre-loaded with the buyer account at paypal

the purchase information is de-encrypted and read by paypal

user completes the transaction on paypal's site

everything up until this part works perfectly.

a notification, called IPN should be sent to my website using the notify_url param that was passed to it in my initial call. but my site is never receiving it or is rejecting it.

possible solutions:

the notification is definitely being sent by paypal, because there is a record of it at paypal.

the doc says here that ""Your listener returns an empty HTTP 200 response to PayPal." what does that mean? how does that occur

once that happens, then paypal sends the exact same thing again.

also, the doc says "the message must contain the same fields (in the same order) as the original message and be encoded in the same way as the original message."

what does that mean?

EDIT feb 25

I think what happened between railscast 143 and today (and it's been five long years), is that in the episode, ryan bates made it sound like paypal's first postback was not required; in other words, in the past, it seems like paypal did not send a first postback to your site. instead, it just sent you the purchase information and it was up to you to verify whether it was from paypal or not.

that's no longer the case. it is now standard for paypal to first send you a postback, which you then have to verify by sending back an empty 200 request. then your site posts the unaltered message, except preceded by cmd=_notify-validate to paypal. paypal then sends you either a 'valid' or 'invalid' response.

seems like there's an extra security step there that wasn't addressed by railscast.

that's the problem, i think.

this link might be key: http://stackoverflow.com/questions/14316426/is-there-a-paypal-ipn-code-sample-for-ruby-on-rails

EDIT feb 26

ok found the problem.

here's a snippet from the original code from railscast 142:

values = { :business => '[[email protected]]', :cmd => '_cart', :upload => 1, :return => return_url, :invoice => id.to_s + 'h', :rm => 2, :notify_url => notify_url, :cert_id => '[YOUR CERTIFICATE#]' }

The following is a guest post by David Rodriguez and originally appeared on his blog. David is currently a student at The Flatiron School. You can follow him on Twitter here.

The past couple of weeks I’ve been engaged in what could be best described as a love/hate relationship with the Rails console. I’m not alone. At times, it can be your best friend, other times it can leave you bewildered, frustrated, and wishing you had a bat. But it’s not always console’s fault, you have to know how to help console help you. There are a few tricks which can go a long way to helping you do that. Following are a few of the more useful and interesting ones.

Let’s start with a few oldies but goodies. reload! will reload your Rails environment in the console enabling any changes to your app’s models to be reflected. Much less annoying than exiting and then restarting the console every time you make a change. If what your seeing in the console output just doesn’t make any sense, it may not be a bad idea to execute reload! just in case your console environment needs updating. No guarantees but every so often it does the trick.

When you have a need to experiment but are worried about placing your database in great peril, have no fear, rails c --sandbox is there to alleviate your fears. Starting the console with the --sandbox option places your console environment in “sandbox” mode. Any database changes which occur while you’re in this mode will be rolled back when you exit. You can be as reckless as you want. Rails console has you covered.

In Rails console, the underscore, _, has never been more useful. In console, _ represents the output of the last command run. How often do you run a command with the intent of assigning the output to a variable but forget the variable assignment. That is situation where _ shines. You can assign the aforementioned variable with the command output by entering foo = _.

Now for one of my favorites. It’s very easy to remember, the letter y. If you place a y ahead of your command (y User.first), the output will load to YAML. The resulting formatting makes the output immensely easier to read. This works with most model objects and data structures. y is worth it’s virtual weight in gold when dealing with nested hashes.

helper can be used to access Rails helper methods in the console. For example, helper.pluralize(3, 'dog') results in "3 dogs". helper.number_to_currency(25.32) results in "$25.32". helper.link_to 'Sign out', '/sign_out' results in "<a href=\"/sign_out\">Sign out</a>".

The app object can be used to access your controllers through the console. For example, app.new_user_path returns "/users/new". app.cookies returns a Rails CookieJar object with which you can access session cookie data.

When I decided to switch to redis as a backend for I18n, it seemed like an obvious choice. Everyone else was doing it! There is even a great railscast walking through the steps.

So I jumped at the chance, hoping for a quick way to decouple editing the copy on our site from the deployment process. According to what everyone was saying, because Redis is an in-memory data store I could use it without worrying about cacheing.

Imagine my chagrin when performance spiked. I really wanted this feature, but just by turning it on, loading times on many of our critical pages jumped 100-200 milliseconds.

And it was obvious why, after a few moments thought. There are sometimes hundreds of translations to be run for a given request. Each of those translations represented a round trip to redis... even for the same translation!

Redis might be in memory, but it's remote memory. That's still a round trip.

Thanks to a short and helpful StackOverflow conversation with Chris Heald I realized that it would take a very small step to memoize the I18n backend. All of the translations would quickly be cached into local memory, thus eliminating the latency problem.

All that was missing was some sort of cache bust, so that we could change the translations without restarting the servers.

The result of my efforts is rolled up into the cached_key_value_store gem. This is a very light wrapper around the existing I18n KeyValue backend (the one from the railscast.) This means it should work with any key-value database client with a hash-like interface.