Payment Processing Using iBiz

Summary

EngageIP integrates with a significant number of processing vendors. This article contains information on integrating the various gateways, testing, trouble shooting and common issues encountered

EngageIP is currently integrated with E-Payment Integrator version 6 .NET edition and only gateways associated with version 6 .NET edition are compatible.

iBiz Features

For more information go to: http://www.nsoftware.com/ibiz/EPayment/

• Credit Card processing & eCheck support for every major Internet Payment Gateway

• Check21 electronic check image processing support

• PCI Security Standards Council PA-DSS validated

• Secure data communications using up to 256-bit SSL encryption and Digital Certificates

• Reliable high volume transaction processing

• Address Verification Service (AVS) support

• Intuitive, easy-to-use, extensible component design

• Credit Card validity checks to decrease expenses that result from attempting to authorize invalid credit cards

• Small and lightweight components with no dependencies on external libraries

• Native development components for all supported platforms and component technologies

• Unlimited free Email technical support backed by an experienced & professional staff

• Rapid implementation of E-Commerce capabilities on your web or desktop applications, including: extensive documentation, sample applications, test accounts, integrated help

Processor Gateways

Below is a list of processor gateways that EngageIP Billing currently integrates with (via nSoftware):

• 3DSI EC-Linx

• ACH Payments

• Adyen

• Authorize.Net

• Bank Of America

• Barclay

• BeanStream

• BluePay

• BrainTree DirectPost (Server-to-Server)

• Chase Merchant Services

• Concord EFSNET (no longer Supported as of EngageIP 8.5.25.0)

• CyberCash

• CyberSource

• DPI Link (no longer Supported as of EngageIP 8.5.25.0)

• ECHOnline (no longer Supported as of EngageIP 8.5.25.0)

• ECX QuickCommerce

• eProcessing

• eWay

• Fast Transact

• FirstData / Cardservice Int.

• goEmerchant

• GoRealTime (Full-pass) (no longer Supported as of EngageIP 8.5.25.0)

• Heartland POS

• HSBC XML

• Innovative Gateway

• Intellipay ExpertLink

• Intuit QuickBooks Merchant Services (QBMS)

• Iongate (no longer Supported as of EngageIP 8.5.25.0)

• iTransact RediCharge HTML

• JetPay

• Landmark

• LinkPoint

• Litle Online

• Merchant Anywhere

• Merchant E-Solutions

• Merchant Partners

• Moneris

• MPCS Weblink

• NetBilling

• Network Merchants\

• NexCommerce

• NOVA's My Virtual Merchant

• NOVA's Viaklix (no longer Supported as of EngageIP 8.5.25.0)

• OGONE

• Optimal Payments (no longer Supported as of EngageIP 8.5.25.0)

• PayFlow Link

• PayFlow Pro

• PayFuse - First National MS

• Paygea (no longer Supported as of EngageIP 8.5.25.0)

• PayJunction Trinity

• PayLeap Web Services API

• Paymentech - Orbital

• Payment Express

• Payments Gateway

• PayPoint

• Payready Link (no longer Supported as of EngageIP 8.5.25.0)

• PayStream (no longer Supported as of EngageIP 8.5.25.0)

• PayTrace

• Planet Payment

• Plug 'n Pay

• PSIGate

• RTWare WebLink

• SagePay Direct

• SECPay

• SecurePay

• SkipJack

• Sterling

• Sterling XML

• SurePay / YourPay

• TransFirst eLink

• TransFirst Transaction Central Classic

• TrustCommerce

• USA ePay

• uSight

• Verifi

• Verisign PayFlow Pro

• WorldPay Select Junior Invisible

• WorldPay XML

• YourPay

• and more ...

For more information check:

Credit Cards: https://www.nsoftware.com/in/EPayment/

Echecks: http://www.nsoftware.com/kb/help/BPN6-A/ECheck.rst

If more gateways are required, it can be requested of nSoftware to include it in an upcoming release of their ePayment integrator.

Token Based VS Standard Credit Card integrations

There are several deployments of credit card processing to be considered.

• Basic Credit Card Processing - This configuration involves a standard payment processor configured on the setup tab. Credit card information is collected and saved on the user account in encrypted form and the credit card and address information is sent to the credit card gateway each time a card is to be processed - PCI Compliance Recommended due to card holder data stored

  • Example: Paypal, Cybersource, Paymentech

