cancel
Showing results for 
Search instead for 
Did you mean: 

SIM Relay Response – Blocked Script Execution Error After Payment

 

I am writing to report a critical issue with our Server Integration Method (SIM) payment flow. The relay response redirect has stopped working, and we are receiving the following browser error after successful payment:

 

"Blocked script execution in 'https://test.authorize.net/gateway/transact.dll' because the document's frame is sandboxed and the 'allow-scripts' permission is not set."

 

Our Setup:

 

Integration Method: SIM (Server Integration Method)

Environment: Test Mode (test.authorize.net) (SANDBOX)

Relay URL: https://2.pmam.com/AgentPortalPaymentAPI/api/payment/callback

Payment Processing: Working correctly – transactions are being approved and our callback API is being invoked successfully

Database Updates: Working correctly – payment status is updated via the relay response

The Issue:

 

After payment completion, our relay URL returns an HTML response with a JavaScript redirect to our success page:

 

 

<html><body>

<script>window.location='https://2.pmam.com/AP/1/quote/success?pid=<guid>';</script>

</body></html>

This redirect was working perfectly before. Now, the browser blocks the script execution due to sandboxing on the transact.dll frame, leaving the user stuck on an empty/blank page. The payment is processed successfully, but the user is never redirected back to our application.

 

What We Have Already Tried:

 

  • Replaced window.location with window.top.location.href – Same error
  • Used <meta http-equiv='refresh'> redirect – Same error (meta refresh also blocked)
  • Removed all JavaScript and returned plain HTML with clickable links – Still facing issues with the relay response rendering
  • Created a new test account with new API Login ID and Transaction Key – Same issue persists
  • Verified our server response headers via curl – Confirmed that no Content-Security-Policy or sandbox headers are being injected by our server, proxy, or network infrastructure. The sandboxing originates from Authorize.Net's transact.dll frame
  • Verified the Relay URL is accessible and returning 200 OK – Confirmed working

 

Our Findings:

 

It appears that the transact.dll page is now loading the relay response inside a sandboxed iframe without the allow-scripts permission. This prevents any form of client-side redirect (JavaScript or meta refresh) from executing in the browser.

 

Our Questions:

 

Has there been a recent change to the SIM relay response behavior or iframe sandboxing policy on transact.dll?

Is there a recommended approach for redirecting the user back to the merchant site within the relay response HTML given the current sandboxing restrictions?

Are the x_receipt_link_url and x_receipt_page fields supported in SIM test mode for post-payment browser redirection?

Is there an alternative parameter or method we should use to redirect the user after payment completion?

 

Impact:

 

This is a production-blocking issue. Our customers complete their payment but are unable to return to our application, resulting in a broken checkout experience.

 

Please assist us urgently. We are available for a call or screen share if needed.

Jaydeep2026
New Member
4 REPLIES 4

Thank you Jaydeep2026 for your detailed problem description! We're having the same problem As a temporary solution, we added a link buyers can tap to redirect manually to our thank you page.

capturewiz1
New Member

We've got the same problem here.

I did the same thing as Caturewiz1 and added a simple page with a link to the receipt page. It appears to be working for the moment.

I see it has been about 10-15 days since this post was created. Has any feedback or resolution been posted yet that I may have missed?

shamilton
New Member

Same problem here. Our flow previously relied on a meta http-equiv refresh tag in order to essentially redirect users back to our site after their checkout was complete.

If this was a change made intentionally, are there workarounds to allow redirection back to the original site or any alternative usages?

jaydavid
New Member

I submitted a ticket, but the respondent provided only generic, unhelpful advise, even after being directed to this thread. Sadly, I suspect SIM was sandboxed intentionally for security, and there will be no fix because SIM has been phased out.

capturewiz1
New Member