Credit Card – NAV – Version 2.0.0.4
Features
Updated cardholder name to first name and last name
Due to the information required in the API, the field “Cardholder Name” is now updated to have a “First Name” and “Last Name”.
More detailed integration into eBizCharge Connect portal
When the payment service is defined on a sales invoice, the invoice is uploaded to the eBizCharge Connect Portal. When the invoice is paid within Dynamics NAV, the invoice is removed from the portal.
Invoices can be paid by customers in the eBizCharge connect portal. A customer can log on and enter credit card information on the portal and then pay multiple invoices with it. This information is downloaded into Dynamics NAV and the invoices are marked as paid.
New functionality is available on the customer card to send an initial email to an email address to invite this customer to register for the Connect Portal. Once a customer has signed up, the customer can pay invoices on the portal, but also enter credit card information. These credit cards then can be used in Dynamics NAV for payment without having to ask the customers for their information over the phone.
Setup to define, if multiple authorizations or one authorization per order would be done when order changes
Since certain cards how authorizations for a while and display these authorizations as pending charges on the customer’s statement, a new setup has been added to allow additional authorizations being created when the order amount changes. Each authorization results in a separate charge on the credit card.
When the setup is set to void the original authorization when the amount changes, a new authorization is created for the higher amount. This can result in bigger pending charges on the customer’s credit card.
It is important to not authorize before an order is finalized.
Changed utilized API
A new version of the underlying API is now utilized to allow better integration into the gateway and to utilize the latest security features.
Changed setup credentials required
New credentials are required for a merchant account. These credentials are utilized with the change API and are the ones that were setup on the payment service in older versions.
Allow definition of credit card clearing accounts by merchant
To allow easier reconciliation of credit card charges, it is now possible to define different clearing accounts on the different merchant accounts.
Allow changing test to live and live to test mode for merchants to allow usage for test databases
When changing the system from test to live or from live to test in a system that has credit cards defined already, errors happened, since the data was not in synch with the live or test account on the merchant. You can now switch to allow creating test systems from your production databases easier.
Removed transactional data from system to store less sensitive data
To make the credit card information stored in your system more secure and ensure PCI compliance, we have removed any information that is not required to actually process a particular transaction (e.g. a refund to a charge).
Allow different merchants for different countries or different currencies
You can now define different merchant accounts to be used for different countries or currencies (based on the customer’s setup) or different dimensions. It is important to understand that the credit cards are stored in the merchant, so it is not possible to easily switch merchants for specific transactions.
Allow merchant processing of European merchants
We are now fully supporting the ability to process credit cards for European and Mexican merchants. Our gateway is currently in the process of expanding to the European market and we are ready with our new version.
PCI Validation
We have completed the process of PCI validation of the credit card solution. You can be sure that your customers’ credit card information is fully secure.
Bugfixes
Url is empty after setup through wizard
When setting up a new environment, an error message was displayed for the first transactions with the eBizCharge Connect portal stating “Uri is empty”. This has been corrected.
Standard Currency missing on Currency Card
The field “Standard Currency” was only shown on the currency list, but not the card and therefore was not editable. This has been corrected.
refund service invoices creates credit memo with invoice number
When a service invoice is refunded, a credit memo is created with the invoice number as the credit memo number. This resulted in a warning that a number was used multiple times when using Navigate. This has been corrected.
“Customer doesn’t exist” when creating new card from service order
When a new card was created from the lookup of the credit card no. from the service order, an error message was shown that the customer doesn’t exist. This has been corrected.
“a transaction has to be started” when changing payment method on service order
When changing the field “Payment Method” on the service order in the credit card detail page, an error message was shown in earlier versions of NAV stating “a transaction has to be started, before changes can be made”. This has been corrected.
PreAuthorization was not always properly voided
When new credit cards were created and then a pre-authorization was created to validate the credit card information, the transaction was not always properly voided. This has been corrected
allow partial charge on order against credit card
It was not possible to only perform a partial charge to a credit card against an original authorization. This has been corrected.
When card assigned on order and click “Charge”, question was missing which card to use
When a credit card was charged manually for an order by pressing “Charge” in the Ribbon and a credit card was already defined on the order, the confirmation was not displayed “Do you want to use the existing credit card…”. This has been corrected.
When new credit cards are added and initial validation is required, require security code entry based on setups
When the setup defined that a security code is always required or at the time of the first transaction, the security code should have been required to be entered, but it was not asking for it at all. This has been corrected.
Card validation ($0.05) was done multiple times when entering new card on order
When entering a new credit card on the detail page on a sales document, the initial validation for the credit card was performed multiple times, which resulted in multiple authorizations on the credit card.
Multiple charges against order did not work always
It was possible to charge more than the actual order amount against a sales document when a partial order amount was charged originally. This has been corrected.
Item level detail was not transmitted preventing PCI level 3 transactions
When transmitting credit card transactions, especially “Authorize”, “Sale”, and “Charge”, line level details were not transmitted. This has been corrected.