cancel
Showing results for 
Search instead for 
Did you mean: 

Payment page returns error, but payment data arrives at our server (wpStoreCart)

Hi.

 

We use WordPress and wpStoreCart - a shopping cart solution that has an API that works with authorize.net.

 

Not sure if anyone here knows about wpStoreCart - one other issue is that American Express payments do not seem to work at all, but that's not why I'm writing here today.

 

The issue is that the cart is passing invoice information to https://secure.authorize.net/gateway/transact.dll.

I enter a credit card, and then I receive this message:

 

An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

      This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service.

 

The email contains this error:

 

Your script timed out while we were trying to post transaction results to it. 

 

Now the interesting thing is that our server logs clearly show that the payment information is received by us. We get the approval code, card type, last 4 digits, etc.

However, authorize.net still throws an error message.

 

The data that is submitted to the payment gateway includes x_relay_url and the correct URL to our server - and obviously, that is working since we do receive the payments.

 

When I access that url myself, the server responds (by default with an empty page, but I changed that - see later).

 

During 3 long chats with support, I was given the following information:

 

https://support.authorize.net/authkb/index?page=content&id=A663

which includes a list of troubleshooting steps. I tried all of them and couldn't find anything wrong.

 

The next person gave me this:

 

To begin troubleshooting an error 52 (time out error) please review the following information from our help files: 
-Before doing anything else, have your script start writing to your receipt page. For example: Print your page headers and the first part of the page body. If your script prints to the screen first, we recognize that you and your customer have received the transaction results. 
-Check that your script permissions are correct and that it can accept an HTTPS POST. 
-Check that the script is not completing other functions before writing to the screen such as writing to a database or sending e-mails. 
-Please check to see if there are different processes that are used in your script for approvals, declines, or errors. Check each process to be sure that they write to the screen before any other functions. 
-Verify that your script is not using redirects upon receiving the response from our servers. Redirects are strongly discouraged because they can potentially interfere with the process.

 

The development site says this:

 

if the merchant’s web server does not send a positive response after ten seconds, then the connection will time-out

 

So I'm figuring there's something that their server expects from ours since all is working on our end.

 

So I started following the steps and created an HTML header first thing before anything else happens and throw it out on the page. That works when I open the page directly in a browser.

 

Still nothing...

 

My system is running PHP, but even developers who use other languages might be able to help here.

 

All I basically need to know:

 

What does their server expect as a correct response in order to not call the connection a timeout?

 

Thanks in advance!

 

 

 
rlund
Contributor
1 ACCEPTED SOLUTION
18 REPLIES 18

What is on the relay response page?

RaynorC1emen7
Expert

Thanks for your reply.

 

That's just it - I don't know what SHOULD be on there.

 

Originally, the shopping cart system returned nothing. Then I tried returning "success", then I followed the suggestion in what I'd been given and created a full simple html page that returns "success" inside the HTML body. I did not set any header data - I just started the HTML code.

 

Neither of these has returned a success message from the authorize.net API.

 

So what is it that I SHOULD be sending back to the server?

Now the interesting thing is that our server logs clearly show that the payment information is received by us. We get the approval code, card type, last 4 digits, etc.

However, authorize.net still throws an error message.

 

so authorize.net did post(relay) data back to your site, it expecting a web page in return.

 

 

 

have you try curl the same data to your relay response page and see what the response is?

No, I have not tried that, but that's a good idea!

 

What I HAVE tried is to just open that page in a web browser, and while it won't post any payment data, it does return a full HTML page back to my browser...

 

But I'll try curl and see what happens.

 

I'm still wondering, though, what the API expects to receive as a response...

OK, I just tried re-sending a payment that has worked before, and I received "Success!" as a response. This is what the shopping cart system sends by default.

 

So what else could I be missing?

 

 

No, I hadn't!

 

Thanks for that!

 

I did notice that it took maybe one or two seconds for the "Success!" response to appear, but if I remember correctly, the timeout is listed in their documentation as 10 or 20 seconds (don't remember, but it had a zero at the end).

 

So I can try manually setting the header to 200 and see if that does something.

I'm curious to know--if your site wasn't responding with an HTTP 200, which HTTP response code was it sending?

I can work on updating our documentation to mention we're expecting an HTTP 200, but I'd like a better idea of the use case of forcing the HTTP 200, and why it might need to be forced.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

Well, honestly I doubt it's a 200 issue since the page loads fine in a browser (when I add HTML output like some documentation suggests) and its output also loads fine using cURL...

 

I am grasping at straws here - I'll try anything at this point!

 

To be frank, the owner of the site is considering alternative payment providers at this point - I have probably wasted 8 hours of intensive research and support chats and am no closer to figuring this out. And I know everything works in our direction because the payments do make it to us... It bugs me when a company gets so big that they refuse to have a developer on call for escalated issues :-( It should be so easy for a developer to watch the logs and simply let me know what our site is not doing that it should be doing - a matter of minutes! But no ...

 

Anyway, I don't know what else to do, so I will try to force a 200 header even though I doubt it'll make a difference.