11-16-2015 11:02 AM
Since approximately the beginning of October, relay response has stopped working. While I do receive a screen of raw text, the relay url is never reached and no errors (other than specific data errors noted) are provided. The raw response screen is not even XML.
1,1,1,This transaction has been approved.,JDASFP,Y,2244979045,11162015184615,Total Design Source, Inc.,494.95,CC,auth_capture,Testing-Anoth-04001,Another,Testing,,1234 Antstreet,Anytown,ME,04001,US,207-555-1212,,email@example.com,Another,Testing,,1234 Anystreet,Anytown,ME,04001,US,,,,,,650183A0B472009DFC51D3FFE2FF1982,P,2,,,,,,,,,,,XXXX0027,Visa,,,,,,,,,,,,,,,,,6651447699567,494.95,19.95,475,494.95,0,Antique Chinese Stone Weight Style #7,Antique Chinese Stone Weight,,0,19.95,1,475,475,494.95
This has been the case for all my sites using the sandbox. I have reviewed a number of the forum entries and tried various posted solutions but have made no progress. I do receive the emails (Merchant Email Receipt and Transaction Receipt) but have been unable to get a response from the sandbox processing to any website, regardless of the url supplied.
I don't have any default response urls set although I have tried putting them in with no change in results and subsequently deleting them. The x_relay_url has a completely valid url in all cases but is never returned to. Sites that were working for months or years are no longer and the result is the same with no indication of any problems, errors, etc. Just a raw text response page coming from who knows where as nothing in the documentation or forums provides any clues.
11-16-2015 12:12 PM
It would help if you provided a sample request and api endpoint you are using. Remove any sensitive information and be sure to include your relay response url.
If you have a firewall that blocks inbound Internet traffic and use Relay Response or Silent Post, please add these IP addresses to yourwhitelist.
11-16-2015 01:40 PM
I am using the standard php:
$time = time(); $fp_sequence = $time; $fp = AuthorizeNetDPM::getFingerprint(AUTHORIZENET_API_LOGIN_ID, AUTHORIZENET_TRANSACTION_KEY, $pgfields_input['x_amount'], $fp_sequence, $time); $sim = new AuthorizeNetSIM_Form( array( 'x_amount' => $pgfields_input['x_amount'], 'x_fp_sequence' => $fp_sequence, 'x_fp_hash' => $fp, 'x_fp_timestamp' => $time, 'x_relay_response'=> "TRUE", 'x_login' => AUTHORIZENET_API_LOGIN_ID, 'x_test_request' => TEST_REQUEST, 'x_relay_url' => 'http://22.214.171.124/~tdesig14/shop/enter-details/?return=y' ) ); $myformout .= $sim->getHiddenFieldString();
As I stated, it had been working (in this specific case for several months) without issues.
11-16-2015 02:35 PM
Well at least something different:
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.
I have tried various combinations of encoding the url or pieces thereof. Hadn't tried this one. They have always worked in the past with the tilde. Using the url with the tilde encoded (%7e) doesn't work when pasted into the browser.
11-17-2015 11:14 AM
The behavior that you are seeing seems to indicate that the transaction is not being recognized as DPM. This is most commonly caused by invalid parameters being sent or parameters not being recognized. I would recommend using a browser development console to check exactly what parameters are actually being passed to Authorize.Net when you run a transaction.
11-17-2015 05:17 PM
I have gone through all the parameters, removed any I added and tested, tested, tested.
The only thing that makes any difference is removing the tilde (using an alternate url - not the correct one) which appears to return correctly (but the response cannot be handled). Because we use shared servers, the tilde is required for our testing (no active domain - Apache mod_userdir ) and we have been using it for AN testing for a decade.
Apparently due to a change in the sandbox, it no longer works. This is catastrophic for us.
What I really can't understand is why I get a raw text page in response. No errors, no XML, just raw text of the response values comma seperated. It appears the sandbox handles everything and processes the request correctly except for the final return to the specified url (x_relay_url). To generate the raw text response it must be going somewhere, just not where it was told to.
Can/will this be corrected?