Web Services in hours instead of days, weeks, or longer
It’s nice to measure programming enhancements in hours instead of days, weeks, or months. .Net Web Services made my day.
I’ve been working on our ecommerce framework and we recently made the decision to reduce costs by processing credit card transactions in two distinct phases. Let me share our architecture a bit with you:
We have various front end systems, some in old school ASP, some in ASP.Net, and some as Managed .Net Windows applications. These front-ends hook into our .Net business object layer for services such as Credit Card processing, Calculating Shipping Info, etc (per Microsoft’s SOA recommendations, these are exposed as web services for the most part).
On the client applications, we apply the Luhn Formula to validate that the CC number is legit. Of course, we also validate that name, address, etc must be provided.
In our business objects, our gateway to the bank exposes a secure API including a two-phase transaction process: phase 1 is Authorizing the Credit Card and amount, phase 2 is Committing the transaction. In my experience, this is how all credit card gateways operate – but I’ve only worked with a handful of banks and your mileage may vary!
So, as I was saying, we decided to process these two phases separately to reduce our costs. Phase one, Authorization, will be called through the customer check out process (after we test with the Luhn Formula) while phase two, Commitment, will be called from the Administrative console. How does this reduce costs, you might ask? Before making this change, we got a lot of declined transactions due to customer typos (misspelling a last name or transposing a zip code digit) – by the time an employee processed the two phase transaction with the gateway, the customer was long gone. We ended up having to try and contact the customer (by the way, NOBODY uses a real phone number when registering with a site and email addresses are becoming disposable too – the Mailinator is something Darrell Norton pointed out to me); this was a frustrating and time consuming experience, for the customer and our organization; our business suffered because of it.
Enough preamble . . . you get why we wanted to include the Authorization phase of the transaction in the checkout process. My point in blogging about this is that our Web Service middle tier made this so friggin easy! Once I nailed down the code to invoke our Web Service from ASP classic . . .
[warning: classic ASP code ahead, hide your children and valuables]
Set soapClient = Server.CreateObject( "MSSOAP.SoapClient30" )
soapClient.ClientProperty( "ServerHTTPRequest" ) = True
soapClient.mssoapinit( “WebServiceURL.asmx?wsdl” )
returnValue = soapClient.MyMethod( “PARAMS” )
Very easy, thanks to the SOAP Toolkit and WSDL standards, although it depends slightly on the Soap Toolkit you use. I say .Net made this really easy because Visual Studio .Net is a premiere tool for web service development: you can build, test (and debug!), and deploy the services with such ease. The Authorize and Commit functionality was already implemented in different methods, I just had to expose each as it’s own public method and slap a [WebMethod] attribute in there. I deployed to our test server and had the whole thing done in hours NOT days.
Now we’re on to the testing and performance tweaking phase (I also know there are some additional Attributes to employ on the webMethod, but that’s another blog).
Happy .Netting