Recurring Credit Card Billing with DPS and Microsoft Dynamics CRM 4.0

Roshan Mehta, 18 November 2010

You may already know that Dynamics CRM 4.0 greatly improves productivity for businesses in any industry. One way that this is achieved is through the use of workflows, which allow you to automate business processes, saving you time and money. This post will focus on the idea of “automation”, but in the context of credit card processing.

We were recently approached by one of our clients, requesting the ability to setup recurring credit card processing using DPS. This is quite a simple task which only requires a few custom entities, a custom ASPX form hosted within CRM, and a Windows Service.

When the user fills out the custom ASPX form, we send a simple request to the DPS web service and set a flag to indicate that we are setting up a recurring transaction. We also need to pass a unique identifier which we can use when the actual recurring transactions are being processed.

Note: The unique identifier can only take a maximum of 32 characters.

These are the two parameters we need to set to tell DPS that this is a recurring transaction, along with the credit card details. When DPS receives the recurring billing request, the credit card details are in their hands, so there is no need to store credit card details anywhere within CRM, which is great for security.

To actually create the transactions, we need to develop a simple Windows Service which is setup to run every six hours. The service checks data stored inside a custom entity called Recurring Transaction which stores information about the frequency of recurrence, the start and end dates, and on which day or date the recurrence should occur. It also checks if the recurring transaction has already been processed today, this week, or this month. If the user wishes to cancel a recurring transaction, they can simple deactivate the Recurring Transaction record, and the Windows Service will not identify that record for processing.

We found that it is important to create a log of all DPS responses, whether they are successful or unsuccessful, so that our client can identify why a certain transaction failed. Failed transactions also trigger a workflow activity, which will send our client an e-mail notification, so they can further investigate any issues with recurring transactions.