Deploy Nav Credit Card processing easily
Why PCI Charge credit card processing?
PCI Charge integrated credit card processing solution from Expand IT for Microsoft Dynamics NAV is the goto solution recommended by Clients First Business Solutions. PCI Charge allows users to easily setup and process credit card payments directly inside of NAV, with no external hardware or software necessary. Credit card processing within NAV includes the ability to directly process (authorize, charge, and refund) credit cards from various Sales and Receivables pages, as well as the Customer page. NAV stores customer credit card information in an encrypted manner, ensuring that credit card information is secure and complies with PCI-DSS requirements.
As the setup documentation is readily available for users, the purpose of this article is to provide tips and recommendations related to implementing credit cards in NAV that is not readily available in the setup documentation. This article assumes setups have been completed and an understanding of NAV sales order processing.
Where is the CVV number?
A common question that I am asked during training and implementation is where is the CVV number stored in NAV? Well, NAV does not have a field to store the CVV number, due to the rule that it is prohibited by PCI standards from being stored. The purpose of the CVV number is to prevent fraud from stolen credit card numbers, as it is less likely that the CVV code is available when attempting to use a stolen card. What is permitted to be stored is the account number, customer name, customer address, and expiration date.
Setting up a test account:
For testing, it is recommended that a test account be setup that allows users to test processing of credit card transactions within NAV. For my testing, I used a test account from Authorize.net, which I easily setup within 15 – 30 minutes. Once you have a test account, you can search Google for test credit card numbers for the major credit card companies i.e. Visa, American Express, Discover, etc. During the Go-Live process, the setups are then updated to the “Live” gateway processor keys and setups.
In NAV 2013, a new Permission Set called E-PAYMENT is required to be setup manually with the appropriate permissions. An important note is that even if the user is a super user, this role is required for each user in order to process E-Payment credit card transactions. See below for suggested table permissions. Note that additional roles can be setup to separate read/modify/insert/delete permission if necessary.
Address verification and authorization:
When setting up a new customer credit card account, NAV has a specific field to enter the address number. For example, if the address is 6237 Rice Boulevard, then ‘6237’ is entered in the ‘Address Number’ field and the street name is entered in the ‘Address’ field. By separating the address number and street name, NAV can provide exact information to the gateway provider to ensure better address matching schemes.
During sales order processing, after the data entry has been completed, the user releases the sales order and enters into the E-payment area to process the customer’s credit card. When the user hits ‘Process’, an authorization request is sent to the gateway provider. If you have address verification turned on with your gateway provider, the gateway provider verifies that the address entered in NAV matches the address on file for the customer’s credit card account.
What happens if the address in NAV does not match the address on file?
If the address verification fails, the user will get error message, and NAV will not authorize the amount requested. What is not generally known is that although NAV did not capture a valid authorization, the gateway provider processed an authorization for the amount requested on the customer’s credit card account. The NAV user then needs to re-verify the address with the customer and re-process the credit card authorization. What this means is that two authorizations will now be on the customer’s credit card account.
Let’s take an example of a $100 sales order. The customer service representative (CSR) attempts to process the customer’s credit card, with the result that the address verification fails. Subsequently, the CSR calls the customer, reconfirms the address, and then updates the customer’s credit information with the new address. The CSR then process a second authorization successfully. The result of this scenario is that the customer now has two authorizations on their credit card account totaling $200. The customer would then need to be notified, and then the customer would have to call their credit card company to remove one of the authorizations. This is a bit uncomfortable to say the least, but I have verified this with two customer service representatives at Authorize.net. that this how it works with Authorize.net. The other option is to turn off address verification, but this is not generally recommended as it could lead to collection issues.
Written by Mark Stept
Clients First Business Solutions, LLC