• Token Based Processing (local) - In this configuration, card information is entered and sent to the gateway - a token is received and saved in the local database which is used going forward to process cards. Upon processing the card, the token is transferred (no card holder data)

• Token Based Processing (remote) -   Credit card information is collected by way of a hosted payment page from the processing company. The card holder data is entered and saved on their PCI compliant network and EngageIP is provided a token which can be used to process that card. Upon processing the card, the token is transferred (no card holder data). No card holder data is held in the database directly associated with the credit card.

Processor Gateways Compatible Overseas

According to nSoftware, these gateways should work in the UK or overseas however you would need to check with each gateway to confirm they work in your region:

• Any of the Authorize.NET gateways (1), (85), (96)

• Ogone DirectLink (29)

• SagePay Direct (Previously Protx) (55)

• WorldPay Select Junior Invisible (43)

The ECheck Component

The ECheck component allows you to use multiple Internet Payment Gateways through one interface and one component. This allows for easy migration from one gateway to another, as well as quick integration into applications or web services.

The ECheck component allows your website to securely process electronic checks without the need to redirect to a third-party site. All transactions are accomplished through a secure HTTPS Post to any supported gateway. The secure response is received and then stored in the component's response properties. Any web site on a standard HTTP server or any stand-alone application can process transactions without the need for a secure server or third-party intervention.

The first thing you must do is select one of the gateways supported by the ECheck component and then set up an account with that gateway vendor. Once you have an account set up with a valid (or test) login Id and password, you can use the ECheck component.

To begin, set the Gateway property to the gateway you wish to use. If this gateway supports an alternate URL to send test transactions to, set the GatewayURL at this time.

Next, set the MerchantLogin (and for some gateways the MerchantPassword). These are supplied by your gateway vendor when you set up an account.

Now you are ready to process transactions. Not all gateways process ACH or ECheck transactions the same way. While all gateways require a bank routing and account number, some require additional information such as a driver's license number, bank name, or the account type (checking or savings). The gateways and their required properties are listed in the Gateway property.
Once all your properties are set, simply call the Authorize method. If your gateway supports it, you may also credit bank accounts with the Credit method.

Canadian ECheck Companies (CAD and ECheck capabilities)

From the list below:

• ACH Payments

• Trustcommerce via Global Payments

• Cybersource via Firstdata

Credit Card, Credit Card Token and ECheck Token Billing Rules

• For a credit card to run as part of an automated bill run, it must be set as the default payment method (bolded under payment methods on Tools page of an account)

  Open

  

• Credit cards will be processed if the 'Credit Card' check box and the 'Enabled' check box are selected on Bill Run configuration page

• Credit card Tokens or E Check Tokens will be processed if 'Run E Check Token' or 'Run Credit Card Token' are selected on the Bill Run configuration page

• Expired credit cards are not attempted. EngageIP will review existing cards and if expired, will not attempt to charge them during the bill run
  In EngageIP 8.5.14.0 the option 'Process Expired Credit Card' was added. When this option is checked expired credit card information will be sent to the processor gateway allowing the gateway to auto-renew, send expiry notifications or take some other action (depending on the capabilities and configuration of the gateway)

• Cancelled accounts will NOT be attempted during a credit card bill run. Note that cancelled relates to the back end account status type, see the Account Status Types link on the Setup page for the status types that you have defined in the EngageIP AdminPortal

• No information is stored in EngageIP for one-off payments (Tools page / One-off Credit Card Payment). This means any one-off payment refunds must be handled manually (logging into your CC gateway vs. using the 'Credit Card / Credit Card Token Refund' functionality on the Tools tab) and then once refunded the payment must also be reversed in EngageIP.  For instructions on reversing payments see the Managing Transactions article

General Card Processor and Card Type Setup

Below you will find basic instructions, test and sample configurations for specific card gateways can be found further down this page.

1. Go to the proper owner account

2. Click Setup

3. Click Card Processors

4. Click Add

5. Enter the Name

6. Select the Card Gateway

7. Enter the Merchant Login and Merchant Password

8. Enter any other configuration specific to your processor (if Tier sync or multiple branded owners is in use, select any existing configuration options that are in place for the same card processor on the other owner)

9. Enable the option Process Expired Credit Card if you want payments to be processed for cards that have expired (most payment gateways should process payments for expired cards). Typically this option should be enabled

10. Click Save

11. Click Setup

12. Click Card Types

13. Assign any card types you'll be using to that processor. i.e. Visa, MasterCard, etc. (again, where other configs exist, you can copy similar naming and config here)

