Alas, WorldPay Junior is a piece of shite. Their support sucks, and the callback API is utterly crap. If you want to take the customer details yourself and then pass it to WorldPay behind the scenes, then you must use either WorldPay's Java or their Microsoft COM APIs. You'd think that in the 21st Century, they'd have heared of SOAP. | [reply] |
| [reply] |
Well, put it this way - this thread reminded me of a question I needed to ask them, so I sent off a mail a few minutes ago, and this is the response I got:
Your message
To: sales@asiapac.worldpay.com
Subject: Alternatives to WorldPay Junior
Sent: Tue, 27 Dec 2005 22:57:01 -0000
did not reach the following recipient(s):
Andrew Black on Tue, 27 Dec 2005 22:57:11 -0000
The message could not be delivered because the recipient's mailbox
+ is full.
exchange.cam.uk.worldpay.com 5.2.2
These guys advertise themselves as an enterprise-level service backed by the world's fifth-largest bank - but emails to their main Asia-Pacific sales address bounce. Would you trust your ecommerce payments to them? Hardly enterprise-ready, are they?
| [reply] [d/l] |
That is not my experience: I have analysed the WorldPay callback process carefully, and have been able to satisfy myself that it can be made secure, which isn't always the case.
Maybe our needs are different, but I had no problems coding to it, and our clients have reported no problems getting support or getting their money.
They are not the cheapest payment processing service out there, but the cheaper one that I investigated at a client's request turned out to be entirely insecure (ie there was no way to write the client code so that the callback could be confident the ordered goods had been paid for); when I pointed this out to them they agreed, but affirmed that they had no plans to change it.
Hugo
| [reply] |
Hugo, it's not hard writing the callback, but why should I have to write one at all? WorldPay do not offer a solution where you can take all of a customer's details (including Credit Cards), submit it to them and have the transaction validated behind the scenes - other than using Microsoft COM or Java.
Instead, you have to take customer details, redirect them to the WP site, and then wait for a callback to find out whether the payment was successful. Callbacks aren't very robust. What if your web server goes down between taking the order but before the callback approval is received? WP callbacks don't keep "retrying." They get sent once (unless they've changed the system since we last used it). That means the customer has paid, but we have no acknowledgement of it
If you take an all or nothing system - we do everything at our end, including verifying the payment via a web service (SOAP, REST or whatever), either we've taken the order and validated the payment, or we've gone down (not nice, I know, but at least the order isn't in an unknown state)
| [reply] |