NAV Team: Integration to Payment Service in NAV 2009 R2

[Blog bot]

The Payment Service available from Online Services for Microsoft Dynamics ERP is an example of the growing availability of online services that users of ERP systems can benefit from connecting to. Adding functionality to the application through connecting to a service is new territory for us in the NAV development team, and we have learned a lot through this development project. We are looking forward to sharing the benefits of being able to expand the service, while we keep our focus on delivering the new NAV product.

The Payment Service is hosted by Microsoft and the number of available Payment Providers is growing. Today there are multiple Payment Providers like First Data, Pay Pal, and Cybersource supporting the US and Canadian markets. The plan is to grow the number of payment providers, so that the rest of the world can be supported as well. We are shipping the integration for all NAV supported countries - even though the payment providers aren't available yet - so the code is ready when the service becomes available.

The integration to the Payment Service that is included in NAV 2009 R2 will allow users of Microsoft Dynamics NAV to accept credit and debit card payments from Sales Orders, Invoices, as well as the Cash Receipt Journal. The solution will allow for both an authorization process and an automatic capture of the required amount during post as well as using it more freely on the Cash Receipt Journal.

Adding the integration to the online services has been done with a number of goals in mind:

• Keeping it simple: Adding the integration to the Payment Service will allow the user of NAV to work within NAV when he is accepting the credit cards as payments. There is no need for a third party add-on outside the normal environment. The payment information is built in to the existing order entry process, using the Sales Orders and the Invoices as a starting point. This means a simple payment flow that doesn't require a huge effort to learn and set up. This will support the envisioning behind adding services to existing installations: it must add to the existing functionality without making it more complex.
• Power of Choice: Secondly, choosing the online payment service will allow the users to choose the payment provider that suits their needs the best. There can be a difference in the transaction cost per payment provider and the user is encouraged to investigate which one that fits their scenario the best. Depending on the payment provider, there is support for multiple credit cards and currencies. Out of the box there is built-in setup for Visa, MasterCard, American Express, and Discover.
• Secure integration: Third, there has been focus on ensuring that the information that is required to handle credit card transactions is kept as secure as possible and that the design adheres to the standards of the market. To this, there are two aspects to consider: the data that is stored in the ERP system and what is being sent to the payment providers through the service.
• The ERP data includes encrypted storage of the customer credit card number as well as securing that users don't have access to the numbers.
• The payment service is also certified by following the guidance of the Payment Card Industry (PCI) Security Standards Council.

Scenarios Covered by the Integration
The areas that are relevant when describing the integration to the Payment Service can be described by the following scenarios:

1. Authorization of the amount from the Sales Order or Invoice against the customer's credit card
2. Capture of the actual amount and thereby also creating the payment in the system
3. Voiding the authorized amount
4. Refunding against an existing capture

To describe the scenarios it is useful to think about the personas using the functionality; in this case we work with Susan, the Order Processor, as well as Arnie the Accounts Receivable Administrator.

As a part of Susan's work, she receives and processes the incoming orders from the sales representatives. She will in some cases talk to the customer to validate the orders and ensure that items are available and that the price is correct according to the agreement. In some cases the customer can request that they want to pay using a credit card, instead of having to handle the invoice later. Susan has to ensure that the information required for using a credit card is available; if not, she will get the information from the customer.

If Susan needs to be certain that the customer can pay the agreed amount, she can go ahead and authorize the amount against the provided credit card information. If the result is successful the sales order can be shipped. When the sales order is posted (or parts of it) the actual capture of the amount on the sales order will automatically be processed. When capture is successful the payment will be automatically registered and money will be received shortly.

On the sales order it looks like below - there are two new fields for the credit cards - as well as a requirement to use a specific Payment Method (described below in the Getting Started section).



The scenario above is the simplest process that is supported by the new payment service integration. The following scenarios is also covered in the implementation:

1. Partial posting of the sales order will only capture the amount that is posted. The rest can be captured later.
2. It is possible from the Cash Receipt Journal to accept multiple credit cards against the same invoice. This is done by adding multiple lines in the journal - one per credit card.
3. It is possible to use a credit card transaction to cover more than one invoice. Again, this is only possible from the Cash Receipt Journal.
4. It is possible to void an existing authorization in case the amount is not needed. This is only implemented in a manual step.
5. It is possible to refund an existing transaction as well as part of a transaction. This is done through the Credit Memo.

All of the above transactions and connection to the payment service can be seen on the specific customer as well as on the specific documents. On all places a Transaction Log has been implemented that shows the status of the current transactions and if the connections have been successful or not.


Getting Started
Enabling the payment integration does require a couple of steps both inside and outside NAV:

• First of all, it is required to sign up for the Payment Service. Details can be found here: Microsoft Dynamics Online Payments Introduction. The sign up includes validating and choosing which Payment Provider to use. There is a difference in the cost and in the support, so some investigation is recommended. After signing up a Live ID and a Password is provided that is required when setting up the connection.
• Within Microsoft Dynamics NAV 2009 R2 there are a couple of steps that needs to be completed:
  • First of all, the connection needs to be setup - and this is where the Live ID and the password are required. Please note that the Microsoft Dynamics ERP Payment Service Connection Setup is only available in the Classic Client due to security reasons.

• • For the connection to carry the correct currency there is a need to fill out the currency field on the General Ledger Setup. Please verify with the help document for the correct values. Below is an example in the CRCARD payment method
  • Finally it is required that a Payment Method is created that uses the Payment Processor field as well as the bank account with correct currency as signed up with

For more information please look at the following resources:

• Help included in the release.
• For introduction to the Payment service - please look at Microsoft Dynamics Online Payments Introduction.
• For demo script and presentations please check the Microsoft Dynamics NAV 2009 R2 Readiness site.
• Please look at the Hot Topic - Online Payments Service for Dynamics NAV.

-Rikke Lassen





Источник: http://feedproxy.google.com/~r/Micro...v-2009-r2.aspx