Credit Card Token Processors

With Token processors credit card information is collected once for the payee and submitted to the Token Gateway.  The Gateway then returns a payment Token and specific payee details, meaning credit card information no longer needs to be stored within EngageIP.

Credit Card Token Processor Setup

First the Credit Card Token Processor must be setup, to do so follow the steps below:

1. Access the owner account

2. Click Setup

3. Click Credit Card Token Processors

4. Click Add

5. Populate the fields presented (required fields are in red)

   Open

   

   • Name - this is simply an identifier can be any value you wish to describe the Card Processor

   • Credit Card Token Gateway - select the appropriate supported gateway from the list

   • Merchant Login - enter your merchant account username, login or ID information supplied by your Gateway

   • Merchant Password - enter you merchant account password supplied by your Gateway

   • Test Mode - if selected, will allow you to run test Bill Run processing simulations on your accounts before going live. All Credit Cards whether real or fake will receive a successful response when using this check box. This should be used if you simply want to confirm that billing is attempting to process cards and should NOT be used in a production system scenario

   • Gateway URL - allows you to override the Gateway URL. This can also be used to post to a test gateway

   • Attribute - allows you to specify additional attributes specific to the gateway.

   • Configuration - allows you to enter uncommon configuration settings for the gateway, see the SSL Certificate Field Definitions section below for more information

   • Threshold Amount - enter a threshold value that will prevent credit card charges if the payment amount is less than the threshold value

   • Process Expired Credit Card Tokens - enable this option if you want the payment gateway to charge cards that have expired, typically this should be enabled

6. Click Save to save the Card Token Processor, or Save/New to save to processor and create another

Credit Card Token Payment Type Setup

The Credit Card Token Processor must be associated with a Payment Type. To setup the Payment Type follow the steps below:

1. Click Setup

2. Click Payment Types

3. Click the Add button

4. Fill out the Fields shown in the image as indicated in the list below:

   • Name - this is simply an identifier can be any value you wish (e.g. Credit Card Token)

   • Payment Type - enter Credit Card Token

   • Disbursement Type - select the Disbursement Type to use when a payment is made using this type (for example Automatic)

   • General Ledger - select the General Ledger (optional) to associate with the payment type

   • Payment Code - select the Payment Code (optional) to associate with the payment type (for instance 'Online Payment')

   • E Check Processor - used with E Check Payment Types (leave empty)

   • E Check Token Processor - used with E Check Token Payment Types (leave empty)

   • Credit Card Token Processor - select the correct Credit Card Token Processor

   • Default Detail Message - message that can be used if the payment details field is left empty by the user on the Add Payment page

5. Click Save

6. Process a Credit Card to test if the configuration is in order (see the Processing Credit Cards section below)

Token Card Processor - Adding Payment Methods

The general steps for adding a card token to an account are these:

1. Add a token card processor

2. Add a regular card processor by clicking 'Card Processors' link

   1. Name it 'Token Processor'

   2. Select any gateway - as this is not used during token processing

   3. Click Save

3. Add a card type by clicking 'Card Types'

   1. Click Add

   2. Enter Visa, or MasterCard, etc. as needed. If using a regular processor AND a token processor, you could name them 'Token Visa' or 'Token Mastercard'

   3. Select your 'Token Processor' option as was done in step #2

4. Add a 'Payment Type' and associate it to the token card processor added in step #1

5. Go to an account and add the payment method to the account by doing the following.

   1. Click Tools

   2. Click Payment Method

   3. Click Add

   4. Select the payment type name that is associated to the token processor

   5. Enter the information required and select the card type associated to your token processor

   6. Click Save

ECheck Token Processing

The ECheck Token Processor configuration can be added by going to the Setup / ECheck Token Processors page.

The ECheck Token Processor setup is identical to the Credit Card Token Processor Setup (detailed above).

When Configuring the Payment Type the following Details should be used:

• Name - this is simply an identifier and be any value you wish

• Payment Type - ECheckToken

• E Check Token Processor - The name of the ECheck Token Processor you setup

Processing Credit Cards

For instructions on Processing Credit Cards see the Credit Card Processing Article.

Any processing errors will appear in the Event Log under the Reports tab. Refer to the Troubleshooting section at the bottom of this article for assistance troubleshooting if errors are found in the log.

Test Mode and Other Processor Specific Configurations

