- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
AMPERSANDS break the Accept Hosted Payment Form!
Help! We are using ampersands in our cancel URL and submit URL and the payment form is failing to load! We need to build a URL with multiple GET parameters to have proper security with the cancel and submission of orders on our website. Which means we need use ampersands to divide up our parameters. The problem is if we pass an ampersand at all to the hostedPaymentReturnOptions the entire payment form fails to load! There is no errors in the logs. It just simply only draw the words "Order Summary" and nothing else. If we remove the ampersands everything works correctly.
SettingType returnSettings = new SettingType();
returnSettings.setSettingName("hostedPaymentReturnOptions");
JSONObject returnSettingsJSON = new JSONObject();
returnSettingsJSON.put("url", "http://1.1.1.1/submitPayment?orderID=2540&orderAmount=13.99&submitPaymentID=4a11f608-4196-4365-929e-
9e01c5fa975d");
returnSettingsJSON.put("urlText", "Complete Order" );
returnSettingsJSON.put("cancelUrl", "http://1.1.1.1/clearPayment?orderID=2540&cancelPaymentID=459b4c8b-e257-4d02-84e3-5
f0965b16b81" );
returnSettingsJSON.put("cancelUrlText", "Cancel Order" );
returnSettings.setSettingValue( returnSettingsJSON.toString() );
We desperately need this fixed. We won't have security without it! Please help!
โ02-19-2021 08:35 AM - edited โ02-19-2021 08:37 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Try URLEncoding the URLs:
http://1.1.1.1%2FclearPayment%3ForderID%3D2540%26cancelPaymentID%3D459b4c8b-e257-4d02-84e3-5f0965b16b81
Certified Authorize.net developers
โ02-19-2021 11:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You mean partially encode. Because that http:// is still not encoded. And encoding only part of a URL is weird and clunky. Because I want to just do this:
returnSettingsJSON.put("url", URLEncoder.encode( submitOrderURL, StandardCharsets.ISO_8859_1 ) );
returnSettingsJSON.put("cancelUrl", URLEncoder.encode( cancelURL, StandardCharsets.ISO_8859_1 ) );
Encode everything is one simple call and be done. But now I need to extract the http:// portion and only encode the back half and then put the URL back together again?
Because when I try to encode the entire thing I get this error:
[2021-02-22 10:24:20,385] [ERROR] Failed to retrieve Nonce token for building AuthorizeNet Payment Form:
Response Code: [E00013]
Response Text: [Failed to add Option hostedPaymentReturnOptions
String 'http%3A%2F%2F1.1.1.1%3ForderID%3D2548%26orderAmount%3D540.0%26submitToken%3D011a7a33-bcea-4de9-9c8b-d0ceb9246c3d' does not match regex pattern '(http|https)://.*'. Line 1, position 160.]
Your regex validation should account for the encoding. Or simply do the validation after you decode the URL I give you.
โ02-22-2021 07:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Technically, you only need to URL Encode the & with %26. So, you could replace the ampersands in your URLs with the appropriate encoding and be done.
Certified Authorize.net developers
โ02-22-2021 09:30 AM - edited โ02-22-2021 09:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah...that is still weird. I have never seen a partial encoding like that. You either encode the params themselves or the entire URL. Not one particular character. The goal of an API is to make the job easier for the person using it. Why not just do your funky replace all after we set the url instead of making us do it. Is this even in the documentation anywhere either?
So we discussed and our solution is we're changing our implentation so we now only have one URL parameter. The secret token. And we'll keep the information we need paired with that token on our end. Sacrifice a tiny bit of security but this is just in case AuthNet decides to change the encoding rules and break us again.
โ02-22-2021 01:35 PM