Paypal PDT

I thought I would follow up my previous post with one that points out some good practices, and potential pitfalls when using really simple interfaces.  The DS Volatility Trends Web site is going to use the Paypal PDT option, where a user will be redirected back to the DS Volatility Trends Web site after payment is complete. The API is VERY simple.  You tell Paypal which page to redirect to, and it redirects to that page with a single get paramer: tx.  You then use this parameter, and your user key to get more information about the tx and to verify it for security purposes.  Here is the output of the response for a first test, run against the sandbox, with user keys omitted:


SUCCESS
mc_gross=5.00
protection_eligibility=Eligible
address_status=confirmed
payer_id=
address_street=1+Main+St
payment_date=09%3A30%3A43+Jan+09%2C+2010+PST
payment_status=Completed
charset=windows-1252
address_zip=95131
first_name=Test
mc_fee=0.45
address_country_code=US
address_name=Test+User
subscr_id=
payer_status=verified
business=
address_country=United+States
address_city=San+Jose
payer_email=
txn_id=8NJ4974863519050H
payment_type=instant
last_name=User
address_state=CA
receiver_email=
payment_fee=0.45
receiver_id=
txn_type=subscr_payment
item_name=DS+Volatility+Trends+Newsletter
mc_currency=USD
residence_country=US
transaction_subject=
payment_gross=5.00

Here is a sample after I inserted a custom value:

SUCCESS
mc_gross=5.00
protection_eligibility=Ineligible
address_status=confirmed
payer_id=
address_street=1+Main+St
payment_date=09%3A06%3A15+Jan+10%2C+2010+PST
payment_status=Pending
charset=windows-1252
address_zip=95131
first_name=Test
address_country_code=US
address_name=Test+User
subscr_id=
custom=12631431526791
payer_status=verified
business=
address_country=United+States
address_city=San+Jose
payer_email=
txn_id=0LG419336A6914908
payment_type=echeck
last_name=User
address_state=CA
receiver_email=
receiver_id=
pending_reason=echeck
txn_type=subscr_payment
item_name=DS+Volatility+Trends+Newsletter
mc_currency=USD
residence_country=US
transaction_subject=
payment_gross=5.00

Can you see the potential issue?  Inexperienced developers often take the first result set and start parsing it, line by line.  Some pseudo-code to represent this:


//Code has other problems besides the one being highlighted...
//Get String from stream...
String[] values = returnString.split("\n");
//now get the values of each line, assuming they are in the correct order
mcGross = values[0].split("=")[1];
protectionEligibility = values[1].split("=")[1];
//continue with all other values..


The code above would break as soon as the new variable is added, since the variable is returned in the middle of the list, all variables after 'custom' will be offset by 1 in the index.  In addition, I don't see any specific guarantee that the order will always be the same (Although that would be a good practice for Paypal to implement...).  At any rate, it is better to handle the values in an order-neutral way.  In Java, I would do this by parsing the string and creating name-value pairs in a Map.  This requires a little more code up front, but will save lots of potential errors down the road.

//Better but still needs work to be robust....


Map values = new HashMap
String[] values = returnString.split("\n");
for(int i=0; i < values.length; i++ ) {
    String[] thisValue = values[i].split("=");
    values.add(thisValue[0], thisValue[1]);
}
//Now values has ALL the values if new ones are added or the order changes,
//we don't care.  We're also sure we set the value with the right key
mcGross = values.get("mc_gross");


As you can see, with the second implementation, the code will still work just fine with the new 'custom' variable returned in the results.  The order of the variables is no longer important, and frankly, I think it is more expressive - mc_gross key is clearly being tied to the mcGross variable.

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.