For most processors, you will have the option of setting the test mode on the merchant website. This is specific to each merchant. On the merchant account pages, there will be much extended configuration as well beyond what is needed to be setup in EngageIP so remember to read thoroughly the documentation received from your merchant company.

In the few cases where you need to setup test mode from the EngageIP side, there are specific instructions will be available to your on request to LogiSense Support (support@logisense.com)

Information for Test URLS:

gwAuthorizeNet (1)

This gateway requires special configuration due to the extra security measures implemented in the 3.1 (AIM) protocol. You will need to add your Transaction Key ("x_Tran_Key") value with the AddSpecialField method. You must also add the secret hash value with the Config method. Both of these values are provided by the Authorize.Net merchant web interface, which is used to set up your account.

For example; AddSpecialField("x_Tran_Key", "mytranskey"), and Config("AIMHashSecret=myhashvalue"). If no hash secret is supplied in the config method, the hash value returned by the server will NOT be checked. Note that you may add the special field "X_Test_Request" with the value "True" to send test transactions.

You can now set a TEST GatewayUrl, a special field and a Config setting. Please note that all these are required for Payment processing: Accept payments anywhere | Authorize.net AIM 3.1 to work properly

You must have your portal HASH in the Config Field.

Leave the test gateway url blank for the default gateway

This information will look like:

PayFuseTestMode: Used to set various test modes for the PayFuse gateway.

Sample Configurations for Processors

Chase Paymentech / Orbital Configuration

Configure a processor under 'Card Processor' on the setup page according to the example in the image.

Production URL: https://orbital1.chasepaymentech.com/authorize

Testing URL: https://orbitalvar1.chasepaymentech.com/authorize

Configuration

• Merchant Login: 6 number value, called MID that Orbital provides

• Merchant Password: Normally 000001 known as a BIN number (BIN 000001 is for Stratus and BIN 000002 is for Tandem)

• Gateway: Prod or test URL as required above

• Attribute: not required

• Configuration: (replace xxx, below is wrapped using space so remove spaces to use one single line for this) :  OrbitalConnectionUsername=PBxxxx; OrbitalConnectionPassword=Pxxxxxx; TerminalId=002; SSLEnabledProtocols=3072; OrbitalCustomerProfileFromOrderInd=A; AllowPartialAuths=False

AuthorizeNet Configuration

The latest process is directly below

1. Set Merchant Login = API Login ID - the api login id is found in the authorizeNet interface

2. Set Merchant Password =  Transaction Key - this is a 16 digit key generated in the AuthorizeNet interface

3. If you need to disable TLS add SSLEnabledProtocols=3072 to the Configuration field

4. No more config is needed, click save and attempt to process a credit card

5. Review Payment Decline report if there is an error or payment report if it says 'approved'

6. Confirm in the AuthorizeNet portal that the payment was recorded correctly

TestMode:

Live Mode: Simply uncheck the 'Test Mode' checkbox to configure live mode.

AuthorizeNet eCheck Configuration

1. On Setup click ECheck Processors

2. Add a new processor by clicking the Add button

3. Enter the required information

   • Name

   • Select the AuthorizeNet gateway

   • Enter your username and password

   • You may or may NOT need an X Trans key, If you do, it needs to be the same as the password you entered above in the configuration. Merchant password = X Trans Key

4. Go back to the Setup tab

5. Under the Accounting heading click Payment Types. The following are available options for payment type. Step 6 and 7 need to be completed for each added: Savings, Checking, BusinessChecking

6. Click on the 'Check' payment type

7. Select the E Check Processor that you've just added from the dropdown

8. Click the Save button

9. Click on the same payment type and confirm that the status types that you wish to be able to process for are selected under the Allow Payment To Only These Status Types heading

10. Test the ECheck processor as needed.

Sending Email Receipts to Customers

x_email_customer,True  (the first x)email_customer is the option that AuthorizeNet recognizes, and the 'True' item is the value assigned to the option that they recognize. So the format is option,value.

• Follow the steps at the bottom here to enabled AVS so that the information is sent up to the processor

CyberSource

See the CyberSource Payment Processor Setup article.

First Data Global Gateway / Payeezy

To setup a demo account with Payeezy reference this url: https://support.payeezy.com/hc/en-us/articles/203730579-Payeezy-Gateway-Demo-Accounts

