I am sending my customers to the hosted payment page, and am passing the first name, last name, and email address. This is the URL (slightly munged for security)

http://example.chargevault.com/update?method=cc&key=CUST_KEY&code=CUST_CODE&firstName=Joe&lastName=Blow&email=joe%40example.com

Note the encoding of the @ symbol to %40 near the very end. By default in my system, all URL parameters are encoded as part of the URL creation process, as part of standard security practices.

However the URL that the user actually ends up on looks like this...

http://example.chargevault.com/update?method=cc&key=CUST_KEY&code=CUST_CODE&firstName=Joe&lastName=Blow&email=joe%2540example.com

Note the double encoding of the @ symbol to %2540. This is not translated properly by CG systems, and the email address that gets populated in the input box reads as joe%40example.com. The first layer of encoding is pulled out, but not the second.

At first I thought it was my software, but after verifying that my URL was outputted properly, I pulled out my trusty Firebug and followed the URL trail. There I learned that the CG Hosted Payment Page system does an internal redirect that applies the second layer of encoding.

Request: http://example.chargevault.com/update?method=cc&key=CUST_KEY&code=CUST_CODE&firstName=Joe&lastName=Blow&email=joe%40example.com
Response: http://example.chargevault.com/update?method=cc&key=CUST_KEY&code=CUST_CODE&firstName=Joe&lastName=Blow&email=joe%2540example.com
(status code 302)

// content of email box
joe%40example.com

To confirm the behavior, I sent a different request, with a plain % attached:

Request: http://example.chargevault.com/update?method=cc&key=CUST_KEY&code=CUST_CODE&firstName=Jo%e
Response: http://example.chargevault.com/update?method=cc&key=CUST_KEY&code=CUST_CODE&firstName=Jo%25e
(status code 302)

I understand why you perform a URL encoding yourselves, all user input is dangerous. However I cannot simply eliminate my own URL encoding process, as that introduces the possibility for a XSS attempt on my site, before the user leaves.

The correct solution is for the Hosted Payment Page to assume that all encoded content is double encoded, and require users to perform encoding before redirecting the user.

I understand this bug is kinda technical, so please re-read (and test!) if this doesn't make sense, or ask for clarification.