March 13, 2007

Switching from PayflowPro to PayPal Website Payments Pro

Filed under: .Net,PHP,Programming,T3city — pj @ 10:32 pm

Way back in 1996 I created an e-commerce web site for a small software company I owned. The system allowed customers to purchase and download software our web site. To make the system appealing and easy to use for buyers, we processed credit cards automatically. Back then, there were no Internet credit card processing gateways, but I was able to purchase some rather expensive software that allowed my computer to emulate a credit card terminal. The software used the computer’s modem to call a modem bank at the credit card processor and complete the transaction. There was a way to automate the software via text files and command lines and that’s what I did. It was slow, but it worked.

Eventually, my credit card processor teamed up with one of the first companies to offer an Internet credit card processing gateway, Cybercash. I hopped on board as one of the first customers. As with a lot of APIs created by hurried teams of inexperienced programmers, Cybercash was much more complex than was necessary to accomplish the simple task at hand. Credit card processing can be really simple: Pass the credit card processor a list of required fields and get back an Boolean success code and an error message.  HTTPS is a fine protocol for this type of stateless transaction that must occur over a secure channel. Input fields can be passed as a URL encoded query string. The error code and error message could be returned an HTTP response code or via a URL encoded fields in the response body. The modern, fancy name for this type of transaction protocol is REST. Under the hood of its overly complex API, Cybercash used the simple REST protocol I described earlier. Liked a lot of other Cybercash programmers, I eventually figured this out on my own and bypassed the complex and cumbersome API to use the simple REST protocol.

Time passed on and Verisign bought up all kinds of important technology related to e-commerce. They purchased Cybercash and started promoting their own gateway API, PayflowPro. Several times, we researched the fees and APIs offered by the various vendors. PayflowPro was the best and the one we used and recommended. The PayflowPro API was a tad bit easier to use than the official Cybercash API – easy enough that instead of bypassing the API for the REST protocol, I used the actual PayflowPro API function calls.

When the time came to automate the billing for T3city, I started out with PayflowPro. However when it came time to get a new merchant account, I took some time to review my options. On paper, PayPal Website Payments Pro looked pretty good – they have a nice and simple fee structure (unlike PayflowPro with all sorts of fees billed out at different times) and the fees are competitive if you can get your volume over $3,000/month (and not too bad if you can’t). The sign-up process was all online. I figured it couldn’t be too hard to change gateway APIs – I’d already used several others – so I made the switch.

Well, I was wrong about the difficulty level associated with switching from PayflowPro to PayPal. The PayPal API is much more complex. First, there is the fact that the API is SOAP based. In addition to the more complex SOAP protocol, the PayPal programming examples use another layer on top of the native SOAP API. Why they add this extra layer, I really don’t know – maybe it’s just a fact that every junior programmer feels like an extra layer or two will make things simpler. It doesn’t make the API any easier to use. In fact, I found the differences between the new layer and the documentation for the base SOAP protocol very confusing. In the end, I elected to ditch the PayPal examples and use PayPalSvc.wsdl and .Net’s SOAP support tools to generate my own SOAP client for the PayPal API. The resulting API is a little awkward is spots (mostly due to PalPals not so hot API design), but at least it matches the detailed and fairly comprehensive PayPal SOAP protocol documentation.

Once you get over the base complexity of the PayPal SOAP based API, then you have to deal with the stateful nature of PayPal. Credit card processing is normally a simple transaction, but the PayPal Website Payments Pro program requires that you offer your customers the option to pay via PayPal. And, what the heck, allowing payments by PayPal is not such a bad idea.  However, unlike a simple credit card transaction, payments with PayPal naturally flow over a series of pages, some on your site and some on PayPal’s site. Information such as billing and shipping addresses and invoice line items have to be exchanged in a delicate dance. Assuming you are willing to tackle the complexity of proper error handling, avoiding browser complaints about HTTPS redirects and giving the user the ability to cancel cleanly, getting PayPal transactions to flow smoothly turns out to be a fairly complex.