1. On Setup and load Card Processors

   1. Enter a Name for the Processor, e.g. First Data / Payeezy

   2. Under Card Gateway select FirstDataGlobalGatewayE4

   3. Under Merchant Login enter your Payeezy provided GatewayID

   4. Under Merchant Password enter your Payeezy provided Gateway password

   5. Under Gateway URL enter the URL supplied by Payeezy

   6. Under Configuration enter the Hash and DMSKeyId value provided by Payeezy (HashSecret=xxxxxxxxxxxx;FDMSKeyId=xxxxxx)

2. Click Save

3. Test processing a payment

IPPay

ACH and CC are supported with IPPay for EngageIP versions 8.2.7.7 and greater.

IPPay Credit Card processing TEST CC processor setup:

1. Load the Setup tab

2. Click Card Processors

3. Click Add

4. Under the Card Gateway field type or select "IPPay"

5. Set the Merchant Login to "TESTTERMINAL"

6. Set the Merchant Password to any value (it's a required field in EngageIP but IPPAY doesn't use / require it, it will not be sent to them, effectively what you enter is a place holder)

7. Set the Gateway URL to "https://test1.jetpay.com/jetpay/"

8. If you need to disable TLS add SSLEnabledProtocols=3072 to the Configuration field
   
   

Once you get a live login for the Merchant account:

• Update the Merchant Login (this should be the Merchant ID, likely 15 numbers long)

• Set password as per above (anything entered will do as a password)

