GoGreen PC Tune-Up™
Learn More

this is how ssl encrypt our websites
MTNCOMP | List View | Table View | myBlog (1746 Entries)
myBlog Home


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

by Mountain Computers Inc, Publication Date: Saturday, February 17, 2024

View Count: 613, Keywords: Authorize.Net, ASP Classic, JavaScript, XML, Hashtags: #Authorize.Net #ASPClassic #JavaScript #XML

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
REF 1: https://developer.authorize.net/api/reference/features/accept_hosted.html
REF 2: https://developer.authorize.net/api/reference/index.html
REF 3: https://sandbox.authorize.net/
REF 4: https://developer.authorize.net/api/reference/index.html#gettingstarted-section-section-header
REF 5: https://developer.authorize.net/api/reference/index.html#accept-suite-get-an-accept-payment-page
Annoying part of documentation is the following is hidden on the getting started page. its collapsed when it should be in plain site for First Time User. Here is the info that you need to digest first before doing anything else.
FIRST TIME USER? Click here for API Endpoints & Authentication details
API Endpoints & Authentication
All requests to the Authorize.net API are sent via the HTTP POST method to one of our API endpoint URLs.
HTTP Request Method: POST
Sandbox API Endpoint: https://apitest.authorize.net/xml/v1/request.api
Production API Endpoint: https://api.authorize.net/xml/v1/request.api
XML Content-Type: text/xml
JSON Content-Type: application/json
API Schema (XSD): https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd
All calls to the Authorize.net API require merchant authentication. Sign up for a sandbox account to quickly get started. 
A Note Regarding JSON Support
The Authorize.net API, which is not based on REST, offers JSON support through a translation of JSON elements to XML elements. While JSON does not typically require a set order to the elements in an object, XML requires strict ordering. Developers using the Authorize.net API should force the ordering of elements to match this API Reference.

Alternately, consider using the Authorize.net SDKs for a seamless integration.
more to come...

if you found this article helpful, consider contributing $10, 20 an Andrew Jackson or so..to the author. more authors coming soon
FYI we use paypal or patreon, patreon has 3x the transaction fees, so we don't, not yet.

© 2024 myBlog™ v1.1 All rights reserved. We count views as reads, so let's not over think it.