Sunday, January 10, 2010

Paypal Integration

Paypal API

I've had to set aside my Android project temporarily to help out a friend.  He has been working for years on refining an algorithm that uses the VIX to increase the ability to predict the volatility in the market.  He has gotten it to a point where it is accurate and reliable, and is starting a service for institutional investors.  Since he's just starting, but he's serving business clients, he wants to be able to take payments over the Web.  The site will be up soon - DS Volatility Trends.

So, instead of working on learning Android, I've been learning the Paypal interfaces.

How has this gone?  A little frustrating, to be sure, but when I think about it, Paypal is a company that really knows their market.  When I first started looking at the interfaces, I was irritated.  The documentation was plentiful to be sure but a lot of it was at a high level, or very watered down.  In addition, I had to continually re-interpret the documents because the terminology mixed metaphors.   For instance,  all interfaces they offer are referred to as APIs.  As a professional developer, when I hear the term API, I immediately think of method calls and returns.  When I hear the term Service or Web service, I immediately think remote connections and these days SOAP or RESTful requests and responses.  While Paypal offers all of these things, they seem to all be called, API.  While technically true, it was a bit of a shift to adjust my thinking.  Perhaps I'm getting too old.

After reading the documentation, and working to set up DS Volatility Trends to interface to Paypal, I believe that Paypal has set up its site to target its core customers - very small businesses, home shops and others who can't afford large development staffs and investment in infrastructure to support the necessary security needed to take payments and process credit cards directly.  They are often integrating Paypal themselves.  My experience with small businesses that have spoken to me about consulting is that even when they do outsourse, they will often go with the 'cheapest route' as well, which, often means young, inexperienced developers.   The reason all the terms are unified is to make it easier for people who don't spend all day coding to grasp the offerings and help them improve it.  Once I realized that, I was much less frustrated.

In fact, may of the Paypal features are innovative and unique.  The code generation features are complete.  The pages allow you to customize some of the Look and Feel, and there are REAMS of documentation.  Almost too much.

Suggestions for Paypal Developers

Here are a few suggestions for those of you who may be starting off with Paypal integration for the first time.

  •   Set up your sandbox environment and accounts FIRST.  Do this immediately.  Before you generate any buttons for production, before you get the keys for your site (or your clients site), before you do anything.  Set up a developer account in the sandbox, and set up a test client account and test merchant account right away.
  • Externalize your Strings!  This is always a good practice, but since Paypal sets up a production version and test version, and you have different URLs, account keys, account names, etc, for the production and test, it is critical that your strings are externalized so that you can easily build for test and production without having to hunt down all the configuration to change.