Accpac Payment Processing

I blogged about our plans for adding credit card processing to Sage ERP Accpac here. At that point we had the general design worked out and we were just beginning development. Now development has come along quite a way, and we demo’ed the product to partners at TPAC. We received a lot of good feedback. I gave the presentation, but in many regards the knowledge of the product and credit card processing in the audience was much greater than my own. So a few questions were left un-answered and several good suggestions were made. It is always fun to give a presentation where the audience is so involved and passionate about the topic. Several of the points brought up were very good and are being incorporated into the product. This is the good thing about our Agile development process, that we can continually get feedback from clients and partners and incorporate it into the product as we develop it. The goal of this blog posting is to:

• give more details on our payment processing solution
• provide some screenshots
• answer the several questions that I couldn’t answer during the session
• list the suggestions that we are going to incorporate into the product before release
• re-iterate any features that are deliberately not being included.

Accpac Payment Processing Walkthrough

Now that Payment Processing is working and in the later stages of development, we can walk through the process with a few screenshots. Keep in mind that some of the labels, wording and screens will change a bit before final release.

Setup

To setup Payment Processing you just need to sign up with Sage Payment Solutions to obtain a merchant account and then enter that into the Accpac Payment Processing Setup screen:

As pointed out by several people, having just one of these is insufficient and we will change this screen to accept multiple IDs. Next you need to setup some A/R Payment Codes with the new Payment Type of “SPS Credit Card”:

The various credit card processing functions will only be available when the document you are dealing with has this payment type.

If you have customer credit cards on file, you can enter them into the A/R Customers screen which now has a Credit Card tab. You can enter as many cards as you like on this screen. You can set one as the default card. The credit card numbers aren’t stored in Accpac, they are stored in the Sage Payment Services vault on a secure server in their facility. The Credit Cards aren’t handled by Accpac nor are they stored anywhere on customer’s own computers.

Entering an Order and Performing a Pre-Authorization

Below is the Order Entry screen where an order has been entered and we now want to pre-authorize the card, so we can reserve credit limit for when we charge the card when we ship the product. So the user has pressed the Pre-authorize button and get this screen:

Then you enter the Payment Code and adjust the amount (you may want to raise it if you anticipate additional costs like shipping and handling, or lower it if this is just a deposit). Then you get the Pre-authorize processing screen where you can verify the credit card information before charging the card.

When ready you hit the Process Pre-authorization button and control is transferred to Sage Exchange which then puts up the screen that will really affect the Credit Card.

Then when you hit Submit the Pre-authorization will be processed. According to credit card processing rules you aren’t supposed to charge credit cards until you actually ship the product. So when you ship the product you will now follow the same sort of procedure, basically applying an O/E Pre-payment to the Order/Shipment/Invoice following the same sort of process outlined above.

Feedback and Questions from TPAC

This section outlines some of the questions and concerns that were brought up at the TPAC session. Basically to answer any outstanding questions and to highlight the feedback that is being incorporated into the product.

More than 1 Merchant ID. I need more than one Merchant ID per currency. I might have different Merchant IDs by geographic location or I might have different Merchant IDs for transactions of different risks such as card present versus over the web. We are adding this feature to the product.

Capture Invoice Amount. Change the default amount on capture to be the invoice amount rather than the pre-authorization amount. Often the pre-authorization covers unexpected costs and is on the high side. We will incorporate this change into the product.

Notify if Pre-payment Already Made. When a partial shipment occurs for an order that was originally paid via credit card, how does the shipper know that the backfill shipment now needs to be charged? This issue negatively impacts any company that creates backorders, which is a significant percentage of our base. We will incorporate this change by displaying a warning message that a prepayment already made by credit card. Option presented to process card payment; if selected common popup defaults original card used for first shipment

Refund to different type. Need to refund to something other than the credit card that made the transaction. Perhaps this credit card was lost, stolen or cancelled.  We will now allow refund to other payment types such as check. We will not allow a refund to a different credit card due to credit card compliance issues.

Disallow capture on shipment. Is it a problem having the a credit card capture on the shipment screen since the shipment can be deleted or not saved after the credit card is charged?  We will catch this during day end processing and flag it, there is also a full audit trail from the virtual terminal, but there seems to be sufficient concern that if you capture during shipment we will force you to generate the invoice in order to capture the card.

How to separate credit cards for Bank reconciliation? If you really need to keep things completely separate you will need to use separate Banks which means only doing one type of credit card per A/R Receipt batch. You can track things separately by using different A/R Payment Codes, but there isn’t a way to separate these in Bank reconciliation and they don’t affect the G/L distribution. One thing to note is that you can reconcile deposits by detail again in Accpac 6.0A PU1, so you don’t need to do the whole deposit at once if statements come in at different times. Also in reconciliation if there are lines in the deposit with the “SPS Credit Card” payment code then this enables you to enter credit card charges. Also remember there is the Deposits Register which gives detailed information on the data being deposited from the sub-ledgers.

Multiple Pre-authorizations. I need to do multiple pre-authorizations on an order to different credit cards (because the client doesn’t have enough credit limit on one card)? We don’t support this, if you really need this then you will need to use an ISV credit card product. We do support charging multiple cards for an order, so you can charge three cards to pay the amount, but you can’t pre-authorize more than one card. Another note is that each charge has to be on a separate pre-payment, you can’t have multiple charges on a single pre-payment.

Different Processor. I need to use another processor than Sage Payment Services? Sorry we only support the SPS processor.

International. Sage Exchange only supports transactions in CAD or USD from Canada or the US. This is a current limitation, if you require additional countries or currencies then you need to use and ISV product.

Summary

The goal of the Accpac Payment Processing module is to provide easy credit card processing with functionality that will satisfy most customers. We aren’t looking to build a large module that can solve every possible scenario. For these we have an active ISV community that either has much larger solutions or will provide customizations and extensions to our core offering. We are trying to keep our solution simple so it works well for most customers, that it is easy to use and will be well adopted. Often complexity, although theoretically it can address more cases, tends to be more of an obstacle to adoption since the majority of customers with straight forward requirements find it hard to figure out or burdensome to use (due to all the options).