JavaScript XML ASP Classic e-commerce integration programming with Authorize.Net - Part 2

Two weeks have now passed since I started this project and its 100% completed. While the delivered solution is not always done; yet in the time frame and constraints I was given: this is what we call good and strong enough.

 

** Whew - the updated integration from PayEz to Authorize.Net for a client's e-commerce site is working.

 

I wish I could securely share the Classic ASP solution without revealing the client name and the source code.

 

Maybe in the future if Authorize.Net developer support wants to see my integration examples for Classic ASP to work efficiently and let me help them update their Authorize.Net API documentation and examples.

 

Note: The PayEz integration Classic ASP solution I provided to the client and has been working perfectly since 2014 I backed up before taking on this challenge. That 2014 PayEz integrated solution only required a few tweaks over a decade to handle the SHA1 replacement and dealing with daylight savings time when generating the security token. Oh wow, I looked at my programming and that's some cool code!! Hell ya, this one too! It's funny, I had used Authorize.Net as my payment gateway for Reno4Sale.com some 22 years ago and it worked perfectly then too.

 

Now on to what I learned in the following:

 

0. the API Endpoints and Authentication link on the previous post is important to learn and figure out first. Then, choose your message format JSON or XML. I preferred XML for readability though more difficult than JSON to implement. Decide on your transaction side, client side or server side. Client side will use the Payment Transactions examples and documentation in the Getting Started section, and server side will be the Accept Suite section. Test your credentials and let it populate the API sections to get a better understanding of your messaging processes. For me, Accept Suite | Get an Accept Payment Page was the request from the client.

1. XML versus JSON replacing REST messaging is daunting. JSON messages do not require strict ordering yet XML requires strict ordering. Start small with your XML transaction and build it carefully and test, test, test.

2. Authorize.Net SANDBOX in TEST mode needs to be turned on to LIVE after credentials are verified using one of the few methods to communicate to it. Why? When you test test transactions, the Processing button will stay processing and never finish to complete and give the receipt!! This is vital to know. In TEST mode, test transactions will NOT go through when in fact you want them to go through, so in the SANDBOX environment, after authentication is verified, turn the SANDBOX to LIVE mode and process your $1 test transactions and they will work. Otherwise it will fail to finish processing and hang at the payment processing step.

3. Ensure your test code website pages are removed from the testing and production sites once your go LIVE into Production. Keep the URL's for relay/response entered, yet the pages should not be on the web server.

4. Change your Authorize.Net transaction keys a few times to get used to updating your authentication methods.

5. Keep Bookmarks and Notes to your API documentation that worked and delete the notes that did not work.

6. You can email developer support for trusted and secured assistance. They respond pretty quickly.

7. Backup your code as you go. For me, after I made small successes I would accidentally break the application integration and have to fall back to where it worked, and review where I went sideways as I build out and enhanced the integration.

 

Coding Notes:

In your HTML Form action for the Get Accept Payment Page, use one for testing and the other for production:

* SANDBOX - ACTION: https://test.authorize.net/payment/payment 

* PRODUCTION - ACTION: https://accept.authorize.net/payment/payment

 

 

more to come...