cancel
Showing results for 
Search instead for 
Did you mean: 

Feedback on Accept.js implementation

Hey Authorize.Net dev team,

 

Last week I had to implement Authorize.Net for our merchant website. We opted for Accept.Js as privacy compliance is important to us (we dont want to post credit card credentials to our server). Everything works fine. But I find it tooks me too long to get it work. I listed some idea to make the integration easier and thus encourage developers to implement your gateway.

 

A. JS form widget

 

We've implemented Stripe which does provide an auto-loaded form for entering card credentials and generate a payment nonce. It is very easier to implement. I guess you probably have such a feature in your pipeline. If you dont, then you really should consider it. For many reasons:

 

1) This would reduce the time for implementation and maintenance for third-part developers, which my encourage companies to opt for your solution.
2) Writing a form for credit card credentials is really not trivial


3) I believe that knowing how the UX of the credit card form is more Authorize.Net's duty than the merchant's one. You should know better than us how such a form should be buit.

 

B. Confusing: sandbox / jstest / test mode

 

I think you should document a suitable configuration for the following use cases:

 

  • when the developer locally implements the API
  • when on live server, in test mode
  • when on live server, in prod mode

 

C. Also generate a public client key when registering to the sandbox

 

D. Which API to use with Accept.JS? DPM, AIM, SIM?

 

I ended up with AIM. But I'd have liked to read it in your documentation. That would have saved me time.

 

E. Having another JS file for developping and debugging

 

While starting implementing Accept.Js, I ran into many small issues that really discouraged me in the first place. Maybe the scope of https://jstest.authorize.net/v1/Accept.js is meant to be a replica of the production JS file (does only the API endpoint differ?), and therefore the issues I went true make sense. But maybe you could provide a JS file for development/debugging.

 

Step 1 As a developer I would use https://jsdev.authorize.net/v1/Accept.js
Step 2 As a developer I would use https://jstest.authorize.net/v1/Accept.js and fix issues such as CORS, HTTPS, etc.

 

F. Handle CORS issues for debugging JS file

 

Even though you do mention it in your doc, CORS errors should be disregarded while debugging. I would rather accept cross-origin request for the debugging JS file and output something with console.log()/console.warn()/console.error(). Otherwise developers may waste their time trying to fix CORS issues before eventually figuring out that their implementation fails for another reason.

 

G. Allow non-SSL loading of JS file

 

If you first step in Accept.js, as a developer it's quite frustrating to see you cant load the file unless you set HTTPS locally. I'd rather output a warning/error in the console if the connection isnt SSL.

 

H. Non-minified source

 

It's quite hard to debug on minifiedJS files as all the variables have been renamed.

 

I. More robust input handling

 

I wanted to fetch the card credentials to generate a payment nonce. My front end implementation caused the value of secureData.cardData.cardNumber to be undefined. Accept.js then triggered the following error in my console:

 

type error: a[c] is undefined

 

This is quite hard to debug. You should check that the property exists AND is not undefined.


J. Nice to have: an API endpoint for account details

 

I'm developing a service where our users can run their own online shop. Our users should be able to implement Authorize.Net as payment gateway. Thus they need to pass their credentials. I would like to make sure the currency they set in their Authorize.Net account does match their currency in our system.

 

K. Your dev team should be involved with https://github.com/thephpleague/omnipay-authorizenet

 

I know you provide and SDK, but as our website supports several payment gateways, we opted for this omnipay lib. Therefore your implication in the omnipay/authorizenet driver would be highly valuable.

1 ACCEPTED SOLUTION

Accepted Solutions

Hi @felixmaier1989,

 

First off, THANK YOU, THANK YOU, THANK YOU!

 

Detailed feedback like yours is incredibly valuable, and we really appreciate that you've taken the time to write this up.

 

I'll address things point by point, but first, let me point out that within the last day, we've released code in sandbox that fixes some of these issues, 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.

 

A. JS form widget

Couldn't agree more, for all the reasons you've mentioned. It's in the works, and is hopefully something you'll see in the next few months.

 

