Yeah, >From php, I've called paybox (http://www.paybox.de), which is a mobile phone based payment service. You exchange transactions with them via xml.
They have their own "cartridge" for php, but it's just a perl rewrite and not very wonderful, so I rewrote most of it. The basic approach is simply to open a socket to the service, send out your xml, and/or listen for xml from them. To parse the xml, you could try one of the php xml parsers, or if they are simple, known, messages, you could just parse them yourself with a few regular expressions see ereg. If you want to write an xml server, php may not be your best bet although I guess it could be done. The problem with the server is all about multi-threading so you don't force everyone to queue on the port while you're processing each request. I've done something similar with tcl using a simple looping stub that listened on the port and passed off requests to sub-processes asynchronously But if you only need to call, then the functions you need are: fsockopen(), fputs(), fgets(), fclose() You might also want to tweak with socket_set_blocking, socket_set_timeout and socket_get_status The manual is quite good on all these nowadays, start with http://www.php.net/manual/en/function.fsockopen.php If this is communication with an xml server to execute a payment, (as with Paybox), you have to design your transactions carefully if you want to avoid all the problems of duplicate payments, interrupted payments, user cancels, web server goes down in the middle of a transaction, php bombs out, their xml server goes down in the middle of a transaction etc. If you get this wrong, you WILL end up with discrepancies between your record of transactions and your payment providers sooner or later. The good news is that you can make it very robust with php, and with a lot less work than if you had to use Java, C or some similar language. The main tricks are:- a) Make your communication with the xml server a 2-phase commit, so if either of you goes down mid-way, the other one knows and can rewind. b) Record your own version of the transaction in a database and use that to check for duplicates, user cancel requests, timeouts etc. c) Put up a holding page with an auto-submit to tell the user you've started and give them an option to cancel explicitly in case they see problems. In Paybox's case the user was involved in the payment authorisation loop via their mobile phone, so this was essential. If you do this you can safely wrap your code in an ignore_user_abort to give extra protection, while still giving the user a sensible message and their own option to cancel if they feel they are waiting too long. d) Make your sql transaction updates atomic i.e. when marking your transaction as valid include a where clause on the update to make sure it has the expected status and hasn't for example, already been processed from another browser window. That way even if your database doesn't support transactions, provided the database server at least locks a row during update, you'll be safe from transactions switching back to cancelled after they've actually been completed (and vice-versa). The key point is that you can do just as secure and safe a job of commercial-grade transaction processing with the likes of php/mysql etc., as with the hard-core geek tools, provided you get the design right. You have a very good channce of doing a much better job, since you don't have to waste so much time on all their geekery. George Eric wrote: > I have a PHP webstore that I want to call my web service that is running on > an IIS machine. The web service returns XML. > > Has anyone called or written a web service with PHP? > > TIA > > Eric -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
