Payment processing in the region and PayPal integration woes

From mid March, companies in Croatia can finally receive electronic money transfers via PayPal (read background story in my article published in Nacional).

Payment processing isn’t something new in Croatia, but PayPal is. On-line stores were able for years to process user credit cards via some of our local popular credit card processing services like T-Com Pay Way or Webteh – WebPay (or directly through connections with each bank – less popular method). But only recently (a year ago), with arrival of Kolektiva and similar sites oriented to wider online consumer public, online payments started to become more popular, widely accepted and less frightened to a regular Joe.

In our e-commerce web development work so far, we had chance to work in close with following regional internet payment service providers:

• T-Com Pay Way (Croatia)
• Webteh – WebPay payment gateway (Croatia)
• PBZ MyCheckout (Croatia)
• EMS (Serbia)
• qVoucher (Serbia)
• Telemach – EON MegaPOS (Slovenia)
• direct connection with various banks in the region

And just recently – the PayPal.

No matter PayPal is mature product, integration was not walk in the park. From developers standpoint, I would definitely commend T-Com Pay Way, Webteh and qVoucher services for ease of integration and support they have. In contrast to PayPal’s undocumented features (or lack of documentation and examples) or EMS’s infinite redirects to 3rd party pages (enforced by other parties) in payment process.

PayPal
After some headache & time spent at the PayPal sandbox (self-contained environment within which you can prototype and test PayPal features and APIs) we finally managed to get it working.

We used widely used HTML way to integrate Website Payments Standard with our shopping cart (please see “Third-Party Shopping Carts – The Cart Upload Command”) since integration via API has been proven to be more complex and undocumented than Facebook’s SDK.

For security we used Encrypted Website Payments (please see “Protecting Payment Buttons by Using Encrypted Website Payments”.

Encrypted Website Payments relies on public-key cryptography using OpenSSL which is available both as external program that can be executed from PHP and as php extension. Prepare to enter world of pain with this one, since most of examples use executable file to do actual encoding.

Using OpenSSL as extension with PayPal is not straightforward, best example can be found at PayPal SDK in php toolkit.

We implemented support for both IPN and PDT notifications:

• PDT (Payment Data Transfer) – is secure method to retrieve details about PayPal transaction after (and if) user chooses to return to our site after paying on the PayPal. It should be used only to display information to the user. Our system is not depending on it since there is no guarantee that this action will be executed.
• IPN(Instant Payment Notification) – is direct PayPal to our system communication. In order to verify authenticity of IPN data received from PayPal should be checked and then sent back to PayPal in exact order it was received. PayPal should respond with “VERIFIED”.

Please note that although PayPal send newline as CR+LF (%0D%0A), PHP returns these new lines as LF (%0A) – so, newlines transformed by PHP into LF must be replaced with CR+LF before data is sent back to PayPal. This bug can easily be reproduced if you enter both Address line 1 and Address line 2 during payment, because those two lines PayPal combines into one field separated with CR+LF.

You can try all all this, or you can just contact us for consulting and/or implementation services. :)