Is the extra complexity worth it? Consider these points:

  • Both gateways are very reliable. 
  • PayPal fee structure is simpler, clearly specified on their web site and may be less expensive – YMMV. Traditional store fronts may be able to get better rates from their current processors with a different gateway API.
  • PayPal charges the same fees for all types of credit cards. AMEX fees are usually higher, so this may save you some money, but, again, YMMV.
  • PayPal does not require any type of term or volume commitment
  • Accepting PayPal is nice – giving customers more ways to pay you is a good thing!
  • Implementing PayPal Website Payments Pro is a good deal harder than using PayflowPro. Depending on your web site/application, adding stateful credit card / PayPal transaction processing may require adding new database fields, new screens and other large scale programming changes.
  • Under .Net, PayPal Website Payments Pro does not require any native (non .Net) code. To use PayflowPro in .Net, I load and make native function calls into the native PayflowPro DLL.
  • PayPal Website Payments Pro requires full names for states (not the typical 2 letter codes) and proper ISO country codes for every transaction. If you don’t already have validation in place and tables to translate state codes into state names (users will use 2 letter state codes if you let them), this support will require additional programming work.
  • With PayPal Website Payments Pro, you have to perform an additional step to transfer money from your PayPal account into your bank account.  Funds from credit card purchases show up in your PayPal account immediately, but transfers to your bank account take multiple business days (similar to the delay you’ll have with a traditional merchant service provider and PayflowPro). In theory, you can use funds in your PayPal account immediately for purchases via PayPal, but you would need a careful strategy to ensure proper accounting.
  • To credit a customer via PayPal, you must create a new credit transaction that references a special code from the original sale transaction. Unlike PayflowPro, you cannot void a transaction and you cannot change a sale transaction to a credit transaction.
  • PayPal has different and likely much more strict fraud protection measures. Overall, I like this capability, but it did cause some pain during our switch when credit cards on file from long term customers no longer worked because of mismatched a CVV number, a mistyped expiration date, etc..

8 Responses to “Switching from PayflowPro to PayPal Website Payments Pro”

  1. Really good article. found the info very useful and it has helped my boss and I on our way to making decisions regarding a potential switch to paypal pro!

  2. Thanks for the write-up here. You make some interesting points. I actually found this site looking for an answer to this question:

    if I am using the Payflow_dotNET.ddl for my ASP.NET 2.0 web-app how should I pass State and Country values for the BillTo and ShipTo objects? Should I use the 3 digit ISO codes for country and the two-letter ISO codes for state, or should I pass them as “United States” and “Illinois”? Maybe it doesn’t matter either way.

    Any help would be appreciated. Thanks.

  3. pj says:

    I’m copy and pasting the actual code I use below:

    AddressType address = new AddressType();
    address.Street1 = CreditCardAddress1;
    address.Street2 = CreditCardAddress2;
    address.CityName = CreditCardCity;
    address.StateOrProvince = CreateStateCode(CreditCardState, “DoDirectPayment”);
    address.PostalCode = CreditCardZip;
    address.Country = CreateCountryCode(CreditCardCountry, “DoDirectPayment”);
    address.CountryName = address.Country.ToString();
    address.CountrySpecified = true;

    PayerInfoType payerInfo = new PayerInfoType();
    payerInfo.Payer = !DbRequest.Singleton.RequestUser.IsSuperAdmin && !DbRequest.Singleton.RequestUser.IsBillingAdmin ? DbRequest.Singleton.RequestUser.Email : null;
    payerInfo.PayerName = name;
    payerInfo.PayerCountry = address.Country;
    payerInfo.Address = address;

    As you can see, I use the codes for states and countries, but also fill out the CountryName field. I don’t know for sure that you need both Country and CountryName filled out. The code is working as it is. Weird that PayerInfoType has both PayerCountry and Address (but no PayerCountryName field)…

  4. John Wilkins says:

    Hi PJ,

    I did some Perl-based CyberCash integration in 1998; it really was a convoluted API. Unfortunately, I’ve now got a client who wants to convert a ColdFusion-based CyberCash site to PHP. (Leaving aside the obvious fact that they are insane and should switch to a new payment gateway…) Do you have any/know of any docs on the REST protocol for CyberCash? There is a dearth of information on the net about CyberCash docs.

    Thanks! – John

  5. pj says:

    Hi John,

    Wow, good old CyberCash. When I worked with CyberCash, it included the C source code for its client API. Perl source code was included as well, but it used the C link library. I used the C source code to figure out the protocol. I assume others did the same. It was pretty simple stuff… just URL encoded name value pairs via HTTP with some (non-SSL) encryption on top. I have no idea if that source code is still easy to get or even if the API would be the same. There is/was a CyberCash extension for PHP. I just checked Google. The PHP extension I saw assumes you have the C link library from the CyberCash SDK – maybe that is not such a bad option (assuming you can find the C link library). The name/value pairs you pass and receive via PHP should be the same ones they used in Perl.


  6. John Wilkins says:

    Hey PJ,

    Thanks for the followup! It turns out my client was confused. They said PayPal (the current owners of CyberCash) made them switch last autumn to one of PayPal’s payment methods, PayFlow ProPlus or something… :-)

    – John

  7. I am happy to see that my reluctance to switch from payflowpro to paypal API is shared out there.
    Unfortunately I am based in Europe and our products has to be sold to customers all over the world. The current strategy by paypal is to promote paypal (of course) and therefore they do not offer anymore payflowpro outside USA!!!
    How can I continue using payflowpro and bind it to European bank accounts? Am I forced to change ?

    – Massimo

  8. Jake says:

    Do you know if certain cards will decline if State or Country is not sent via Payflow pro?

Leave a Reply

Powered by Teztech