• Enter specified / provided Gateway URL (Currently: https://gtwy.ippay.com/ippay).
  
  

The fields currently sent by EngageIP to IPPAY are as follows:

• TransactionType – auth only, sale, or credit

• TerminalID – Merchant Login

• TransactionID – InvoiceID

• CardNum – Credit Card Number

• CardExpMonth – Expiry Month on card

• CardExpYear – Expiry Year on card

• CardName – Name shown on card

• TotalAmount – the total value with which to charge the card

• CVV2 – CVV number

• BillingAddress – customer billing address

• BillingCity – customer billing city

• BillingStateProv – customer state or province

• BillingPostalCode – customer postal code or ZIPcode

• BillingCountry – customer billing country

• BillingPhone – Customer billing phone number

• OrderNumber – ID from PaymentProcessLog table

• UDField – CustomerID

• UDFIeld2 – UserID

IPPay - ACH

ACH Processing: For testing ACH, use MerchantLogin=TESTMERCHANT" and Gateway URL: "https://test1.jetpay.com/jetpay/"
and select E Check Gateway = IPPay.

SEC Sending:

• CHECKING = PPD

• SAVINGS = PPD

• BUSINESSCK = PPD (if you want this to be sending CCD, setup a role profile question called 'ACH SEC code' per image below, data type of text, and set its value per account that needs it to ccd. This tells the system to send CCD instead of PPD when a business checking account is processed

  
  1. Add eCheck Processor
  2. Enter merchant login as above
  3. Enter password = merchant processor - password is not required or sent to gateway so bogus
  password should be entered
  4. Enter gateway URL as specified by IPPAY
  5. Ensure that you have configured your 'Payment Type' on setup to point the ACH/Echeck option to
  the IPPAY processor
  6. To test, add ACH info to an account, then go to tools and click make payment and save
  7. Review payment or payment decline reports for more info

Once merchant account info is received from IPPay for our customer, then update the  MerchantLogin, Password and Gateway URL, above url is only for sending TEST transactions.

Moneris Configuration

EngageIP Billing uses the Moneris DirecPost configuration which requires specific setup and a new username and password specifically for EngageIP 8 to use. The method is called 'DirecPost' and it requires that you add a 'DirecPost Configuration' within the Moneris management console. Please consult Moneris documentation for further instruction specific to the configuration.

The Direcpost screen in the Moneris interface looks like this:

Once the DirecPost has been setup, Moneris will provide a new unique ID called 'ps_store_id' and the hpp_key value. These are what you need to populate the EngageIP interface with.

Merchant Login = ps_store_id
Merchant Password = hpp_key

EngageIP interface confirmation:

Moneris eSelectPlus

The configuration for eSelectPlus is the same process as for regular processors, except for the addition of the Attribute and Configuration items that need to be entered. These should be found in the gateways interface page.

Moneris Test Configuration

=============================

Owner/Setup/Cardprocessor:-

Card Gateway: Moneris-eSelectPlus

Merchant loging: test

Password: test

Gateway URL:  esqa.moneris.com

Attribute: store3

Configuration: yesguy

*************************

For LIVE Moneris eSelect:-

*************************

Card Gateway: Moneris-eSelectPlus ( Do not run live account testing on development servers )

Merchant loging: xxxxxx

Password: yyyyyyyy

Gateway URL:  www3.moneris.com

Attribute: (Store Name)

Configuration: (API Key from Settings Menu)

PayFlow Pro / PayPal Configuration

Fill in the card processor as per below definitions

MerchantID: Vendor Name

Password: Vendor password which was created and used to login to PayPal Manager interface

TEST Gateway URL: https://pilot-payflowpro.paypal.com

If you want to specify a different partner other than 'PayPal' which is the hardcoded partner, enter the below in the attribute field:

PARTNER,MyPartnerName

To use a different user to authenticate, do the same as above and add the attribute below to tell it to use a particular user:

USER,MySecondaryUser;PARTNER,MyPartnerName

Test URL: https://pilot-payflowpro.paypal.com

YourPay

1. Select the gateway as YourPay

2. Enter the merchant number and password (not your username)

3. Convert your .PEM file as downloaded from the FirstData website to a .PFX file - Instructions here

4. Enter the direct harddrive path to the .pfx files in SSL Cert Store.

5. Enter the number 2 in the cert store type (references the use of .PFX file instead of the unix file type)

6. Enter the SSL Cert Store Password = password

7. Enter asterisk in the subject section (this is as specified by YourPay / LinkPoint)

8. Click Save

9. Attempt to process a credit card

10. Review from the YourPay webbased interface and the payment process reports on the reports page in EngageIP

WorldPay Configuration

1. Add terminal / installation ID into Merchant field

2. Add Merchant password into password field

3. Set configuration field to 'CurrencyCode=EUR' or as needed

4. SSL Cert Store Type must be blank. If the UI gives error with it blank, update cardprocessor table to allow nulls for that field then save that field as blank on the card processor edit link

5. Leave URL blank to use the production URL built into the system

Error listing: https://secure.worldpay.com/global3/payment/default/messages_en.properties

Worldpay Gateway Example: https://www.nsoftware.com/kb/xml/01191001.rst#worldpayxml

SSL Certificate Field Definitions

SSL Accept Server Cert instructs the component to unconditionally accept the server certificate that matches the supplied certificate. If it finds any issues with the certificate presented by the server, the component will normally terminate the connection with an error.

You may override this behavior by supplying a value for SSL Accept Server Cert. If the certificate supplied in SSL Accept Server Cert is the same as the certificate presented by the server, then the server certificate is accepted unconditionally and the connection will continue normally.

Please note that this functionality is provided only for cases where you otherwise know that you are communicating with the right server. If used improperly, this property will create a security breach. Use it at your own risk.

SSL Cert Encoded is the SSL certificate (PEM/base64 encoded). This property is used to assign a specific certificate for SSL client authentication (SSL server authentication in the case of the IPDaemonS component). The SSL Cert Store and SSL Cert Subject properties may also be used to specify a certificate.

When SSL Cert Encoded is set, a search is initiated in the current SSL Cert Store for the private key of the certificate. If the key is found, SSL Cert Subject is updated to reflect the full subject of the selected certificate; otherwise SSL Cert Subject is set to empty string.

SSL Cert Store is the name of the certificate store for the client certificate. The SSL Cert Store Type property specifies the type of the certificate store specified by SSL Cert Store. If the store is password protected, specify the password in SSL Cert Store Password.

SSL Cert Store is used in conjunction with the SSL Cert Subject property in order to specify client certificates. If SSL Cert Store has a value, and SSL Cert Subject or SSL Cert Encoded is set, a search for a certificate is initiated. Please refer to the SSL Cert Subject property for details.

Designations of certificate stores are platform-dependent

The following are designations of the most common User and Machine certificate stores in Windows:

• MY - A certificate store holding personal certificates with their associated private keys.

• CA - Certifying authority certificates.

• ROOT - Root certificates.

• SPC - Software publisher certificates.

In Java, the certificate store normally is a file containing certificates and optional private keys.

When the certificate store type is PFXFile, this property must be set to the name of the file. When the type is PFXBlob, the property must be set to the binary contents of a PFX file (i.e. PKCS12 certificate store). If the provider is OpenSSL, the certificate store is a file containing a certificate and a private key. This property must be set to the name of the file.

SSL Cert Store Password is the password for the certificate store (if any). If the certificate store is of a type that requires a password, the value of this property is used to open the certificate store.

SSL Cert Store Type is the type of certificate store for the client certificate.

This property can take one of the following values:

0 (sstUser - default) - For Windows, this specifies that the certificate store is a certificate store owned by the current user. For Java, this specifies that the certificate store is the name of a JKS (Java Key Store) file. If the provider is OpenSSL, this specifies that the certificate store is a file that contains PEM encoded certificate and private key.

1 (sstMachine) - The certificate store is a machine store (not available in Java and when provider is OpenSSL).

2 (sstPFXFile) - The certificate store is the name of a PFX (PKCS12) file containing certificates. If the provider is OpenSSL, the file may contain only one certificate and private key.

3 (sstPFXBlob) - The certificate store is a string (binary or base64 encoded) representing a certificate store in PFX (PKCS12) format. This setting is currently not supported when the provider is OpenSSL.

4 (sstPEMKey) - The certificate store is a string or filename that contains a PEM encoded certificate and private key. This store type is currently not supported in Java.

SSL Cert Subject Property (ICharge Component), when this property is set, a search is performed in the current certificate store certificate with matching subject. If an exact match is not found, the store is searched for subjects containing the value of the property. If a match is not found, the property is set to an empty string, and no certificate is selected. The special value "*" picks a random certificate in the certificate store. If a matching certificate is found, the SSL Cert Subject property is set to the full subject of the matching certificate.

Convert .PEM to .PFX Certificate

You will have a file in a PEM format and want to convert that to a PFX. Below is a command you can use on a unix system (OpenSSL) to do this.

>cat x.cert x.key > x.pem
>openssl pkcs12 -export -in x.pem -out x.pfx

Save this file to the EngageIPBillservice directory according to the steps for YourPay and copy the directory location for use in the YourPay configuration

All of the supported gateways have certain properties that must be set in order to successfully complete a transaction. Generally, the following properties must be set for every gateway:

• CardNumber

• CardExpMonth

• CardExpYear

• CustomerAddress

• CustomerCity

• CustomerState

• CustomerZip

• CustomerFirstName

• CustomerLastName

• MerchantLogin

• MerchantPassword (where required)

• TransactionAmount

Please note that some gateways may also support non-AVS transactions, where customer name and address data is not required. However, these transactions are risky and are not recommended for fraud reasons. When a transaction is authorized, the status of the response will be indicated by the TransactionApproved property. For more details as to why a transaction was authorized or declined, it is recommended that the developer check the ResponseCode and ResponseText properties. Please see the ResponseCode property for a list of specific response codes for each gateway.

Please see the TransactionType property for a list of transaction types supported by each gateway.

In addition to the properties listed above, some gateways require that a few more properties be set. These gateways and properties are listed below. Please note that there are several Authorize.Net compatible gateways which are not listed below. Please see the GatewayURL property for more information.

The default "Partner" special field is set to "VeriSign". You may be required to change it depending on your account setup. If your User ID and Vendor ID (Merchant Login ID) are different, supply the Vendor ID to MerchantLogin and add the User ID like so: AddSpecialField("USER","User ID Value").

gwPayFuse (27)

The Config setting "MerchantAlias" is required. The TransactionAmount must be submitted as the number of cents without a decimal point. For example, a dollar value of "1.00" would equate to "100" for this gateway. The TransactionId property
must be explicitly set before the initial authorization, and that value must be used to modify that transaction rather than the value returned in the ResponseTransactionId property. The "PayFuseTestMode" Config setting can be used for testing.

gwPaymentsGateway (45)

This gateway requires the same setup as the ACHPayments gateway.

gwPayReady (11)

This gateway is no longer in service.

gwPayStream (49)

For this gateway, you will receive a "MerchantID", "CustomerID", "ZoneID", and "Username" from PayStream. The "MerchantID" field corresponds to the MerchantLogin property. The remaining fields must be added to the request using the AddSpecialField method. Also, the InvoiceNumber is a required property for this gateway, and must be unique for each transaction.

gwPlanetPayment (15)

This gateway requires the same setup as the Authorize.Net gateway.

gwPlugNPay (14)

(none)

gwPRIGate (37)

The MerchantLogin should be set to your MerchantID. The MerchantPassword should be set to the RegKey provided by PRIGate.

gwProtx (38)

InvoiceNumber. The fields "RelatedSecurityKey", "RelatedVendorTXCode", and "RelatedTXAuthNo" must be added with AddSpecialField before calling Capture or Credit. After a successful Authorize, the value to put in the "RelatedSecurityKey" field should be parsed from the SecurityKey value found in the ResponseData, and the values for RelatedVendorTXCode and RelatedTXAuthNo should be retrieved from the InvoiceNumber and ResponseApprovalCode properties respectively.

gwPSIGate (26)

(none)

gwPSIGateXML (52)

(none)

gwRTWare (17)

This gateway requires the same setup as the Authorize.Net gateway.

gwSkipjack (22)

CustomerEmail, CustomerPhone

gwTransFirst (50)

InvoiceNumber

gwTrustCommerce (25)

The TransactionAmount must be submitted as the number of cents without a decimal point.

For example, a dollar value of "1.00" would equate to "100" for this gateway.

gwUSAePay (13)

(none)

gwUSight (32)

(none)

gwViaKlix (12)

InvoiceNumber If given an ssl_user_id by ViaKlix/Nova, set it with the AddSpecialField method. Please note that ssl_merchant_id maps to the MerchantLogin property and ssl_merchant_pin maps to the MerchantPassword property. Test transactions can be sent by setting the test mode with AddSpecialField("ssl_test_mode", "true").

gwWorldPay (54)

InvoiceNumber and CustomerCountry are required properties. You may also wish to change the "currency" special field to the currency you support. It is defaulted to "USD". (See the SpecialFieldNames and SpecialFieldValues properties for more information). If the "testmode" Special Field is added with the value "100", all transactions will be accepted. If set to "101" all transactions will be declined. If no "testmode" is set, the transactions are live.

gwYourPay (43)

This gateway requires the same setup as the LinkPoint gateway.

More Info IBiz E-Payment Integrator V3 .NET Edition. -For more info, please visit our website at http://www.nsoftware.com.

Configuring Your System to Email Receipts to Customers

1. The email box on the bottom of the credit card add / edit screen needs to be completed as well as address as this will be what is sent to your cc processor

2. On the Setup page configure your Card Types

   • Check Enable AVS - this prompts EngageIP to actually send the data to the processor

   • Click Save

3. Enable / configure the option on the processors gateway website or merchant configuration page

4. Test by charging a credit card for a small amount to confirm the email is being sent and if not, that the data, email and address is being sent up to the processor. You can see this detail on the transactions detail on your processors website

Credit Card Expiry Email

Expiry emails can be configured on the Email Settings screen on the setup tab. It consists of selecting an email template (from the Email Message link on the setup) which you want to send customers when their credit card is close to expiring. 1 month prior to the expiry of a credit card, the system will email out the template you have configured on ‘Email Settings’ to the email address stamped on the billing contact of the associated account. This email will only be sent out once and is sent out via the Event Manager service as it checks its daily jobs.

Full detail and images are in this article: Credit Card Processing - Processing, Refunds, Testing and Expiry Emails | Automatic Expiry Email Notification

Troubleshooting

The below provides some common errors when attempting to process cards.  You can find errors in several places:

1. The Payment Decline report: will list basic errors

2. The Event Log: will show Credit Card return messages and errors

3. The paymentprocesslog: will show a full unparsed list of the returned value from the gateway

iBiz Registration Message

when processing a card, you may receive a message initially about needing to register iBiz software. If it is not already registered, this needs to be done by LogiSense Customer Support on your billing server. If you see the issue occur after that on desktops of CSRs, the ASP.Net user on the Webserver may need extra permissions so that IIS can read the registry and know that the iBiz software is already registered.

iBiz will also need to be installed on all services where the billing service is installed and running, i.e. in a clustered SQL environment, iBiz will need to be installed and registered on the applicable SQL servers.

Registry keys are located here:

[HKEY_LOCAL_MACHINE/SOFTWARE/nsoftware/RTBPN3A]
[HKEY_LOCAL_MACHINE/SOFTWARE/WOW6432/NODE/nsoftware/RTBPN3A]

Communication Errors

Communication errors: Ensure that your firewall is not preventing communication to the processors website, especially to HTTPS (port 443) communication between the webserver and card processor servers.

Credit Card / SSL Response Errors

Credit Card return messages and errors will show in the EngageIP event log and are common among all processors compatible with the iBiz processor module. Some of the most common errors - Credit Card Response Errors:

SSL Response Errors:

For further information, refer to the iBiz documentation on troubleshooting and errors or you can request assistance by emailing support@logisense.com.

See Also

• Vantiv Payment Processor Configuration (non-iBiz integration)