The other day we started looking at various credit card payment gateways in order to be able to process transactions on one of our client’s e-commerce sites. After reading up on a few alternatives, we hoped to be able to implement an easy all-in-one solution such as PayPal’s Website Payments Pro. Unfortunately, this program is not available in Canada. Apparently it will be some time soon, but we can’t wait on them for e-commerce, obviously.

After looking round a bit more, we found a payment gateway popularity contest and since we had seen a bunch of programming samples for Authorize.NET, it interested us. However, once again, Canadians cannot use this payment gateway. We looked at PSIGate the most popular one in Canada and were interested by their offering but, in the end, our client decided to go with BeanStream, another Canadian firm. BeanStream offers Electronic Funds Transfer programs (EFT) which is very useful for collecting royalties from franchisees. I may post something concerning EFT later in the year.

In any case, we were a bit disappointed that the site was not full of technical information, programming samples, SDKs, etc.  We had to contact them to obtain a copy of the documentation, something we would not have expected from a technical company in the days of Web 2.0. Having to contact them increases their contact base but shows a certain lack in openness, something which is gaining stream nowadays. The integration process seemed straightforward, as expected. Send out a request and get a response back. We were a bit surprised that the requests were encoded as you would encode a query string instead of XML with a freely available XSD/DTD. The sample code provided was dirt simple VBScript (ASP) with other technologies that we don’t use.

Some would call us lazy, but we feel that re-inventing the wheel is not a mission one should waste time on. Therefore, we started googling for freely available code for C# for payment processing using BeanStream, figuring that if the company itself doesn’t make this code available, someone must have posted an article on The Code Project or at least that we could find some code on Google Code Search. We found some PHP and some Perl, but since we code in C#, this code was not useful for us. Therefore, we started our implementation from scratch for our own purposes.

The code that follows is the current state of our implementation. It has not yet been tested in production, but our unit tests are working. We discovered a SOAP API after signing up and used that instead of the query string format.  We implemented a bit of parameter verification to make it easier to integrate with our higher level structures, which don’t have strict field lengths. Hopefully you’ll find this code useful and will let us know if you find any flaws. In our code, we've subclassed this base class to insert logging and conversion from our object-oriented data structures.

We found that the documentation was not very good, especially for the SOAP API. There were tons of mistakes and inconsistencies but, worst of all, the documentation was only available in a PDF format from which we cannot copy-paste. Therefore, the 500+ error messages or 100+ country codes cannot be easily exported to an Excel spreadsheet in order to create lookup tables in our database. We're building multi-lingual systems and don't have the time to translate their 500+ error messages, so we chose a simple solution as seen in the code. All errors (and exceptions in our code) are mapped to large encompassing classes. Fortunately, we were put in contact with VERY helpful people who responded extremely rapidly to our technical questions.

The source code follows. If you're interested, download the attached zip file containing the c# source code.

BeanStreamProcessing.zip (5.82 kb)

kick it on DotNetKicks.com