ePDQ intergration for nopCommerce

Posted by Ed NIce on 23 August 2010 | 0 Comments

Tags: nopCommerce, ecommerce, ePDQ, payment gateways, c#, .NET

One of the applications we use a lot is NopCommerce.

The reasons why are pretty obvious if you've used it or seen what it can do.

On a recent e-commerce project based around nopCommerce (1.6 on .NET 3.5) I needed to use ePDQ for the payment gateway.

This is all cool stuff, because I've done a lot in nopCommerce and also have done a few ePDQ integrations on bespoke dev in the past.

Another great reason for using nopCommerce is the community support, which is pretty big, normally helpful and good at sharing code. In actual fact nop themselves seem to do a pretty regular job of integrating common payment gateways and other items into the base build from user contributed code, so I was pretty confident of seeing ePDQ in there, or at least a project on GitHub or similar for it.

I was amazed that no one had actually contributed one to the project, but there were a few 'call for quote' options where people had written one and were offering it commercially.

Payment gateways in general and nop in particular are pretty easy to work with, so I wasn't going to pay for an option. If you are limited by time, want something of commercial strength or aren't really a .NET developer, the commercial offerings should be a good option, although I know noting about price, support or implementation, so check out the nopCommerce forum if you need details.

So, how do I go about adding ePDQ to nop?

Understanding ePDQ

First things first, you need to understand the payment gateway, what it expects and what it returns.

I had a little refresher on ePDQ and it all came flooding back.

Payment gateways work in one of several ways. The differences are normally in how they authenticate and secure your data, with writebacks all generally taking a familiar approach.

With ePDQ, you need to generate a secure post, send it to the encryption service on the gateway, along with a few other variables, then send the returned data to the actual gateway where the user puts in their card details.

Once payment has been made, a return url is used to update the order locally (in nopCommerce) and the user gets a nice redirect back to your site.

Understanding nopCommerce

NopCommerce is easy to use because it has a lot of in-built functionality, is well written with proper interfaces and inheritance (that most people seem to not bother with, but should) and [IMHO] has a nice usable project structure in the solution.

What makes nopCommerce scary as hell at first, is that it is quite huge. If you take a little time to understand how it all knits, it's pretty easy to just figure out the smaller pieces of code that do what you need to do.

So, nopCommerce payment types all have some big similarities that allow us to copy and complete the small difference that make up the payment methods.

All the payment methods live in their own project with a payment processor or two, have a configuration user control in the admin section of the store and a template in the templates section.

These are supplemented by response scripts that take the returned data from the gateway, update the order and do whatever you need to with the response.

Making a new payment type, eg: ePDQ

This is simply a matter or adding each required project, user control and writeback file based on the closest existing payment type.

For ePDQ, I have based my version on the SagePay processor.

The new payment type needs to inherit from IPaymentMethod and include all the required methods.

The ProcessPayment() and PostProcessPayment() methods do all the work. (I assume these are called from the checkout process once the payment method is selected. See, interfaces at work!).

My implementation creates a RemotePost object, adds some post fields, calls a local method that build the encrypted post fields via a WebClient() using a mix of data from the Order class and settings in the Settings management store (which are reflected in the payment configuration file in the Administration section of the store), then fires it all off to the gateway.

I've added most of the meaningful variables to the ePDQ configuration user control, and also added a TestMode setting, which takes the writeback values from the gateway and writes them to a log file.

One of the slighly annoying aspects of ePDQ is its lack of a test gateway or simulator, such as PagePay offers. Thinking around this for testing takes a bit of consideration, but if we take the rough process as follows:

Build an order string
Send to ePDQ
Get encrypted data back from ePDQ
Send the form post to the gateway with encrypted data enclosed
Get a writeback from ePDQ with status
Display a happy message to the user

We can see 3 or 4 meaningful places where data would be useful for debugging, so if necessary we could add logs for each step of the process. One of the big problems with debugging payment gateways is always the inability to return to a Localhost page. Having meaningful debug data will help.

So, where's the solution?

Good question. I'm writing it now, so it's not ready to be used in my projects or anyone else's just yet.

I'll probably offer it as a sample download and do a more in depth how-to at the same time.

:)