DPS not redirecting to checkout_success.php

[acumen]

After a successful transaction with DPS (using PXPAY payment module), clicking the next button returns us to the checkout_confirmation screen (which is very confusing) rather than the checkout_success screen.

 

As a result, the credit card transaction takes place and we receive the money but oscommerce seems unaware of any order.

There is no record in the Product purchased information under Reports and there is no email generated to the customer of a successful sale - hence, we are unable to fulfill the order.

 

Can anyone help?

[Guest]

Mae,

 

Return URLS should always go back to checkout_process.php which will check the transaction status and forward it to the appropriate page.

 

 

 

 

Chris

[acumen]

But it does not forward to any other appropriate page. After the payment has been made, it just goes back to the previous page. It does not indicate that the purchase has been successful so it looks confusing.

 

- Also, no email was sent to the buyer

- The email that we receive as a seller only informs us that a purchase has been made without any info of who the person bought it or where to send it.

- There is no record reflected on the Reports - Product Purchased so we could not tell how many has been paid for.

[Taipo]

Check with your web service provider that there isn't a mod running that limits the size of the return string. Suhosin for example by default limits GET string lengths:

 

In PHPINFO check for this setting:

suhosin.get.max_value_length = 512

 

512 is the amount of characters of the values of a variable in the URL, set by default. Some return strings from 3rd party payment providers can be up to 4 or more times that length. If phpinfo shows that your webserver does have Suhosin installed, and the get max value is set to something like 512, then you can email them and request it be raised, or try to do so locally via your htaccess, there is a small chance they may allow local overrides.

 

However I have found most web hosts unwilling to raise the limit and the solution may just be for DPS PXPAY to switch to a POST method of returning data instead of encoding variables in the URL returned or break the string values up into smaller amounts spread across more variables.