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.]
Do you have the source code for AX 2012 retail?
We are now having AX 2012 retail implementation, and having difficulty on the credit card validation.
Hi Victor. Please see the note above with respect to the 2012 version of the sample. Can you open a support case and we will work with you on getting the updated sample? Thanks.
If we use stand-alone device for credit card processing like "ingenico" or the manual credit card imprinter, after successful authorization of the card, the cashier shall be obliged to register the non-cash payment at the cash register.
Is it possible configuring card tender type without physical processing (authorization card) by POS?
If not, which of tender type we can use for registering non-cash payment?
A couple of possibilities off the top of my head:
- You could modify the EFT plug-in to allow for a workflow that always simulates a successful auth/capture. This way the transaction would be identical to a card payment as far as POS is concerned.
- If you think about it, receiving this kind of payment is really no different than a personal check or a similar voucher. You could probably just set up a payment method to keep track of these types of payments. You could change the settings on the payment method for whether you wanted to require counting, tender declaration, etc. You could also change the posting account for that particular payment method as well.
I have customized the EFT plugin but the problem is to display the card types how to display this screen where the user will select the card type for the transaction.
In Ax2009 i have used ApplicationServices.ICard.GetCardType) when i write this code it gives me the form to select the card type in axapta 2009 how can i do the same for ax2012 r2.
Please help me on this one.
I have customized the EFT plugin
For 2012 it should happen automatically - if the card that is swiped matches a single card type (based on how your number schemes are set up) it will just use that card type. The only time the card type choose needs to be shown is if there are two or more matches. Can you check how you have your card type numbering set up in HQ?
Are the samples you referenced to get directly from MS support different from the samples on Retail SDK for Ax 2012 R2?
The sample for 2012 R2 is also available by opening a support incident. It is much different than 2012 R1 EFT sample. It is also different than what is in the Retail SDK when you install AX for Retail.
We have setup a button for Card tender type and an action mapped to it PAY CARD but the Payment method is not showing unlike when I select the PAY CASH Action for Cash tender type it shows drop down for PAYMENT TYPE where i can select Cash Tender type.
Everything is working fine but the Reason codes which are mapped to Card Tender Type are not popping up at the end of the transaction.