Invalid return URL with reset fragment and Paypal GET variables

[tomcastleman]

When the following are true:

• return URL specified (data-return)
• PDT and auto return enabled in Website Payment Preferences

Paypal seems to always send back the transaction variables (including tx etc) via GET rather than POST even when setting the return method (data-rm) to 2 (annoying).

Minicart appends a reset fragment to the URL on success:

// Add Mini Cart specific settings
if (settings['return'] && settings['return'].indexOf('#') === -1) {
    settings['return'] += '#' + config.name + '=reset';
}

When Paypal sends back GET variables this causes the return URL to have the fragment before the query string which is obviously neither desirable nor useful.

I think the solution here is to have a config option to disable the addition of the reset fragment to the return URL which would enable the GET variables to come through in the return URL correctly.

For example:

// Add Mini Cart specific settings
if (settings['resetCartOnSuccess'] && settings['return'] && settings['return'].indexOf('#') === -1) {
    settings['return'] += '#' + config.name + '=reset';
}

and in the config resetCartOnSuccess defaults to true, but can be set to false in situations like this as necessary.

[jeffharrell]

Awesome. Let me re-review in the morning when I've had time to think through some scenarios, but at first glance I don't see any problems.

I'll also get a bug filed against the product on the PayPal side of things. They should be treating the return URL param as an actual URL and not a string. This would enable proper parsing.

[jeffharrell]

Keeping this open as a reminder to follow up on the PayPal side of things.

This is also a non-issue in the upcoming 3.0 release since I've removed the "smart" hash technical due to problems. The return URL page now needs to explicitly call reset().

[jeffharrell]

Issue filed and being tracked at PayPal.