Overview: All I want to do is have a single PHP script that uses cURL to send a sequence of individual posted transactions one-by-one to a merchant gateway, capture the merchant gateway response for each, and store them in SQL for processing.

Details: Recently, I started dealing with the merchant account provider Authorize.net. When our site posts to their gateway a transaction using a real form, an actual submit button clicked by a user, we're having no problems. The results are coming back intelligibly.

But when we simulate that same form posting using cURL, the PHP script containing the cURL execute is timing out. The desired transaction response spits out as it quits, but it's too late. On top of that, the goal here is to cycle through and send multiple transactions. The application sitting on the A.net server behaves as if it won't send the response until the socket connection is closed, but I can't seem to close the connection until the script times out (which of course is useless for actually doing anything with the data I'm trying to capture). I can have the response sent back directly to my script, or I can tell the system to redirect to a separate receipt page. Makes no difference.

So, logically, I tried connecting to the same page using cURL from the command line, and it seems to establish a socket but then just sits there. Never closes the connection until I break it. This too is useless.

So, next, I head back to PHP, and tried telling cURL to only grab a small number of bytes. No change, times out. Next, tried telling cURL to time out after 4 seconds. No change -- it times out after 30 secs per the PHP settings (same as before).

A little background: Authorize.net has recently changed their requirements (they call their system 'AIM' now), but I was never around back before the change, so I don't actually know if my problem is related to the change or not. The past discussions from this list refer to the old A.net system which called this kind of connection "direct response," but those discussions don't seem to apply to this situation.

Some more info: The URI to which cURL is connecting (or supposed to be connecting) is secure, https, port 443. If I run the same PHP script mentioned above but specify non-secure port 80, I get plenty of response -- the standard forbidden/rejection response. I get a similar reaction if I try to open a socket -- whether port 443 or port 80 -- using fsockopen(), fputs, and fgets.

Anyone have any ideas or have run into this before? A colleage suggested handing the process over to Perl so that PHP could keep executing while the Perl script was free to time out whenever. That struck me as a hack work-around that shouldn't be necessary.

What am I missing? Tell me I'm an idiot, that I'm missing the obvious, plain-as-day point, and I'll be a joyful man. Just tell me what that is.

Naturally, when I call A.net on the phone for support, they seem annoyed and assure me it's not their problem.

Thanks for your help.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-11-25