Developing a RESTful JSON web service integration for Dynamics GP - Part 1

By Steve Endow

I just finished a very interesting Dynamics GP integration.  It is a RESTful JSON web service that allows a web site to integrate with Dynamics GP, Authorize.net, and k-eCommerce / Azox Credit Card Extension.  Because it is a web service that will receive credit card data, it also includes HMAC authentication and AES encryption and runs over HTTPS.

As Fancy Nancy would say:  Très geek!

The customer uses an internal web site to record customer orders.  The web site collects the customer information, credit card information, and the products that the customer is purchasing.  In the past, the customer information was saved and then separately entered or imported into Dynamics GP.  Credit card transactions were processed through a payment gateway, and setup with recurring billing through the gateway.  All transactions were entered in GP after the fact.  The client wanted a real time integration between the web site and Dynamics GP so that the customer information is immediately saved to GP.

However, the customer did not want to store the credit card information in Dynamics GP or the Credit Card Extension module--even if it is encrypted.  They wanted to use "tokenization".  This involves sending the credit card information to the payment gateway (in this case, Authorize.net) and receiving a unique ID, or "token" that can later be used to process credit card transactions.  Once the token was received, it would be stored in the Credit Card Extension module so that future credit card transactions could be performed from within Dynamics GP.

So why RESTful?  Well, the customer's web site was developed using PHP on Linux.  That pretty much ruled out direct APIs such as COM and .NET libraries.  SOAP would have required the client's developers do more work, so we went with REST, which they were familiar with, and REST is pretty simple and would work well for this relatively straightforward integration.

Why JSON?  The customer's web developers were used to JSON-based web services, so that was much easier than trying to implement a SOAP based web service or anything that involved XML.  Neither the client's web developer nor I like XML, so I was open to trying JSON.

So with those architectural choices made, we had a few implementation details to work out.  How would we authenticate calls to the web service?  The client's developer recommended HMAC--something that I had, sadly, never heard of before.  HMAC is a very clever and simple authentication method where you hash the contents of a request combined with a secret shared key.  The resulting hash produces a unique "password" of sorts that is effectively impossible for someone else to forge.  When the web service receives the request and the HMAC value, it performs the same hash on the request data, with the same secret key.  If the resulting value matches the HMAC value submitted by the caller, the request is considered valid.  We chose to use SHA-256 for our hashing algorithm.

Next was the credit card data.  Even though the web service would use SSL and only accept HTTPS requests, we still did not want to transmit the credit card data as plain text.  We decided to encrypt the credit card info using AES-128.  We thought that would be pretty straightforward, but it ended up being more difficult than we expected.  One challenge was figuring out how to choose an "initialization vector" (IV), and a second challenge was learning how AES is implemented in PHP vs. .NET--it took us a while to figure out that there are different default settings for PHP encryption, so we had to dig pretty deep and spend several hours researching every one of the encryption settings.  We finally figured out that PHP uses NULL padding by default, where as my encryption library uses PKCS7 padding by default.  Got that?  Easy peasy lemon squeezee!  (okay, so it is not obvious at all)

In the next several posts on this topic, I'll explore each of the elements of the project in more detail.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com