• No results found

SalesPad for Dynamics GP Credit Card Processing Setup and Credit Card Payments

N/A
N/A
Protected

Academic year: 2021

Share "SalesPad for Dynamics GP Credit Card Processing Setup and Credit Card Payments"

Copied!
12
0
0

Loading.... (view fulltext now)

Full text

(1)

SalesPad for Dynamics™ GP

Credit Card Processing Setup and

Credit Card Payments

A software product created by SalesPad Solutions, LLC. Copyright 2004-2011. www.salespad.net

Contact Information

SalesPadSolutions, LLC.

3200 Eagle Park Drive, Suite 100 Grand Rapids, MI 49525

Phone: 616-245-1221

Email: support@salespad.net Web: www.salespad.net

Legal Information

Copyright Copyright © SalesPad Solutions, LLC. All rights reserved. Trademarks SalesPad is a registered trademark of SalesPad Solutions, LLC. Published December 2011

(2)

Overview

The Credit Card Processing function allows users to process credit card authorizations, charges, and credits through SalesPad®. SalesPad offers users the ability to capture credit card payments and deposits during order entry, and allows storage of multiple credit cards per customer (beyond the one credit card per customer that Dynamics GP allows).

Note: SalesPad only supports US credit cards.

Note: On orders, users can enter both payments and deposits. On invoices, only payments are

supported. A deposit may show on an invoice only if it was entered on the order and transferred to an invoice through Dynamics GP.

Tables

Credit card transactions are recorded in both Dynamics GP tables and SalesPad tables: GP Payment table - SOP10103

SalesPad Payment table – spSalesDocumentCreditCardPayment

If the credit card payment/deposit is recorded in GP, this transaction will not be visible within SalesPad because the information is only written to the GP tables. For transactions recorded in SalesPad tables, the data will be stored encrypted.

Credit Card Type Setup

Credit cards can be set up in two ways in Dynamics GP. First is a Bank Card, which requires a checkbook ID to be assigned. All transactions for a Bank Card will be applied to the assigned checkbook. The Second type of card is a Charge Card, which requires an account number to be defined. All transactions for a charge card will be applied to the defined account number. Note: The Checkbook ID can only be changed from an Invoice document type.

Payment vs. Deposit

Payments can be made on orders and invoices; deposits can only be made on orders. A deposit will immediately create a GL transaction creating a cash receipt. Payments mark an amount on the invoice as paid and will not create the receipt until the invoice is posted.

Note: These differences are based on GP functionality – a payment doesn't hit the GL until the invoice is posted whereas a deposit hits the GL as soon as the deposit is saved. SalesPad Solutions recommends talking to your GP dealer about which way fits best in your environment.

(3)

Configuration

Payment Processors

You will need to open a payment gateway processing account. SalesPad supports the following credit card processors: PayFlow Pro (formerly VeriSign), Authorize.Net, and AssureBuy/BluePay. SalesPad can process single credit card transactions through third party interfaces Azox and Nodus; batch processing can be performed with this software in GP. See the Payment Processor Setup section for more

information on processor setup.

Security

In Modules > Security Editor:

1. Under the Security column, enable Sales Document Payments:

2. Set the security sub-settings to reflect the type of transactions to authorize 3. Enable Payment Processor Setup

Note: You must log out of SalesPad™ and then back in for security changes to take place.

Settings

In Modules > Settings:

1. Type “credit card” in the filter line

2. Under Credit Card Processing, specify the following settings:

Allowed Charge Types: Authorization, Charge, or Manual

Default Credit Card Mappings: Default mapping of Credit Card types to Dynamic Credit Card names – Supported: AM, DI, MC, VI

Default Payment Processor Name: This must be specified when two or more payment processors are defined

Default Charge Type: Specify one of the following – Authorization, Charge, Manual

Lower the Payment Amount to match total on Capture: Specify True or False (True is only applicable if your company will be charging an upcharge percent on preauth and if the Authorization Up Charge Percent setting under Sales Entry Overrides has a value.

(4)

Refer to the SalesPad Settings Guide for more information.) Note: These two settings are only available in versions 4.0 and higher.

Mask GP Credit Card Numbers: Specify True or False

Preauth Hold Code: Configure the code in Sales Order Processing Setup in Dynamics™ GP

Authorization Up charge Percent:

3. If you wish to automatically store the customer’s credit card on the SalesPad Credit Card file, set Save Credit Card to Customer Record (under Sales) to True

4. Under Sales Entry Override, specify the following settings:

Auto Fill Credit Card Number: Specify True or False

Prompt for Credit Card Payments: Specify True or False

Close Payment Screen When Fully Paid: Specify True or False

5. Under Sales Document Entry, you can set Split CC Payments to True to have credit card preauths split between documents when a document is split (otherwise, entire preauths will move to the .1 document). See Also: Splitting a Sales Document

6. Click Save

Payment Processor Setup

AUTHORIZE.NET – CREDIT CARD PROCESSING INFORMATION Connection Method: AIM

Note: DEPOSIT setting has no effect on Authorize.Net. It refers to the difference between a deposit and a payment within GP. CHARGE can be done on either a deposit or a payment; the only difference is in how GP treats the transaction.

Request a test account through Authorize.Net by visiting http://developer.authorize.net/testaccount/ . This link will walk through the process and provide everything needed to test payment gateways with Authorize.Net. For valid testing, set Authorize.Net to Test and set SalesPad to Production.

(5)

Note: When you try to process a credit card for an order with the Send Line Item Detail setting (Modules > Payment Processor Setup) enabled (set to True), since Authorize.Net limits the detail to only 30 lines, any transaction with over 30 lines on the sales document will be declined. Disable this setting (set to False) to eliminate the issue.

TO SET UP PAYMENT PROCESSORS IN SALESPAD:

Note: To set up BluePay processor in SalesPad, you will select the AssureBuy processor from the list and change the following information:

Admin Web URL: https://secure.bluepay.com/login

Gateway Primary Server: https://secure.bluepay.com/ics_gateway.exe Gateway Secondary Server: https://secure.bluepay.com/ics_gateway.exe

Payment Gateway UserID: can be found on the BluePay website’s administration list– Account ID Payment Gateway Password: can be found on the BluePay website’s administration – Secret Key The remaining fields will be entered as described in the following instructions.

In Modules > Payment Processor Setup: 1. Click the New button

2. Select the Payment Processor Type and click OK 3. Enter the Name of the Payment Processor and click OK

4. Enter the applicable information regarding the payment processor

Note: A payment processor User Name and Password may be needed to complete this step. 5. Click Save

6. Repeat for any additional payment processors

TO SET UP PAYMENT PROCESSORS IN DYNAMICS™ GP: 1. Log in to Dynamics™ GP

2. Go to Tools > Setup > Company > Credit Cards

(6)

4. On the Note, enter /salespad

5. Click Attach 6. Click Save TEST TRANSACTIONS

Note: You cannot submit a test transaction while in Test mode in SalesPad. You must set either the payment processor or SalesPad to Test and the other to Production for valid testing to work. The payment processor should be Test and SalesPad should be Production.

(7)

Multiple Credit Card Processors – Setting a Default

If you need to use multiple credit card processors and have a default set based on specific criteria, the following SQL can be used to set the default.

First, you need to add a user defined field called sf_CreditCardProcessorName as a text field long enough to hold the processor name (see the SalesPad User Defined Fields document for more information on adding a user defined field).

Next, make sure the following trigger is in place: set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON go

Create TRIGGER [dbo].[spt_spxSalesDocument] ON [dbo].[spxSalesDocument]

AFTER INSERT, UPDATE AS BEGIN

-- SET NOCOUNT ON added to prevent extra result sets from

-- interfering with SELECT statements.

SET NOCOUNT ON;

IF EXISTS (SELECT * FROM syscolumns WHERE name =

'sf_CreditCardProcessorName' AND id = OBJECT_ID('spxSalesDocument')) BEGIN

DECLARE curDocs CURSOR FOR SELECT Sales_Doc_Num, Sales_Doc_Type FROM INSERTED

DECLARE @salesDocNum VARCHAR(21)

DECLARE @salesDocType VARCHAR(15)

OPEN curDocs

FETCH NEXT FROM curDocs INTO @salesDocNum, @salesDocType WHILE @@FETCH_STATUS <> -1 BEGIN

EXEC sppSetDefaultCreditCardProcessor @salesDocNum, @salesD ocType

FETCH NEXT FROM curDocs INTO @salesDocNum, @salesDocType END CLOSE curDocs DEALLOCATE curDocs END END SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO

ALTER PROCEDURE [dbo].[sppSetDefaultCreditCardProcessor] @salesDocNum VARCHAR(21),

@salesDocType VARCHAR(15) AS

-- To customize this logic uncomment and call this proc,

-- then RETURN to bypass the default processing in this stored proc EXEC spcpSetDefaultCreditCardProcessor @salesDocNum, @salesDocType

RETURN

DECLARE @paymentProcessorName VARCHAR(100) DECLARE @prefix varchar(3)

(8)

set @prefix = substring(@salesDocNum, 1, 3) DECLARE @numProcessors INT

SELECT @numProcessors = COUNT(1) FROM spUserSetting WHERE settingKey LIKE'Nam edPaymentProcessor_%'

IF @numProcessors = 1 BEGIN

-- if there is only 1 payment processor defined, just use it.

SELECT @paymentProcessorName = settingKey FROM spUserSetting WHERE settingKey

LIKE'NamedPaymentProcessor_%'

END ELSE BEGIN

-- TODO: figure out a good way to pick the default when more than 1 processor defined

SET @paymentProcessorName = (SELECT TOP 1 settingKey FROM spUserSetting

WHERE settingKey LIKE 'NamedPaymentProcessor_%' and settingKey like '%'+@pref ix+'%'

ORDER BY settingKey) END

DECLARE @startPosn INT

SET @startPosn = CHARINDEX('_', @paymentProcessorName)

SET @paymentProcessorName = SUBSTRING(@paymentProcessorName, @startPosn+1, LEN(@paymentProcessorName)-@startPosn)

DECLARE @sql NVARCHAR(1024)

SET @sql = N'UPDATE spxSalesDocument SET

sf_CreditCardProcessorName=@paymentProcessorName2 WHERE

Sales_Doc_Num=@salesDocNum2 AND Sales_doc_Type=@salesDocType2 '

DECLARE @params NVARCHAR(500)

SET @params = '@paymentProcessorName2 VARCHAR(100), @salesDocNum2 VARCHAR(21), @salesDocType2 VARCHAR(15)'

EXECUTE sp_executesql @sql, @params, @paymentProcessorName2=@paymentProcessor Name,@salesDocNum2=@salesDocNum, @salesDocType2=@salesDocType

GO

SET ANSI_NULLS OFF GO

SET QUOTED_IDENTIFIER OFF GO

SET ANSI_NULLS ON GO

SET QUOTED_IDENTIFIER ON GO

ALTER PROCEDURE [dbo].[spcpSetDefaultCreditCardProcessor] @salesDocNum VARCHAR(21),

@salesDocType VARCHAR(15)

AS

DECLARE @paymentProcessorName VARCHAR(100)

DECLARE @prefix varchar(3) set @prefix = substring(@salesDocNum, 1, 3)

DECLARE @numProcessors INT SELECT @numProcessors = COUNT(1) FROM spUserSettin g WHEREsettingKey LIKE 'NamedPaymentProcessor_%' IF @numProcessors = 1

(9)

-- if there is only 1 payment processor defined, just use it.

SELECT @paymentProcessorName = settingKey FROM spUserSetting WHERE settingKey

LIKE'NamedPaymentProcessor_%'

END ELSE BEGIN

-- TODO: figure out a good way to pick the default when more than 1 processor defined

SET @paymentProcessorName = (SELECT TOP 1

settingKey FROM spUserSetting WHERE settingKeyLIKE 'NamedPaymentProcessor_%'

and settingKey like '%'+@prefix+'%'

ORDER BY settingKey) END

DECLARE @startPosn INT

SET @startPosn = CHARINDEX('_', @paymentProcessorName)

SET @paymentProcessorName = SUBSTRING(@paymentProcessorName, @startPosn+1, LEN(@paymentProcessorName)-@startPosn)

DECLARE @sql NVARCHAR(1024)

SET @sql = N'UPDATE spxSalesDocument SET

sf_CreditCardProcessorName=@paymentProcessorName2 WHERE

Sales_Doc_Num=@salesDocNum2 AND Sales_doc_Type=@salesDocType2 '

DECLARE @params NVARCHAR(500)

SET @params = '@paymentProcessorName2 VARCHAR(100), @salesDocNum2 VARCHAR(21),

@salesDocType2 VARCHAR(15)'

EXECUTE sp_executesql @sql, @params, @paymentProcessorName2=@paymentProcessor Name,@salesDocNum2=@salesDocNum, @salesDocType2=@salesDocType

