depthq - ccm|mac

I just want to write a short piece to document some of my experiences in working with the Worldpay payment system.

It is pretty similar to Paypal, you just need to POST a bunch of HTML form variables to a URL and its done. Worldpay has an option to send a Payment Response back to your server. Using this response you can do some integration with your backend to identify that payments have been made.

For Worldpay, it works for both single payment transactions or recurring payment transactions. To support this, Worldpay is flexible enough to not charge for the initial transaction and it acts more like a registration step, which is suitable for recurring payment. You can read more about it in Worldpay FuturePay's documentation on Regular Agreement Options.

A lot of information is passed back but I think the following are the most important:

• transStatus
• cartId
• futurePayId
• amount

If the transaction deducts money, it will include a transId.

If the transaction is a cancellation, the fields that are important are futurePayStatusChange and futurePayId.

There is a big list of fields that might be returned in the Payment Response and its documented here.

If the user selected a different currency as you initially set, it will be indicated in the group of variables with the authXXXX convention. Worldpay has also written a bit about their Exchange Rates and how it works.

To fully support the Worldpay FuturePay with dynamic recurring amounts or payment dates, there is a Remote Administration Interface (RAI) that you use programatically. But do note that you need an installation id that is specifically setup for RAI.

There are some security recommendations by Worldpay such as ensure the request is from Worldpay, MD5 security and make transactions more time dependent.

One thing that bugged me is how user defined variables are passed back to the Payment Response. The recurring and cancelled Payment Response would never include user defined variables because they don't store it in their system, as indicate here. So you'll have to create a system that would need to work in a more flexible way for those cancellation and recurring Payment Responses. I suppose this makes the system a bit more robust, but I am lazy and wish that recurring Payment Responses could send me back the user defined variables. I would view that as more consistent and simpler API to use.

Oh yea and finally, you can have a Shopper Response that will be shown to the user once the payment (or registration) is done. The Shopper Response is generated by the same callback that handles the Payment Response but it works slightly differently. It will take the HTML that you generate and then render it as part of their final payment confirmation page. The URL of that page is not the callback that handles the Payment Response but their own URL. Its like they are doing a copy and paste. But the copy is done by reading off the HTML that you generate by the Payment Response callback. Also there are some restrictions because you need to include a compulsory banner code, which will be expanded (or filled in) by Worldpay to include more details.

Worldpay has written some documentation on creating a Shopper Response but it took a while and a lot of reading to understand how it roughly works. I am still scratching my head over it and sort of given up. There is still whole interface that you can use to configure the Shopper Response page and change all the styles and colours but I think its just too damn difficult at the moment and I've kind of lost interest in doing further for now.

Okay I think that is all for now until I figure this Shopper Response crap...