>From php, I've called paybox (, 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

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

The manual is quite good on all these nowadays, start with

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.


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?
> Eric

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to