Update (May 8, 2014): Writing an integration for credit card processing has changed greatly for AX 2012 R2 and AX 2012 R3. Instead of modifying the EFT plug-in for the proper way to integrate is with a payment connector. The payment connector is shared among POS, Online Store, and Dynamics AX Accounts Receivable. Please contact support for documentation and sample code for writing a payment connector.
Update (June 5, 2012): The AX for Retail 2012 version of the EFT sample plug-in will not be hosted via this blog. Please contact Microsoft Dynamics Technical Support for information about obtaining an updated sample compatible with AX for Retail 2012.
We often receive requests for a better sample EFT (electronic funds transfer) plug-in for the POS. This is especially important in regions other than the U.S. where credit card processing may be handled much differently.
The project that we ship with the POS Plug-ins (sample code) is different than our other plug-ins because it isn’t the actual source code for the compiled DLL that we ship with the POS. There is a very good reason for this: the shipping EFT plug-in uses Payment Services for Microsoft Dynamics ERP (formerly “Dynamics Online”) as its back-end processor. The product team does not want to expose the specifics of how Payment Services is called (i.e., the API), so we consider the code in EFT.dll to be proprietary.
This would be fine if the Payment Services-specific code was all that was removed from the EFT sample that we do ship. However, in addition to taking out the calls to Payment Services, the sample is also missing things such as the user interface (credit card and debit card forms), hooks into the magnetic stripe reader events, and the basic process flow of the card authorization process. This makes it very difficult to get started on writing your own credit card processor.
This post aims to provide a better EFT sample with some of those things added back in. This new sample is based on the full source code of the shipped EFT.dll with just those Payment Services called removed. It also adds comments to the code to assist you in understanding the process flow and where to store data (authorization code, rejection reason, error messages) that you receive back from your card processor. This is a much better way to get started with your development.
At the end of this post is a zip file containing the source code for the new sample. You will want to start by reading the included Readme file (EFT_NewSample_Readme.docx) and then you can create a new Visual Studio 2008 or 2010 solution and add EftNewSample.csproj to it.
One additional note with respect to forms. All three forms (two for credit card and one for debit card) are exactly the same as the forms that are used by the EFT.dll that ships with the POS; modification to those forms was not a goal of this sample. You will likely need to make changes to these forms – if so, you will need to purchase and install DXExperience Winforms from DevExpress. Details can be found on here: AX for Retail: Using DevExpress for POS Customization.
This sample is provided with no formal support, but we would definitely welcome feedback and questions.
[Edit (January 16, 2012): Small modification to zip file. No code changes.]