Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server error 5006: Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL. #197

Open
dathwa opened this issue Mar 22, 2024 · 3 comments

Comments

@dathwa
Copy link

dathwa commented Mar 22, 2024

Hello All.
I know this error can be a bit vague/misleading, but that's what we have.
We use Sagepay server and since yesterday, payment started failing. Still on omnipay-sagepay 4.0.1.

"Server error 5006: Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL."
"HTTP error 500: The request was unsuccessful due to an unexpected condition encountered by the server."

Absolutely mystified. Anyone else?

Out of interest, the data array we post is below...
The documentation can be confusing, so we post all of these url handles, hoping one will stick:
returnUrl,
redirectUrl,
RedirectionURL (is it case-sensitive?),
failureUrl,
notifyUrl
Anyone have any clarity on what URLs really work? Would having all of these break the transaction?
Thanks in advance for any insight.

    $data = [
            'amount'    => $this->order->total_in_currency,
            'currency'  => $this->order->currency['code'],
            // 'token'     => $this->data['token'],
            'transactionId' => $transactionId,
            'description' => PaymentGatewaySettings::get('sagepay_server_payment_description'),
            'card' => $card,
            'items' => $items,
            'clientIp' => request()->ip(), // protocol 4 addition
            'returnUrl' => $url,
            'redirectUrl' => $url,
            'RedirectionURL' => $url, 
            'failureUrl' => $url,
            'notifyUrl' => $url, // 22/03/2024 - worth a shot?
            // 'Apply3DSecure' => 1, // 1|2|3|4 // protocol 4 addition // 022 : The Authorisation was Declined by the bank. SCA required
                // 'Apply3DSecure' => CreatePayment::APPLY_3D_SECURE_FORCE, this work?. see https://github.com/academe/SagePay-Integration
                // 'ApplyAVSCV2' => true, // protocol 4 addition
        ];
@judgej
Copy link
Member

judgej commented Mar 23, 2024

The Omnipay driver uses notifyUrl which is then sent to the gateway as NotificationURL. This documented by Elavon here: https://developer.elavon.com/products/opayo-server/v1/transaction-registration

You can also use returnUrl, which is legacy from when the driver was first created. These are all case-sensitive, and any other variations will be ignored.

Since this functionality has not changed in the driver, I would look at the URL itself. Is it fully qualified, is it http or https (both should work, but that may have changed)? Is it upper-case or lower-case? Again should not make a difference, but straws need to be clutched at here. Is is less than 255 characters, and ASCII only?

The documentation says this:

The fully qualified URL (including https:// or https://) that Notification POSTs are sent to.

Notice it says "https://" twice, almost as though somebody has edited out a "http" to "https" with little care. Those little clues are always worth not ignoring.

@judgej
Copy link
Member

judgej commented Mar 23, 2024

This error message comes not from the notification URL that you set up in the transaction creation, but in the rediect URL that your notification handler returns to Opayo to tell it where to send the user back to on your website. It is $nextUrl in the notification handler described here:

https://github.com/thephpleague/omnipay-sagepay/tree/79bbd9972191b6908dc2470e6b7b1e829536ef76?tab=readme-ov-file#server-notification-handler

The handler returns three lines: the status (hopefully "OK") a status message, and the URL to send the user to.

I would recommend you log what comes in on the notification from Opayo, and what you then send back out to Opayo. You may find a clue there, or you may find the notification URL is not actually being called at all, or is returning a 404 or 403 (easily done, especially if you are only allowing certain IP addresses to access that URL - have Opayo recently changed their IP addresss they send the notifications out from?).

Some documentation here:

https://developer.elavon.com/products/opayo-server/v1/step-4-you-confirm-the-transaction

Opayo say this to help solve your error:

If the above has been checked, or unable to be checked look to the server for possible restrictions that could cause the transaction to encounter errors:

  • Ensure you have opened ports 80 and 443 on your servers to allow posts from Opayo.
  • Ensure all Opayo IP Addresses have been added to your server.
  • Check any additional firewall or security measures will allow contact from the Opayo systems.
  • After checking, and validating all of the above you are still encountering this error you can change the notification URL to another link on your server that can be tracked to ensure contact is being made by the Opayo system and a response is being generated.

They do not say where to get the list of IP addresses from though, The Sage Pay IP range was 195.170.169.0/24.

@Ferrisbane
Copy link
Contributor

Hi this might be due to the bug I've created a fix for.
#198

I was also getting an error about redirecting back to vendor.
However that was because our server was erroring due to signature verification checks. And therefore was not able to give a url to redirect to.

You might want to copy my fix and test to see if that fixes your issue?

Hopefully my fixes can be merged in before Opayo's cut off date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants