Reply
Regular Contributor
Posts: 55
Registered: ‎08-01-2013

AMPERSANDS break the Accept Hosted Payment Form!

[ Edited ]

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!

 

 

 

Posts: 478
Topics: 0
Kudos: 93
Blog Posts: 0
Ideas: 0
Solutions: 38
Registered: ‎04-28-2017

Re: AMPERSANDS break the Accept Hosted Payment Form!

Hello,

 

Try URLEncoding the URLs:

http://1.1.1.1%2FclearPayment%3ForderID%3D2540%26cancelPaymentID%3D459b4c8b-e257-4d02-84e3-5f0965b16b81
Powered by NexWebSites.com -
Certified Authorize.net developers
Regular Contributor
Posts: 55
Registered: ‎08-01-2013

Re: AMPERSANDS break the Accept Hosted Payment Form!

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.

Posts: 478
Topics: 0
Kudos: 93
Blog Posts: 0
Ideas: 0
Solutions: 38
Registered: ‎04-28-2017

Re: AMPERSANDS break the Accept Hosted Payment Form!

[ Edited ]

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. 

 

Powered by NexWebSites.com -
Certified Authorize.net developers
Highlighted
Regular Contributor
Posts: 55
Registered: ‎08-01-2013

Re: AMPERSANDS break the Accept Hosted Payment Form!

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.