B. Confusing: sandbox / jstest / test mode

This isn't specific to Accept.js but all across our system. We have a sandbox, for test transactions, and we have a production system. But, there's also a "Test Mode" that can be set in the Account Settings for both sandbox and production, as well as a test mode parameter that can be set on a per transaction basis in both systems. So, you can send a transaction to our test system where your account is in live mode, but the transaction is in test mode. Or, you can send a transaction to our live system where your account is in test mode but the transaction indicates live mode. Or any other possible permutation of these things.

 

Confused yet? I am.

 

We've got things in the works to try and clear this up, both on the documentation side and in the way our merchant interface works. In the meantime, let me try to clarify:

 

The sandbox "should" be a duplicate of our live production processing system. It has some simulated parts, such as the actual processor connection to send card details out for authorization and settlement, but the behavior and responses that you get from sandbox should be identical to what you would get with the same request on the production system.

 

"Test Mode", whether enabled for an account as a whole or on a per-request basis, only checks your authentication credentials and returns a response. That's it. It's meant to just test that you have a valid connection to our system and that you are using a valid account, not that you're making a valid request to do whatever you want to do. It would possibly be better if we called it "Connection Testing and Account Credentials Validation Mode", but that's a little too unwieldy. Either way, the important thing to remember is that sending a transaction to the live system in Test Mode is not the same as sending a transaction to the sandbox system and will not get you the same results.

 

Specific to Accept.js, there are two script URLs:

https://jstest.authorize.net/v1/Accept.js is for processing in the sandbox,

https://js.authorize.net/v1/Accept.js is for processing in production.

 

I've made some wording changes in an upcoming revision of the Accept.js documentation to make that clearer, but I'll go back and see if there's anything else I can do there.

 

As far as developing with something hosted locally, there's not a specific environment for that now, and perhaps might never be. You could try to take the Accept.js and AcceptCore.js scripts and modify them to serve them locally, or perhaps someday we could do the same. For now, if you're doing your development locally, the web server on your machine needs to be using https. That's not too hard to set up with a self-signed certificate usually. However, I understand not everyone wants to go to that trouble, so we do have a feature request to allow straight http connections when the window.location property includes "localhost".

 

C. Also generate a public client key when registering to the sandbox

Good suggestion. If we generated the public client key automatically, we could perhaps go further and include it in the welcome emails we send. I'll pass that on.

 

D. Which API to use with Accept.JS? DPM, AIM, SIM?

This is a headache of our own making. We have this collection of older task-specific APIs (DPM, AIM, SIM, CIM, NVP, etc), which we've since supplanted with one consolidated "Authorize.Net API". Those older APIs are in some cases deprecated, and in other cases still officially supported, but the "Authorize.Net API" is the way forward, and all of those other APIs will eventually go away.

 

Using an Accept.js payment nonce is only supported using the "Authorize.Net API", so if you're using Accept.js, that's the API you're using. The documentation is all written around the premise that there is only one true API and that's the API featured on our website. However, this still becomes a little confusing if a developer has previous experience with these older APIs. I'll see if there's something we could add in the documentation to make things clearer:

 

This thread is relevant: https://community.developer.authorize.net/t5/Integration-and-Testing/Using-the-Accept-js-Payment-Non...

 

E. Having another JS file for developing and debugging

The sandbox version of the script is really meant to be identical to production, which does cause some difficulties if you're calling it from something running locally. So, again, we could look into making another version available. If we can make the change to allow non-https connections from localhost, though, that would eliminate a lot of the need here. Removing the unnecessary CORS errors takes care of a lot as well.

 

F. Handle CORS issues for debugging JS file

The good news is the new release fixes the one consistent unnecessary CORS error. Now that that's gone, any CORS errors found now should be rare, and if soon, shouldn't be disregarded because they actually mean something.

 

G. Allow non-SSL loading of JS file

Yep. Agreed. It's planned. Unfortunately, I don't know if it can be included soon or has to wait for a later release.

 

