Introducing Authorize.Net Accept.js

by Administrator Administrator on ‎06-29-2016 05:56 AM (34,447 Views)

Today we’re announcing the second module for the Authorize.Net Accept suite of tools: Authorize.Net Accept.js.


This new module makes it easier to integrate payments into applications while helping to reduce PCI DSS scope. With Accept.js, developers have control over the user experience without sending PCI data through their servers. One of the top-requested features in our developer community, Accept.js replaces Direct Post Method (DPM) with a modern implementation that doesn’t require a post-back. Accept.js can be used like any other payment type in the Authorize.Net API.


If you currently use the Authorize.Net API to process payment transactions, the integration should be the same, with only one additional step: before you POST the order/payment details to your server, you make a call to the Accept library and pass the resulting data to your server in place of any credit card details.


See our Sample Application on GitHub for a full working example.


Learn more about Accept.js by visiting the Authorize.Net Accept.js feature page.

by earthskater1
on ‎07-10-2016 11:29 AM

What does this error represent: E_WC_14:Accept.js encryption failed.

by xqm199090
on ‎07-18-2016 06:35 PM

I kept getting 'window[c] is not a function' error from 'Object.function.a.dispatchData.a.dispatchData [as dispatchData] (AcceptCore.js:1)'. Any Idea whats going on?

by pcmatt
on ‎07-18-2016 08:00 PM

I need a simple sample PHP file that can capture a payment form including email address to email the receipt via account settings. 


The current sample incorporates all kinds of other functions that I don't need and the multiple php files and javascripts are difficult to understand.   Just one or two file/php page solution for simple process of payments is needed to REALLY replace the SIM and DPM API methods.


Please help!




by bitforge
on ‎08-19-2016 10:13 AM

Is there going to be any official statement on where in the PCI SAQ spectrum this falls? It looks to me like it's SAQ-A EP, which is the same as DPM is, so in terms of compliance it's not really much of an improvement. Other processing providers are providing similar methods via JS that allow you to stay within the realm of SAQ-A, which is much, much easier to comply with...

by sirmann
on ‎08-19-2016 10:48 AM

bitforge, I agree with you on the PCI scope of this new inplementation.  This just does DPM a different way and doesn't change the SAQ level.  When I started reading this article, I got excited thinking we could use this method instead of SIM to maintain SAQ-A and not have to deal with iframing in the entire payment page and posting the user back to our servers after the fact.  But after looking at the developer guide, it definitely stays SAQ-A EP because the payment input fields still originate from our code/servers.  I wish they would have spent a little more time and actually developed this JS method to create and host the payment input fields like most of the other major payment processors are doing to allow us to use it and maintain SAQ-A.

by treii28
on ‎08-19-2016 01:04 PM

Will this work somehow with the Customer Information Manager when a customer is creating a new payment profile or does it only work with direct transactions in the AIM/SIM?

by monis01
on ‎09-28-2016 11:58 PM

I am getting error 'window[b] is not a function' on integrating accept.js. what is this error?
using example from


by firebird
on ‎12-31-2016 04:07 PM

I am also getting 'window[b] is not a function' - has anyone got Accept.js to work?  So far I've been immensely frustrated with the process...  With Stripe, I was up and accepting payments in an afternoon.

by firebird
on ‎01-04-2017 06:30 PM

I fixed my above-mentioned problem (window[b] is not a function) by making the response function a global function off of the window object:


window.submitPaymentData = function(res){...}



Now I have another question - is it possible to test card rejections using Accept.js?  I tried using the zip code 46282 as list here but the transaction is still approved.

by Administrator Administrator
on ‎03-07-2017 04:19 PM

Hi @firebird,


Just a heads up for you and anyone watching this thread that we've released code in sandbox that fixes many of the issues brought up here, and this code should make it into the production environment within the next couple of days.


Specifically for Accept.js, there's no longer any "Access-Control-Allow-Origin" related error in the console, the accept.js script can now be loaded at any point in the workflow, and the response handler function can be passed directly in the function call instead of having to pass the name of a global function.


Additionally, the zip code is making it through now where it wasn't before, so if you include the 46282 zip code in your nonce request, you should get back a nonce that will be declined when it's submitted in a payment request.


Of course, please let us know if anything's not working as expected!