Sagepay 5006 error code fix

Question

Can any one please let me know why the sagepay throws the 5006 (Unable to redirect to Vendor's web site.), i can able to post transaction to sagepay and can able to give credit card information at sagepay's end. But, my problem is once it return back to my notification page it throws error 5006.

and i could not reach my success or fail URLs at my end.

Answer 1

Please see the below recommendations regarding your issue with your transactions failing error 5006: Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL.

The error message itself is not always entirely accurate, as it is displayed when there is any kind of issue with the Notification response they receive in reply to their post to your NotificationURL. The following is a list of various known issues that you can investigate:

1) You can acknowledge receipt of the transaction response with a Status of either OK, INVALID or ERROR

2) Before writing the three fields above to the Response object of the POST, please ensure you clear your response buffer to remove any header code, comments or HTML. The Sage Pay Server is expecting “Status=” to be the first characters in the response. If it does not see these, it treats the response as though it is an error and fails the transaction!

3) Your Notification Page should ONLY respond with a Status field, a RedirectURL field and optionally a StatusDetail field. No other HTML, headers, comments or text should be included either before or after these fields. The Sage Pay Server will treat all such text as an error and fail the transaction

4) Regardless of status, the RedirectURL must be sent that contains a valid, Fully Qualified URL (i.e. an address starting http:// or https://) to the final completion page on your site to which Sage Pay will send your customer

5) Encoding must be as Name=Value fields separated by carriage-return-linefeeds (CRLF)

6) Your notification page on your server may be ‘crashing’ and you should check to ensure that the notification page on your server can handle correctly all the message sent by Sage Pay (OK, ABORT, NOTAUTHED, REJECTED, PENDING and ERROR).

7) You should send OK in all circumstances where no errors occur in validating the Notification POST, so even if Sage Pay send you a status of ABORT or NOTAUTHED, you should reply with an OK and a RedirectURL that points to a page informing the customer that the transaction did not complete.

8) Sage Pay gateway operates on a variety of fixed IP addresses and they usually use separate IP addresses to respond to all transaction requests.

Please ensure that all of the following IP addresses are allowed within your Server or Firewall:

For outbound traffic to our gateway:

195.170.169.9 – live.sagepay.com 195.170.169.8 – test.sagepay.com

For inbound traffic you only need to whitelist IPs if you are using SERVER as this is the only solution that initiates call backs. You don’t need to apply this for our FORM and DIRECT integrations. The IPs from which we call back are:

195.170.169.14 195.170.169.18 195.170.169.15

The Subnet mask used by Sage Pay is 255.255.255.000.

Ensure that your firewalls allow outbound Port 443 (HTTPS only!) and inbound Ports 443 (and optionally 80 HTTP) access in order to communicate with our servers (on Simulator/Test/Live). There is however always scope for this to change. Sage Pay own the entire 195.170.169.0/255 range (256 IP’s).

9) Are you matching the transaction correctly on your database using the ‘SecurityKey’ we passed to your notification page with the NextURL

10) If the MD5 signatures match, your Notification Script should respond with a Status of OK and a RedirectURL pointing to either an order completion page (if the Status was OK) or an appropriate order failure page (if the Status was NOTAUTHED or ERROR). You may wish ABORT messages to redirect the customer to a page providing them with alternative methods of payment, or asking them why they chose to cancel. If the signatures do not match, you should check that your code is rebuilding the message correctly, and if you are sure that it is, all such messages should be responded to with an INVALID and a RedirectURL pointing the user to a failure page.