cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted Form problems

Hello,

I am successfully getting a token from the getHostedPaymentPageRequest.

 

I then post the hidden token to the payment api and getting HTML returned. However, the CSS and Script tags are not being found and the button text is not being replaced. I'm very confused. heres some HTML as example:

 

<script src="../payment/scripts/components/paymentComponent/1_0/payment-min.js"></script> <script src="../payment/scripts/components/addressComponent/1_0/address-min.js"></script> <script src="../payment/scripts/components/bankAccountComponent/1_0/bankAccount-min.js"></script> <script src="scripts/app-min.js"></script>

 

<button class="btn btn-primary payButton pull-right bg-color" id="payBtn" ng-click="payBtnHandler()" ng-disabled="!(paymentForm.$valid &amp;&amp; isValidCaptchResponse)">{{payButtonText}}</button>

 

Thanks,
Zach

ZachE844
Member
15 REPLIES 15

One more thing: I'm hoping to see the actual token request as it would travel over the wire to our servers. You're logging the request object, which the SDK has filled with a bunch of null fields that it's not actually going to end up sending. I want to get a log of the actual request that it's going to post to our servers after the SDK has fully formatted it. What kind of log can you capture if you try to log the controller object instead of the request object?

 

Of course this would be easier if we had better logging in our .NET SDK...

Aaron,

 

I did as you suggested and generated the token and submitted that on a device on a different network (my phone on the cellular network), and the CSS and Javascript files are still not being fetched properly. 

 

I am able to post the token and get to the https://test.authorize.net/payment/payment/ page, but then the CSS and JS files on that page are returning 550 errors. Here is a screenshot of the resulting page, and the console errors for each file so you can see what I am seeing.

Unstyled page

Script and Stylesheet errors

 

Thanks,

Mason

This is great, thanks! Any luck getting a log of the token request?

Hi @Aaron,

I noticed a discrepancy in the referenced js and css files depending on how the application is called.

Notice the 2 URLs below, the first is good and is what is being referenced when posting to https://test.authorize.net/payment/payment and the second URL is what is being referenced when posting to https://test.authorize.net/payment/payment/ which generates the 550 server errors, the key difference being the trailing slash.

https://test.authorize.net/payment/scripts/lib/angular.min.js
https://test.authorize.net/payment/payment/scripts/lib/angular.min.js

The answer is, they are probably posting to https://test.authorize.net/payment/payment/ instead of https://test.authorize.net/payment/payment

 

Although the documentation and you reference the correct URL, apparently this trailing slash is the cause of some confusion.


Easy fix to reference the the js and css files from the application with full paths instead of relative URLs or remove the trailing slash with the following in the application's Web.config: 

<rewrite>
  <rules>
     <rule name="Remove trailing slash" stopProcessing="true">
      <match url="(.*)/$" />
      <conditions>
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
      </conditions>
      <action type="Redirect" redirectType="Permanent" url="{R:1}" />
    </rule>
    
  </rules>
</rewrite>

 

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

Well, that did it.

 

Thank you, @NexusSoftware for the solution and thank you @Aaron for helping me try to debug.

 

Mason

Hi @NexusSoftware,

 

As usual, your contributions are outstanding! I have no doubt that the rest of us would have stumbled upon this eventually, but it may have taken us a few more days (or weeks!) of posting back and forth to get there. You've saved us all a ton of time.

 

I'll escalate this internally so we can figure out ways to better handle the URL in the future.