H. Non-minified source

We've got valid reasons for minifying the script that you're including in your page. However, you're right that having an easier to read one with real variable names would be useful in the debugging process. I'll talk about that more internally. If we were to do a separate debugging/development environment like you suggested, that could include a nicely commented and non-minified version of the script(s). If not, it might still be possible for us to include a "variable-ized" and commented version of the scripts somewhere in the documentation for reference purposes. Good suggestion.

 

I. More robust input handling

Huh? Are you trying to tell me you see "type error: a[c] is undefined" and don't instantly know what's wrong? :) Point taken. I'll see what we can do.

 

J. Nice to have: an API endpoint for account details

We do have some APIs for partners or resellers, and we're improving them constantly. What you describe is either possible now, or will be shortly. We're also working on improvements that would allow the merchant to designate you to operate on their behalf without them giving you their credentials directly.

 

If you haven't already, sign up for one of our partner programs at http://www.authorize.net/partners/. Our partner team can then get you more information about what's possible here.

 

K. Your dev team should be involved with...

No matter how that sentence ends, you're right. There are a lot of things we should be involved with, and over the next year, we're pushing to be involved in a a lot more places and a lot more projects. With the OmniPay library driver specifically, I've just added it to my watchlist on GitHub, and when I get a chance, I'll dig through the whole repo to see if there's anything I can help with.

 

Again, thanks!

 

View solution in original post

Aaron
All Star
4 REPLIES 4

Hi @felixmaier1989,

 

First off, THANK YOU, THANK YOU, THANK YOU!

 

Detailed feedback like yours is incredibly valuable, and we really appreciate that you've taken the time to write this up.

 

I'll address things point by point, but first, let me point out that within the last day, we've released code in sandbox that fixes some of these issues, 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.

 

A. JS form widget

Couldn't agree more, for all the reasons you've mentioned. It's in the works, and is hopefully something you'll see in the next few months.

 

B. Confusing: sandbox / jstest / test mode

This isn't specific to Accept.js but all across our system. We have a sandbox, for test transactions, and we have a production system. But, there's also a "Test Mode" that can be set in the Account Settings for both sandbox and production, as well as a test mode parameter that can be set on a per transaction basis in both systems. So, you can send a transaction to our test system where your account is in live mode, but the transaction is in test mode. Or, you can send a transaction to our live system where your account is in test mode but the transaction indicates live mode. Or any other possible permutation of these things.

 

Confused yet? I am.

 

We've got things in the works to try and clear this up, both on the documentation side and in the way our merchant interface works. In the meantime, let me try to clarify:

 

The sandbox "should" be a duplicate of our live production processing system. It has some simulated parts, such as the actual processor connection to send card details out for authorization and settlement, but the behavior and responses that you get from sandbox should be identical to what you would get with the same request on the production system.

 

"Test Mode", whether enabled for an account as a whole or on a per-request basis, only checks your authentication credentials and returns a response. That's it. It's meant to just test that you have a valid connection to our system and that you are using a valid account, not that you're making a valid request to do whatever you want to do. It would possibly be better if we called it "Connection Testing and Account Credentials Validation Mode", but that's a little too unwieldy. Either way, the important thing to remember is that sending a transaction to the live system in Test Mode is not the same as sending a transaction to the sandbox system and will not get you the same results.

 

Specific to Accept.js, there are two script URLs:

https://jstest.authorize.net/v1/Accept.js is for processing in the sandbox,

https://js.authorize.net/v1/Accept.js is for processing in production.

 

I've made some wording changes in an upcoming revision of the Accept.js documentation to make that clearer, but I'll go back and see if there's anything else I can do there.

 

As far as developing with something hosted locally, there's not a specific environment for that now, and perhaps might never be. You could try to take the Accept.js and AcceptCore.js scripts and modify them to serve them locally, or perhaps someday we could do the same. For now, if you're doing your development locally, the web server on your machine needs to be using https. That's not too hard to set up with a self-signed certificate usually. However, I understand not everyone wants to go to that trouble, so we do have a feature request to allow straight http connections when the window.location property includes "localhost".

 

