I was wondering if you could help explain some behavior we're seeing with our Hosted Checkout integration. We're submitting the following fields (among others) in our POST to demo.globalgatewaye4.firstdata.com
x_description=Charges for transaction(s) 237
x_relay_url=https://our.company.url/app.dll
test_field_1=spaces here (just to test)
which are correctly percent encoded in the POST body as
x_description=Charges%20for%20transaction(s)%20237
x_relay_url=https%3A%2F%2Four.company.url%2Fapp.dll
test_field_1=spaces%20here%20(just%20to%20test)%0A
However, when the payment is complete and the gateway posts back to our web app, the fields its sending include
x_description=Charges+for+transaction(s)+237
x_relay_url=https%253A%252F%252Four.company.url%252Fapp.dll
test_field_1=spaces%2Bhere%2B%2528just%2Bto%2Btest%2529
which percent decode to
x_description=Charges for transaction(s) 237
x_relay_url=https%3A%2F%2Four.company.url%2Fapp.dll
test_field_1=spaces+here+%28just+to+test%29
So the x_description field is sent correctly, but the x_relay_url (a supported field) and test_field_1 (our custom field) both seem to be encoded twice when they come from FirstData. Could you help us figure out if we're overlooking something in the documentation or if this is a potential problem on FirstData's side? Thanks in advance!
The x_relay_url is URL encoded when performing urldecode with PHP returns:
https://our.company.url/app.dll test_field_1=spaces here (just to test)
<?php
echo rawurldecode('https%3A%2F%2Four.company.url%2Fapp.dll
test_field_1=spaces%20here%20(just%20to%20test)%0A');
?>
To see the actual raw data being passed back you should use something like Fiddler as I cannot recreate the issue.
Christopher, thank you for replying. I can show you the raw requests we're sending and receiving but I'm a little leery of putting details like my test server URL on a public forum. Is there an option to pursue support via email?