[Nfb-web] Fwd: Re: [nfbcs] Setting Up a Website to Accept Payments via PayPal

[David Andrews]

>This post from Brian Buhrow on the Computer Science list may be of 
>interest and/or use to some of you here.


Dave



>         Hello.  Jim suggested I get on this mailing list, something I should
>probably have done anyway, serving on the NFBCS board as I do, since I've
>done what Mike is asking about for the NFB of California.  While jim is
>technically correct in that they don't use the exact web forms I wrote some
>years ago, the system they use to this day is, for the most part, exactly
>as I built it some 6 or 7 years ago.
>
>         Let me try and address Mike's points as best as I can.
>
>         There is a documentation section on the Paypal web site and it has
>documents on various ways to build payment systems that talk to Paypal.
>Some of them involve using plug-ins with varius packages while others
>involve purchasing services from third parties that integrate with Paypal.
>What I wanted was a simple html form that could tell Paypal how much the
>buyer was willing to pay, exactly what they were paying for and how to
>determine who paid for what without having to look at Paypal receipts
>directly.  Also, I wanted a system whereby the NFB of California was not
>responsible for handling user credit cards in any way shape or form.  Since I
>did this in 2007, I don't remember how I assembled the
>documentation I did, exactly, but if you browse to:
>http://www.nfbcal.org/~buhrow/pp-standard-variables.txt
>you'll get a txt file containing a description of the various methods for
>submitting html forms to Paypal with all the details I outlined above.
>Although this documentation is older, I assure you it's still absolutely
>relevant since I just finished attending a conference for another
>organization which uses the forms and system I built in the same way.  If
>you're in a hurry and just want to see an example button, using both "post"
>and "get" methods for creating the button, browse to:
>http://www.nfbcal.org/~buhrow/paypal-button-sample.txt
>and you'll get a snippet of html that can be modified and used in your own
>forms page to create donation buttons or registration buttons.
>
>**IMPORTANT**
>If you put this html into a real page, you'll get a submission button that
>will really take you to Paypal and they'll really think you're going to pay
>$15 to the NFB of California.  The submission address in the form is bogus,
>but Paypl will happily hold your money for a month while they figure it
>out.
>**/IMPORTANT**
>
>         Below are notes which document some of the caveats I learned about
>setting up Paypal accounts.  I've done this twice now, so hopefully these
>notes will save others the grief I've gone through when they do their's.
>
>
>1.  The e-mail address associated with a Paypal account is immutable.  Once
>you create an account and assign it an e-mail address, you cannot change
>the e-mail address associated with that account without closing and opening
>a new account from scratch.  This has many ramifications on many fronts.  I
>strongly recommend creating an address which is itself a list that can be
>distributed to  other e-mail addresses or automated e-mail processing
>systems -- see below.  This gives you the flexibility to change the flow of
>Paypal mail as your board changes or as you implement new features on the
>web site -- I'll give an example below.
>
>2.  If you open a Paypal account as a business or as a non-profit, you'll
>be asked to supply documentation proving your status as a business or
>non-profit.  This involves producing documents showing your 501(C) status,
>a cover letter on official letter head and any other documents Paypal asks
>for.
>
>3.  In order to be permitted to transfer more than $500/month from your
>Paypal account to another banking institution, you'll need to have what's
>called a verified account.   this means Paypal needs to know the account
>details for the affiliate account you want to use as the verifying account.
>  Things like account number, routing number, etc.  If you opened the
>account as a business or non-profit, you'll need to make sure the banking
>institution which holds the verifying account recognizes you as a business
>or as a non-profit as well.
>
>4.  All of this verification is done the old fashioned way, i.e. with
>telephone calls, printed papers and US mail.  consequently, getting your
>Paypal account established the way you want is a labor intensive 
>time consuming
>process and something you want to do only once if you can help it. See note
>1 above regarding the immutability of e-mail addresses associated with
>Paypal accounts.
>
>5.  Once you're done with all this banking mumbo jumbo, you can get down to
>the business of setting up donation buttons, registration forms and the
>like.  While Paypal can make the distinction between payments and
>donations, for our purposes, there's no difference since our affiliates are
>non-profits and all payments are, technically speaking, donations.  What
>this means is that you can set up payment forms any way you like.  You can
>embed the payment price inside a hidden field of the button, or you can
>give users an edit box to let them choose how much they want to pay.  In
>either case, by the time they get to the Paypal payments page, Paypal
>knows, from the URL you generated, how much to charge and who to pay.
>
>6.  What I wanted when I set up the registration system for the NFB of
>California was a way to automatically corelate payments from Paypal with
>registration forms from users.  The registrant would then receive two
>pieces of e-mail when they registered: a receipt from Paypal and a
>confirmation of their registration for the event in question.  That
>confirmation would contain their registration preferences and would be sent
>to the coordinators of the event as well as the registrants themselves so
>they could use it as proof of purchase.  The confirming e-mail would not be
>generated until the registrant had completed the payment process with
>Paypal.  The Paypal documentation above says that if you fill in a specific
>form variable with a return URL, the payor will be taken to that URL
>automatically once payment is received.  That statement is false.  What
>happens is that if you fill in that form variable, a button appears on the
>final page of the Paypal process inviting the payor to return to the
>vendor's web site.  I discovered this discrepancy between the manual and
>reality after I  set up the Paypal account with an e-mail address that was
>not a list.  Needless to say, most registrants didn't click on that "return
>to vendor" button and my scheme for generating that second piece of e-mail
>to the event coordinators largely failed.  (See note 1 above.)
>         When I set up the second Paypal account for a second organization, I
>learned my lesson.  That account is setup with an e-mail address that goes
>to a list which includes an automated mail processor which recognizes
>paypal  payment notifications, something Paypal generates very reliably,
>and which can corelate the payment transaction ID with the registrant's
>registration packet and generate that afforementioned second e-mail.  For
>the second Paypal account, the confirmation process works flawlessly
>regardless of whether or not the registrant clicks on the "return to
>vendor" button.
>         I offer that story as a cautionary tale as to just one of 
> the reasons it is
>important to make sure you pick the e-mail address you use with your paypal
>account with care.
>
>         I hope these notes and observations are helpful and I'll be glad to
>answer any questions folks might have to the best of my ability.
>
>Sincerely,
>
>-Brian

         David Andrews and long white cane Harry.
E-Mail:  dandrews at visi.com or david.andrews at nfbnet.org