Discovering the problem problem.

[AaronHildebrand]

Okay folks;

This one's a bit strange, no I'm not asking for help with my implementation directly, but I am wondering if there is a way to see the FULL RESPONSE that the RECEIVING SERVER is sending to AUTHORIZE.NET on transaction to generate the beloved phrase:

"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."

Silent Post URL doesn't do what I'm looking for either, just a heads up on that.

Again, I am not looking for Authorize.Net's lovely statement above, what I am looking for is what the page is sending (preferrably verbatim) to ANET that's generating the lovely statement above.

Also, is there a way to produce some dummy data to send to the receiving point to test this directly? I know you can inject it into the head, but I need a dummy sample to do a header injection (effectively a fake POST right in the browser).

[RaynorC1emen7]

Not sure what you asking for at all.

But you get that error when the relay response is not working correctly.

See if the following help

Relay Response Basics and Troubleshooting

And you can use this as the relay response URL to see what was return from authorize.net

Post Data Validation URL

To get some dummy data, use the above post data validation url result and use those fields to post(post it in code-use the AIM example) to your relay response page.

[AaronHildebrand]

The problem I have is that I can't get any loggging in this particular area (a point of acute frustration for me at this point) and all the API passes back as an error is "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." on the page and "Your script timed out while we were trying to post transaction results to it."

These two things could mean anything really, and without knowing exactly what error's being triggered I'm simply going around in circles chasing my tail, it's driving me to distraction.

The dummy data idea is another means of trying to extract what is wrong, because if I manually post a false post header that has all the fixings of a proper ANET response it should show me where the errors lie. (The reason for this is that error reporting will give a 'Bad Request' response if it's cold-called)

[AaronHildebrand]

Additional:

This is not the request that's faulty, it's the response reciever, so unfortunately pre-checking on the way in is going fine, but the response receiver is failling somehow and I have no means of finding out how at this point if the API doesn't pass anything back.

[RaynorC1emen7]

It not getting log  because authorize.net can't access it for some reason. You might able to see it trying to get access at the your web server http log.

Did you do all the thing it said to check?

Relay Response Basics and Troubleshooting

Are you using asp.net? add this EnableViewStateMac="false" to both the form post to SIM and the relay response page 

And what is on the relay response page?

[AaronHildebrand]

I understand that it can't access it, I also know that it's timing out in less than a second so it's not hitting the ten second problem, so that means it's not sending a response code 2XX back.

What I don't understand is why, and that's not really something I can ask about here, so what I am asking about is if there's a way to see what the API is seeing when it attempts to pass the postdata to the site.

Okay, let's go through the checklist:

• Check that the Relay URL:

Relay is dynamically generated and enters into the form correctly

• Confirm that you can load the Relay URL in a Web browser:

Loads, this is what I need the dummy data for because the page it loads fires off a 'Bad Request' if it's cold called by design.

• If the merchant’s Web server is not available on the public Internet, has authentication enabled, or if the Relay URL uses a non-standard port for HTTP or HTTPS:

Server is on the internet, It's got a self-signed certificate at this time (it's a test server) and the relay URL uses standard HTTPS.

• If the relay response page is using an SSL connection, ensure that the SSL certificate is valid and is from a trusted issuer. If Authorize.Net’s server cannot validate the certificate, it will abandon the connection.

Again, it's a self-signed cert, if this is the issue I don't know how to fix it on our testing area and it cannot at this time be tested live (due to the live system being in use)

• Log into the Merchant Interface at https://account.authorize.net/, click Account from the top navigation, click Response/Receipt URLs, and review the settings to ensure that the correct Relay Response URL is configured.

As per prior discussions, this is shut down intentionally so that it goes to the correct location.

[RaynorC1emen7 · Accepted solution]

it is a self signed cert. that would be the problem as authorize.net probably getting a 403 error.

can you change that to just http for testing?

[AaronHildebrand]

Now I'm getting an error 14, at least it's something, but this brings us back to the problem of "this is a dynamic URL so I can't predefine it in Authorize.Net's settings"

[RaynorC1emen7]

remove the relay response URL setting on your merchant account.

[AaronHildebrand]

Okay, it says that relay can be used without setting a default, but I'm still getting a 14 error...

There's nothing in the following locations:

Account -> Response/Receipt URLs

Account -> Relay Response

Account -> Silent Post URL

So where is it catching?