Create simple management tools for a subscription site. Find your payment gateway, solidify a set of packages, and program the elements to interface recurring payment options with different payment methods. At this point in e-commerce’s maturity, such systems should be dead simple to implement but some jerks are still around to ruin your day in the name of poor management and pursuit of the Yankee Dollar. Enter PayPal.

Let’s just start with educational resources. You have the sandbox development environment to test out your processes, but instructions found in the documentation and forums are constantly vague and sometimes just plain wrong. I felt like I was going mental from the cyclical paths I went through to solve problems. Take, for instance, this message which I received when attempting to process a GetRecurringPaymentsProfileDetails request:

PayPal error code: 11546 “Profile ID is not valid for this account. Please resubmit request with the correct profile ID.”

The PayPal API error codes indicate this error number is “Merchant account is denied” (conveniently with no resolution in sight.) There isn’t a single Google result for the former error messsage or a useful match for the latter. Not a mention nada in the Paypal forums. The problem? The Paypal profile I was attempting to access was creating with another API key that I had since switched. So not only is a very simple and easy to describe error obscured in its report, the support documentation to indicate so doesn’t even exist.

To maintain a local billing history of a recurring payment profile involving credit cards (say, for your site users to reference using your web site rather than Paypal’s), you must develop your own service to accept IPN messages triggered by Paypal’s server. Now how does one test the processing of these recurring payments? The minimum cycle you may set between payments is 1 day, so you must wait 24 hours and over the span of a week to analyze each notification’s success status? How’s that for rapid development?

Now if you want to offer regular Paypal payments rather than just credit cards, there’s always this gem:

For profiles created using Express Checkout, the total amount of a recurring payment can only be increased 20% in a fixed 180-day interval after the profile is created. The 20% maximum is based on the total amount of the profile at the beginning of the 180-day interval, including any shipping or tax amount.

For the Website Payments Pro package at $30/mo with no up-front fees, you cannot have a subscription package increased from $20/mo increased to $40/mo since it’s over 120% of the previous recurring payment amount. It’s still doable with credit card processing but some rumblings I came across on Paypal’s site and its developers forums mention if you offer Visa/Mastercard, you also must offer Express Checkout. I guess I’ll find out whether they monitor sites using Website Payments Pro. As a substitute, you can always upgrade to Payflow Gateway at $60/mo with a hefty $250 setup fee which offers a whole other set of features that are simply not required. All we need is to secure credit card information with an easy method for us as merchants to adjust monthly charges. That’s all.

So the alternative is to find another payment gateway in Canada, all of which are sketchier than Paypal (I guess it’s possible, after all.) An example includes Beanstream, which doesn’t even have any pricing online. Just call up so they pull the snake-oil salesman trick on ya. All I know is that they take away larger cuts per transaction than Paypal that it makes the service not worth using.

Maybe once online merchants get their shite together, small to medium-sized subscription web sites can roll out solutions that don’t generate a multitude of headaches with a side of nerd rage. I even had to write my own socket code in PHP to contact Paypal’s web services!