Paypal and Rails

I describe how to do exactly this in my Rails e-commerce book: http://www.agilewebdevelopment.com/rails-ecommerce

The short version is that you have your order form submit to an action in your app that creates the transaction and renders a view with the paypal form filled out and submitted automatically via javascript. This form can then be populated with an invoice number that you can verify at IPN time. You would also have a transaction in pending state for a customer to be able to see immediately.

hate to counter plug, but there's also the small pdf only title 'Payment Processing with Paypal and Ruby ' from Joe Fair. http://pragmaticprogrammer.com/titles/jfpaypal/index.html

I haven't read either yet, so can't really advise, only state the obvious :slight_smile:

Heh, good point. :slight_smile:

Sorry for the late reply.

Another option is to use something similar to IPN called PDT. When the user gets done and PayPal redirects them to your web site PayPal puts a hidden field in the redirect. This field has a token that you can use to directly query PayPal before you build the response page. You can save the results of the query, too.

> hate to counter plug, but there's also the small pdf only title > 'Payment Processing with Paypal and Ruby ' from Joe Fair. > http://pragmaticprogrammer.com/titles/jfpaypal/index.html

Yes, but he's not as responsive in monitoring the mailing lists. :wink:

Joe

According to the PayPal documentation, you are not guaranteed to received a PDT due to various reasons.

That's true. The way I understand it, the reason you *wouldn't* get a PDT message is if the redirect to your site too "too long" and the user closed the browser. I could see that happening somewhat frequently, esp. if you have to receive the token, go get the data, parse it, save it to the database, and build the page before the user gets a response.

To combat this, the PayPal page that the user sees before the redirect says something to the effect of "Don't Close This Window Until It Says Order Complete" and in the PDT docs it talks about the things you should display, including "Order Complete".

Actually, I'm not sure why PDT exists..

At first I couldn't figure it out either. It's not guaranteed, it depends on the user's patience, it's slower, and it's a pain to code up this AND IPN.

However, the problem it solves is exactly the original question: How do I show the user what they ordered on the web page they return to.

If that's what you need, that's what it gives you. The problem is that it kind of appears to be an alternative to IPN, but really it's not. You can use either, both, or neither. If I used PDT I'd also enable IPN.

In my last post I left out what I intended to be the how-to part. - Read up on PDT on PayPal's web site. There is no fee. http://www.paypal.com/cgi-bin/webscr?cmd=p/xcl/rec/pdt-intro-outside

- For api-level detail of IPN and PDT, see the Order Management Integration Guide at

- Enable it for your account on the PayPal web site. That's where you set the landing page.

- Build a landing page controller that takes the token, pulls the data down, and saves it.

- Build the display.

These steps are from memory, so check the facts with the PayPal doc.

One last caveat: PDT requires PayPal to use "AutoReturn" to return the user to your site. If you are selling a subscription and want PayPal to create the username and password, you can't use "AutoReturn", so those two scenarios are mutually exclusive.

Thanks, Joe

Is there a reason for not opting for the “Website Payments Standard” option rather than " Website Payments Pro". The transaction fees don’t seem to be any higher plus you wouldn’t have to go through an API based integration?