C. Also generate a public client key when registering to the sandbox

Good suggestion. If we generated the public client key automatically, we could perhaps go further and include it in the welcome emails we send. I'll pass that on.

 

D. Which API to use with Accept.JS? DPM, AIM, SIM?

This is a headache of our own making. We have this collection of older task-specific APIs (DPM, AIM, SIM, CIM, NVP, etc), which we've since supplanted with one consolidated "Authorize.Net API". Those older APIs are in some cases deprecated, and in other cases still officially supported, but the "Authorize.Net API" is the way forward, and all of those other APIs will eventually go away.

 

Using an Accept.js payment nonce is only supported using the "Authorize.Net API", so if you're using Accept.js, that's the API you're using. The documentation is all written around the premise that there is only one true API and that's the API featured on our website. However, this still becomes a little confusing if a developer has previous experience with these older APIs. I'll see if there's something we could add in the documentation to make things clearer:

 

This thread is relevant: https://community.developer.authorize.net/t5/Integration-and-Testing/Using-the-Accept-js-Payment-Non...

 

E. Having another JS file for developing and debugging

The sandbox version of the script is really meant to be identical to production, which does cause some difficulties if you're calling it from something running locally. So, again, we could look into making another version available. If we can make the change to allow non-https connections from localhost, though, that would eliminate a lot of the need here. Removing the unnecessary CORS errors takes care of a lot as well.

 

F. Handle CORS issues for debugging JS file

The good news is the new release fixes the one consistent unnecessary CORS error. Now that that's gone, any CORS errors found now should be rare, and if soon, shouldn't be disregarded because they actually mean something.

 

G. Allow non-SSL loading of JS file

Yep. Agreed. It's planned. Unfortunately, I don't know if it can be included soon or has to wait for a later release.

 

H. Non-minified source

We've got valid reasons for minifying the script that you're including in your page. However, you're right that having an easier to read one with real variable names would be useful in the debugging process. I'll talk about that more internally. If we were to do a separate debugging/development environment like you suggested, that could include a nicely commented and non-minified version of the script(s). If not, it might still be possible for us to include a "variable-ized" and commented version of the scripts somewhere in the documentation for reference purposes. Good suggestion.

 

I. More robust input handling

Huh? Are you trying to tell me you see "type error: a[c] is undefined" and don't instantly know what's wrong? :) Point taken. I'll see what we can do.

 

J. Nice to have: an API endpoint for account details

We do have some APIs for partners or resellers, and we're improving them constantly. What you describe is either possible now, or will be shortly. We're also working on improvements that would allow the merchant to designate you to operate on their behalf without them giving you their credentials directly.

 

If you haven't already, sign up for one of our partner programs at http://www.authorize.net/partners/. Our partner team can then get you more information about what's possible here.

 

K. Your dev team should be involved with...

No matter how that sentence ends, you're right. There are a lot of things we should be involved with, and over the next year, we're pushing to be involved in a a lot more places and a lot more projects. With the OmniPay library driver specifically, I've just added it to my watchlist on GitHub, and when I get a chance, I'll dig through the whole repo to see if there's anything I can help with.

 

Again, thanks!

 

Aaron
All Star

With regards to item "J" I got sidetracked in talking about partner information and forgot to actually give you the answer to your question. Sorry about that!

 

We have an API request for getting merchant details, called Get Merchant Details which should provide what you're looking for including currency.

Hi Aaron, 

 

I'm glad I could help, and I'm glad you're taking actions to improve the process of integrating your payment gateway as third part.

 

 

I just have one remark left: enabling SSL if location.href is localhost wouldnt work in my case as I use virtual hosts. Therefore I would really suggest to allow all connections - in the the developper/debugging version of Accept.js of course.

True. That's an argument for either a special developer version, or some sort of parameter that you can pass (on sandbox only) to disable the https check. I'll add that to the list.