I''ve looked into this a little bit for a client. I will be
implementing this though the timeframe is a little bit hazy (The
client wants to launch in august and I have a full time position
slated for the summer, and finals till then, so this will be a spare
time gig). My research so far suggests the following approach:
1. Use a custom buy it now button to transmit the data to paypal (in
my case, one shot per shopping cart). This can be configured to do
shipping/tax on the paypal side (convenient, if a little inflexible)
or it can be done locally. Pre-filling of information from previous
sales is possible.
2. When paypal autoreturns, it can send a token to the autoreturn page
allowing data describing the sale to be retrieved (PDT). This data
should probably be logged in full and processed selectively (things
like shipping address are in here. That sort of thing should be kept
in the database for auto-form filling next time, etc.)
3. Paypal sends (via GET) IPN (instant payment notification) token to
a separate URL. This token can be used to retreive the payment data.
Note that the sale might have cleared and been marked complete in the
PDT page allowing for instant confirmation, else it would be marked
pending and the IPN would provide the full notification. I believe
that the IPN comes through either way, but haven''t verified this.
At this point the order tracking system can do what it wants as all
paypal-involved parts of the transaction are complete.
Thankfully, the protocol for all this is very simple. As far as I can
tell, IPN responses and PDT responses follow the same general format
and shouldn''t require more than String#split and an URL decode
function to parse.
Since the paypal system is much more controlling than something like
Payflow Pro or Authorize.net, I don''t know how well it would fit into
the existing payment architecture. Its greatest strength is that it
can be relatively secure (esp. with an encrypted button, but even
without) without the user needing SSL. It can also provide a
moderately well-branded checkout that redirects back to your site and
(more recently) doesn''t require paypal registration.
As I see it, it would be more fitting to implement paypal handling
support as a set of helper functions (for views and controllers) that
did the parsing (into a Hash) and the POST requests for PDT and IPN
(using net/http). Since rails is threaded, this could probably all be
done synchronously (the only point of concern being PDT, due to the
interactivity, but that could be timed out).
Basically I''ll be writing this sometime between now and August. If the
client allows me to release the code under a BSD-like arrangement,
then I will. If someone has a more urgent need for this sort of
processing, I''d be glad to help out in any way I can. I''ve
spend a
good deal of time researching the system and understanding its issues,
though I haven''t interfaced to it yet.
Sorry about incoherentness...it''s late in these parts.
Brian
On 4/19/05, Rick Bradley <rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org>
wrote:> * Raymond Brigleb (ray-THGPwszTed5CpjqP0VxSwUEOCMrvLtNR@public.gmane.org)
[050419 10:50]:
> > I''m writing an application to manage art sales on websites
and will be
> > using PayPal. Has anyone written any code that deals with PayPal,
> > either with IPN or PDT or such? Just checking... this is a wheel I
> > don''t want to invent!!!
>
> Not exactly what you''re looking for, but I just turned a website
> (http://www.lawskills.com) from PayPal IPN to free access this morning
> and was planning on releasing the crufty-ass old source code (actually,
> as well as the statute data and caselaw data). I wrote a Perl module to
> handle the IPN notifications (and to complete the loop w/ PayPal), while
> verifying that items (actually subscriptions in my case) bought
> corresponded to items in my database. The Subscription case is slightly
> different from the Sale case with IPN, but not vastly so.
>
> A Ruby version would probably be about 1/10th of the size of my nasty
> old Perl code, but you''re welcome to look at the Perl version if
you
> think it would help you write a Ruby one (anyone, actually). I was
> planning on opening this code up anyway, but on a when-I-get-time
> schedule. I could send a copy of the IPN stuff right away though.
>
> Rick
> --
> http://www.rickbradley.com MUPRN: 443
> | thus actionable
> random email haiku | under section 301(b) of the
> | Trade Act. See FR (Aug.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
--
The years ahead pick up their dark bags.
They move closer. There''s a slight rise in the silence
then nothing.
--
(If you''re receiving this in response to mail sent to
bluczkie-OM76b2Iv3yLQjUSlxSEPGw@public.gmane.org, don''t be concerned
This is my new address,
but mail will be forwarded here indefinitely)