GO

SET ANSI_NULLS OFF GO

SET QUOTED_IDENTIFIER OFF GO

(10)

Usage

To apply a credit card payment:

1. Open or create an order or invoice

2. On the header, go to Actions > Payments on the sales document header, or click the amount hyperlink in the Payment field. The Payments window appears

3. Click on the Credit Card tab

4. Click New Payment

5. Fill out the credit card and billing information as needed; information may be pre-filled. Note: For versions 4.0 and later, you can swipe credit cards to auto-fill some information. Note: Billing Address information defaults to the billing information on the Customer Card. If the customer is using a personal credit card, the Billing Address information must either be changed to match the customer’s personal information, or the payment processor must be set up not to verify addresses (Turn AVS off).

6. Select a Type (Payment or Deposit) and Transaction Type:

Charge – An instant charge will be applied to the credit card

Manual – Writes information to table only; equivalent to adding the payment into GP. When using this method, users can process credit cards using Sales Batch Processing

(11)

Authorization – Places a hold on the card for the amount; a capture must occur later to complete the process. PreAuth Batch Processing (Modules > PreAuth Batch Processing) can be used to complete the capture process:

After processing from this screen, completed captures will automatically move to the bottom processed area of the window.

Note:

 PreAuth Batch can display both orders and invoices; orders transferred to invoice will keep the pre-auth code attached.

 If an order is transferred to an invoice in SalesPad, the CC pre-auth stays on the document.

 If an order is transferred to an invoice in GP, the CC pre-auth only stays on the document if the check boxes include totals and deposits are checked when the transfer process is started. Note: With the Authorization method, the bank is responsible for expiration of the authorization if the capture is not completed. This varies by bank but is generally 7-10 days.

Note: If a Pre-Auth fails but the card still has funds held at bank, the issue is normally due to Address Verification Services (AVS) by the credit card processor. With AVS on, a card can be declined but still show as held by the end bank, because the address verification typically occurs after the bank’s authorization. If the card number is valid, it will be processed at the bank but will be sent back as invalid due to the address information. Recommendation: Turn off AVS.

You can also complete the capture process using the Payment Processor (step 7):

7. When finished filling out the information, if the transaction is to be processed immediately, click Submit to Processor

8. Click Yes to confirm

(12)

Credit cards can also be processed directly from the customer card, under the Credit Cards tab:

Note: Transactions processed from the customer card can only be applied as a credit or charge and are only applied to the account, not to a document. Since customer card credits/charges are only applied to the account, a transaction is NOT created in GP for these items. To connect a credit/charge created from the Customer Card to a document in GP, create a cash receipt in GP for the amount charged, or a credit memo for the amount credited. You can then apply the cash receipt or credit memo to the customer’s account through GP.

Note: Cash and check payments appear as credit card payments.

Because GP does not allow check or cash payments on an order (only check or cash deposits), and SalesPad does, we add a workaround by using a GP credit card called Cash. So when a cash or check payment is made within SalesPad, it will appear as a credit card payment with the card name Cash. Refer to the SalesPad Cash and Check Payments knowledge base article for setup information. If you disable this option, users will no longer be able to enter cash or checks as payments against an order.

References

Related documents

The following outlines one option for processing credit card statements which allows you to enter and process credit card payments through the Creditors Payment Processor when

In the Credit Card Processing with Element solution, when you are accepting a payment for a credit card transaction, typically when a customer is present with their card or using

The Payment Terminal Setup Wizard that walks you though the basic 8-step process for configuring a DVMAX terminal to accept real-time credit and debit card payments.. Payments

MANUALLY CHARGE A CREDIT CARD OR PROCESS A CREDIT – Once you make note in your GroupNet Solutions’ database of a player’s Invoice number, you can then process a credit card

The process by which credit card payments are processed beginning with the e-commerce merchant’s web site to a credit card processor or service gateway to the credit card

Prepaid Expenses Assets Overstated Expenses Understated LO: 3.5, 3.6 Difficulty: Medium BLOOMCODE: Analysis AACSB: Analytic EXERCISE

From perimeter security to video surveillance to access control, Honeywell provides integrated security solutions that can be easily implemented throughout government facilities of

when a piece-wise polynomial interpolation is used in the assumption of displacement field, u. Hence, the solution is not exact.. 1.7 and using the stiffness of the