Odd timeout and invalid card number error?

[hav]

Recently went live on a client's server using DPM.  Everything seemed find during testing.  Tested with his acct in test mode - then turned on and used test argument - then went fully live.

I believe some payments have been fine - but several have acted very odd.

First there is a message that the card number is invalid

Then a message that his server script (I am assuming the relay page) timed out

Then the purchase seems to go through just fine and the card is valid??

Has anyone seen anything like this?

I just modified the Timeout and MaxKeepAliveRequests on his server to see if it has any effect butit seems like we would have seen such a timeout at least once during the testing we did - so not very hopeful this will fix the problem.

Anyway - always - thanks if you have any thoughts.

[RichardH]

Hello @hav

This sounds like a relay response error meaning Authorize.Net is able to process the transaction, but the server is unable to POST back to the relay response URL you specified.  You can review some troubleshooting steps here. 

Richard

[hav]

Thanks Richard ...

We have tried live purchase tests and they seem fine - so perhaps this is indicating a problem in the way we are handling the error conditions in the relay page?? Typically, we pop off a note to the merchant about the error and abort the relay page (cleanly but perhaps, prematurely??)

Or perhaps this is just what we should expect when someone enters a bad card number - then, corrects the number and resubmits the order???

Anyway - here's what the merchant sent to me for review...

=========================================
the first email from authnet to the merchant reads...


Authorize.Net Merchant,

Your script timed out while we were trying to post transaction results to it.
   Transaction ID: 0
Transaction Result: The credit card number is invalid.

The following message was displayed to the customer:

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

The credit card number is invalid.



============================================
.... the relay page notifies us of a failure and provides the post data (from the authnet server not from the paying customer, of course)
Here are some of the relevant items...

x_response_code  =  3  (i.e. error)
x_response_reason_code  =  6
x_response_reason_text  =  The credit card number is invalid.



===========================================
..... these are then followed by another email from authnet to the merchant which says the transaction was approved....

============== RESULTS ==============
Response : This transaction has been approved.
Auth Code : -- snipped
Transaction ID : -- snipped
Address Verification : Street Address: Match -- First 5 Digits of Zip: No Match

[RichardH]

Hello @hav

It appears you have your gateway in test mode, or are setting test mode in the transaction which means it doesn't actually attempt a transaction.  It only confirms the API Login and Transaction Key are valid and returns OK.  If you examine the transaction ID, it is zero meaning nothing was saved by the gateway.

You must read the response code to confirm a transaction was completed.

Richard

[hav]

Hey Richard .. well - in the post data from authnet to the relay page, the x_test_request is set to false and the x_trans_id is 0.

My client tells me that his gateway is turned on and live - and though I have no way of verifying that with authnet, we have done some live tests where he has made purchases from his site since we saw this error.  He used authnet payment and one of his cc's ... everything seemed to work just fine??

I'll have him verify with authnet that the gateway is live and see if that helps?

Thanks again

[RichardH]

@hav, if you log into the Merchant Interface, you should see your transaction there.

Richard

[hav]

We're STILL having issues when there is an error - like a bad card number.

Good purchases (meaning good card number etc.) go through just fine.

When there is an error - like a bad card number - should the relay page respond differently than it would for a successful transaction?  Our relay page responds the same with the only difference being where we want the customer sent - i.e. to a page indicating there was an error vs a Thanks page.  However, it seems that, when there is an error, the customer is not sent back to the store's server and lands, rather, on an authnet server page indicating there was an error.

In itself, that's fine BUT, when an error occurs, WE get email sayiing that our "script" timed out - which I assume means the relay page; however,  when I look at the my client's server log, I can see the authnet server posting (twice) to the relay page and no indication of any errors in the error log - I can't, of course, see anything indicating a "timeout" and, of course, do not see the customer's machine being redirected to either our error page or our thanks page.

[hav · Accepted solution]

Seems to be resolved ... we think

Solution was reworking the httpd header generation to be a little bit less lazy.