Payment Gateway Terms & Concepts

This Help File Page was last Modified on 11/29/2019

<< Click to Display Table of Contents >>

Navigation:  Accounts Receivable System - The Receivables Module > Receivables - General Maintenance Entries > Payment Gateways >

Payment Gateway Terms & Concepts

This Help File Page was last Modified on 11/29/2019

This is a Glossary of Terms and Concepts which will assist you better understanding how to use Payment Gateways.

This Table contains two columns of data relating to Payment Gateways:

1.Term or Concept - This column lists the specific terms and concepts you'll encounter while implementing Payment Gateways.

2.Description or Explanation - This column lists the explanations of those Terms or Concepts

 

 

Term or Concept

Description or Explanation

Payment Method

A Payment Method is a Customer's Credit Card or Bank Account information - provided by the Subscriber - to be used for processing automated payments and manual E-Payments of their Invoices.

MKMS supports the creation of multiple Payment Methods per Subscriber Account,

Multiple Credit Cards and Multiple Bank Accounts may be registered for one Subscriber.  

When Tokenization (see below) is used, the Subscriber's Credit Card number is replaced with a Token, and the Credit Card number cannot be accessed and viewed again

.

Understanding the Credit Card's “Token Status” column on the Payment Methods dialog:

a)Initially, the status is identified as “Token is pending to be created” when the Credit Card has not been Tokenization

b)The status changes to “Token has been created” when the Tokenization process runs and the Credit Card is Tokenized.  

c)If an error occurs during the Tokenization process, status is set to “Token could not be created”.

Payment Processor

The Payment Processor is the entity responsible for processing your Company's payment transactions and depositing those funds into the designated Bank Account.  It cound by your Company's Bank, or a third-party Payment Gateway.

Payment Processor Types

A.Automatic Payment Processor (Online) - An Automatic Payment Processor is one that process your payment transaction on the fly, it uses your internet connection to send the payment information straight to the Payment Processor system, and gets back the payment approval response in seconds.

Micro Key's MKMS Software provides automatic integration for processing payment transactions online for three (3) different Payment Processors

oAuthorize.Net

oForte.net

oInnovative ePay (InnoEPay)

 

When a payment is processed by an automatic processor, as the transactions are approve,

a)a Receipt record is generated in MKMS, and if it is setup to do so,

b)an Email is sent to the Subscriber's email address, then

c)the Payment Processor will deposit these funds into your Company's designated Bank Account.

 

B.Manual Payment Processor (File Based) - Manual payment processing refers to a Payment Processor entity that does not process transactions on the fly,

Important Note: When Tokenization is turned, you should not use any Manual Payment Gateway (File Based) for Credit Card Processing!

This type of Payment Processor usually requires that the payment information be sent in a text file to the processor via email or via their web portal (via an uploaded file), then

The Payment Processor returns another file with the payment transactions approval responses

The most common Manual Payment Processor is a Bank which will process your payments and deposit your funds in your Company's Bank Account there.

Payment Processor Account ("Gateway")

You can have your Automatic Payment Processor entity which may be set up for one, or many, accounts (Payment Gateway Accounts) based on your Company's payment processing needs.

Each Gateway Account will have its own Key/PIN or User/Password combination.

Each Gateway Account is associated with a Bank Account where the payment funds will be deposited .

That Bank Account is specified when the Payment Gateway Account is created by the payment processor.

Then you will configure your Gateway Account in MKMS System where you will set up that relationship between your Gateway Account and your Bank Account.

 

Only one Payment Gateway service should ever have Tokenization turned on at the same time!

Company Settings of interest:

1)The Company Setting option that turns each Automatic Payment Gateway is

i.InnoEPay option is ePayAPE and is turned on when set to True ("T")

ii.Authorize.net option is AnetAPI and is turned on when set to True ("T")

iii.Forte.net option is ForteAPI and is turned on when set to True ("T")

 

2)The Company Setting option that turns each Automatic Payment Gateway's associated Tokenization is:

i.InnoEPay option is ePayTokenWorkerEnabled and is turned on when set to True ("T")

ii.Authorize.net option is AnetTokenWorkerEnabled and is turned on when set to True ("T")

iii.Forte.net option is ForteTokenWorkerEnabled and is turned on when set to True ("T")

 

Note: In this chapter we refer to a Payment Processor Account and its relation to a Bank Account as your “Gateway”.

Bank as Account Holder

vs

Bank as Payment Processor

 

In the MKMS System the Bank Accounts your Company's uses are referred as Banks,

It is important not to confuse the concept of a "Bank" as a Payment Processor (Gateway) with the concept of a Bank Account (account where money is deposited).

 

A "Bank" could be the entity that process your Payment (Payment Processor) as well as your account holder (Bank Account)

If you use a "Bank" as a Payment Processor then that Bank will have your funds deposited in the Bank Account that is in your Company's name.

When using a third-party Payment Processor - which by definition is not your Company's Bank - they will process your payments and deposit those funds into any Bank Account that you specify, while your Company's actual Banks usually deposit your funds only in the Bank Account that you have with them.

Tokenization

 

Before creating or activating your Gateway (Payment Processor) Account you should understand the Tokenization Process

For security reason it is not recommended that your system stores your Subscriber's actual Credit Card numbers,

oSo one solution to minimize this risk is to allow the Payment Processor to hold this information for you.

For each Credit Card Number that you save in MKMS, a Token (a code representing that Credit Card number) will be returned to MKMS by the Payment Processor's System

oThis Token will be saved in MKMS instead of the Credit Card Number, and you will only see the last digits of the Card's Number after a Token is received.

The process of Tokenizing Credit Card Numbers is executed 100% in the background, so you do not need to take any actions for it to work.

o In just a few seconds after a Credit Card is saved in your system, a background service will replace the Card's Number with a Token.  

oEverything will continue to work as before.

oYou will simply be using a token instead of a Card Number for payment processing.

 

Tokenization:

Tokenization is one of the steps that help make your system meet PCI Compliance

It reduces the risk of anyone - including hackers - getting a Subscriber's Credit Card information

Replaces the Subscriber's Payment Method of Credit Card information with a unique code (Token) and deletes from your system all credit card number information

If you switch from one Payment Processor to another, the existing Tokens will not work and all Credit Card information will need to be collected from your Subscribers again, which should be done before switching

Tokenization can be turned ON/OFF but it will not revert already existing Tokens back to Credit Card Numbers, (To turn ON/OFF just un-check the Tokenization check box on the associated Payment Gateway Form)

Only the Payment Processor that generated the Token can use that token to process Credit Card Transactions

Only One Gateway at a time can be set up to manage your Subscriber's Credit Card Tokens

Tokens may only be used when your Company uses one and only one Automatic Gateway for all your Credit Card transactions

If Tokens are used, you cannot use any Manual Payment Gateway (File Based) for Credit Card Processing

 

Important Note: When Tokenization is turned, you should not use any Manual Payment Gateway (File Based) for Credit Card Processing!

Only one Payment Gateway service should ever have Tokenization turned on at the same time!

Company Settings of interest:

1)The Company Setting option that turns each Automatic Payment Gateway is

a.InnoEPay option is ePayAPE and is turned on when set to True ("T")

b.Authorize.net option is AnetAPI and is turned on when set to True ("T")

c.Forte.net option is ForteAPI and is turned on when set to True ("T")

 

2)The Company Setting option that turns each Automatic Payment Gateway's associated Tokenization is:

a.InnoEPay option is ePayTokenWorkerEnabled and is turned on when set to True ("T")

b.Authorize.net option is AnetTokenWorkerEnabled and is turned on when set to True ("T")

c.Forte.net option is ForteTokenWorkerEnabled and is turned on when set to True ("T")

 

MKS EPay Service

The MKS EPay Service is a Windows® Service that runs in the background on the MKMS Database Server (or your PC if not using a Network) and takes care of the processing of any generated Payment Batch files, the following are some of the tasks which may be performed by this EPay service:

 

Process Single Payment Transactions:

a)When a Credit Card Payment Transaction is created by a Customer Payment, the service sends the payment information to the Automatic Gateway for it to be process

b)Once Transactions have been processed, it receives the responses from the Payment Processor and does one of two things

If the response is an approval it tags the payment transaction as approved and closes it

If the response is a declaimed it tags the payment transaction as declaimed and closes it

If the response is not an approval or a denial if a check waiting for approval, then it set the transaction to “Summited”

c)Generate Receipts for all payment transaction that where approve by the Payment Processor

d)Allocates the Receipts to the corresponding invoices

 

Process Payment Batch Transactions

When the Auto Billing or Auto Draft processes are run, they generate a Payment Batch will all the customers payment transactions that need to be process

1)The service then starts sending each transaction information to the Automatic Payment Processor

2)Once a Transactions have been processed, it receives the responses from the Payment Processor and does one of two things

3)If the response is an approval it tags the payment transaction as approved and closes it

4)If the response is declined it tags the payment transaction as declined and closes it

5)If the response is not an approval or a denial (a check waiting for approval) then it identifies the transaction to “Submitted”

6)The service may:

i.Generate Receipts for all payment transaction that were approved or submitted by the Payment Processor.

ii.In the case of Receipts for Submitted checks then the deposited date of the receipt will not be set

iii.Allocates the Receipts to the corresponding Invoices

 

Processes Submitted Pending Payments

When a Payment is made from a Bank Account (Bank Draft) it gets a Status of Submitted, then the service keeps looking for the Submitted Transaction pending for approval response and sends them back to the Payment Processor to get and updated status of the transaction.

The service will repeat this process until the transaction is approved or denied by the payment processor

Once Transactions are processed, and it receives the responses from the Payment Processor, if the response is an approval

The service will set the deposited day of the previously generated Receipts

 

Tokenization of Credit Cards

oThe service keeps looking for new customer Payments Method of type Credit Card to replace the Card Number with a Payment Processor’s specific Token

oThis process eliminates credit card numbers from your systems

 

Manual Payment Processors Services

If a Payment Batch is Generated for a Gateway that is not one of the Automatic Payment Processors and the Gateway's  “Generate Receipts” Check box is Checked

1)Closes all payment transactions of the Payment Batch and tags them as approved

2)Creates the Receipts for all transactions

3)Allocates the Receipt to the corresponding Invoices

 

When the EPay Service is not running:

a)Individual payment transaction(s) will not be processed on the fly

b)Payment Batch will not be automatically process by Payment Processor

c)Token will not be generated for the Subscribers' Credit Cards

d)Submitted check status will never get updated to approved or denied

e)Payment and receipts will not be generated or allocated

 

 


EPay Service Configuration

These are general system level settings that affect MKS EPay Service for all companies

Parameter

Use

ePayTranTimerMs

 

Set the frequency in milliseconds use by the EPay Service to look for a new single transaction to be processed by Automatic Payment Processors

ePayBatchTimerMs

 

Set the frequency in milliseconds use by the EPay Service to look for new Payment Batch generated by Auto Billing or Auto Draft, to be processed by the Automatic Payment Processors

ePayStatusTimerMs

 

Set the frequency in milliseconds use by the EPay Service to look for Submitted Check / Bank Account Payments transaction to be processed by the Automatic Payment Processors to update their approval status

ePayTokenTimerMs

 

Set the frequency in milliseconds use by the EPay Service to look for new Credit Cards in the system that need to be Tokenize by the Automatic Payment Processors

 

At the Server Level we can set On/Off status of the Automatic Payment Processor for each individual company, this will optimize the performance of your system by avoiding to run unneeded processes

 

Parameter

Use

ANetAPI

Turn On/Off the Authorize.net Automatic Payment Service for a specific company

ForteAPI

Turn On/Off the Forte Automatic Payment Service for a specific company

ePayAPI

Turn On/Off the InnoEPay Automatic Payment Service for a specific company

 

At the Company Level, these are the Settings that we can user to turn On/Off individual processes of the MKS EPay Servicevice for Each of the supported Automatic Payment Processors

 

Parameter

For EnnoEPay Automatic Payment Processor Gateways

ePayTranWorkerEnabled

Enable Single payment processing

ePayBatchWorkerEnabled

Enable Batch payments processing

ePayTokenWorkerEnabled

Enable Tokenization process

ePayStatusWorkerEnabled

Enable Submitted E-Check status updates

 

For Forte Automatic Payment Processor Gateways

ForteTranWorkerEnabled

Enable Single payment processing

ForteBatchWorkerEnabled

Enable Batch payments processing

ForteTokenWorkerEnabled

Enable Tokenization process

ForteStatusWorkerEnabled

Enable Submitted E-Check status updates

 

For Authorize.Net Automatic Payment Processor Gateways

ANetTranWorkerEnabled

Enable Single payment processing

ANetBatchWorkerEnabled

Enable Batch payments processing

ANetTokenWorkerEnabled

Enable Tokenization process

ANetStatusWorkerEnabled

Enable Submitted E-Check status updates

 

 


Payment Gateway Configuration

Every Payment Processor Account (see the Payment Gateway chapter for complete information) needs to be configured within MKMS and connected to the corresponding Bank Account record.

Your Bank Account(s) must to be created and configured within MKMS before you can relate your Payment Gateways to them.

MKMS comes with most Payment Processors already defined.

Before you create your new Gateway you should check to see if one already exists for that Payment Processor.

If it does exist then all you need to do is a minimal configuration for the Authentication Information.

 


1. Automatic Billings Setup

(Set it and Forget it)

A Fully Automated Recurring Billings Process:

a)Runs MKS ePayService as a Windows® Service and Generates Recurring Revenue Invoices each morning at 4:00am [this requires that the Automatic Billing Setup Wizard be run to set the “AutoBillingOnoption in Company Setting to True (‘T’)]

b)Selects only those Accounts (Subscribers) who have Recurring Revenue billing records with a Billing Cycle Billing Day matching the day number of the current Date ("Today" at 4:00am). 

c)Recurring Revenue Invoices may be created in advance of the Invoice's Sale Date [this requires the “DayPriorToCylceStartoption in Company Setting be set to the appropriate Value (= the Number of Days to be billed In Advance)] - This requires that the Automatic Billing Setup Wizard be run to set the “DayPriorToCylceStartoption in Company Setting to the appropriate Number of Days.

d)Even when you run your Automatic Billings Process a few day before the Billing Day, the Payment Transactions from those Subscribers will not be processed until the Due Date (e.g., Billing Day + Subscriber Terms) of the billing.

e)Generation of Recurring Revenue Invoices respects the Separate RMR Invoice option to specifically generate a separate Invoice for designated Service Accounts

f)Includes any previously Suspended Invoicing charges on the Recurring Revenue Invoices

g)Generates Late Fees during the process [this feature requires the “GenerateLateFeesoption in Company Setting be set to True (‘T’)]

h)Supports the grouping of Detail Line Items on the Recurring Revenue Invoices (this feature requires the definition of Invoicing Groups and the assignment of an Invoice Group to the appropriate Recurring Revenue records)

i)Generates and submits the Auto Drafted payments to the Payment Gateway (InnoEPay is the recommended Payment Gateway) but also supports the Authorize.net and Forte.net Payment Gateways which requires that 1) that a Company's Payment Gateway account has been setup, 2) the “ePayAPI" option in Company Setting is set to True (‘T’), and 3) the MKSePayService is running].

j)Generates Receipt records for each of the Approved Batch Payment Transactions when acknowledged by InnoEPay (or your Company's selected Automatic Payment Gateway).

k)Allocates those Receipts to the appropriate Recurring Revenue Invoices

l)In addition to InnoEPay, other Automatic Payment Gateways: (Authorize.net and Forte.net) are also supported.

m)Generates e-mail notifications for Invoices to customers (The emailing of the Invoice notification - using the MKS Connect Service - during the Fully Automated Recurring Billing process is activated in Company Setting  by setting the "email_invoice_notification"  to True ("T") and the Subscriber must have a valid Email address.  Requires that all SMTP settings be properly entered.).

n)Generates e-mail notification for Receipts (The emailing of the Receipt notification - using the MKS Connect Service - during the Fully Automated Recurring Billing process is activated in Company Setting by setting the "email_receipt_notification"  to True ("T")  and the Subscriber must have a valid Email address.  Requires that all SMTP settings be properly entered.).

 

2. Manual Billing

(Auto Billing Form)

If the Fully Automated Recurring Billings Process is not used, MKMS still provides manual Auto Billing Process for Generating the Recurring Billing for Selected Billing Cycles (One Cycle at a time).

This process will also generate the Payment Batch file if the Billing Cycle is identified as an Auto Draft type (that box is Checked), and you are using an automatic Payment Processor

When a Billing Cycle is identified as an Auto Draft type (that box is Checked), the manual Auto Billing Process will also generate the Payment Batch file for those Invoices generated for those specific Billing Cycles, which is useful when your Company is using a Manual Payment Processor that requires it.

Understanding the Auto Draft option

on the Billing Cycles Form

HelpFilesRecurringBillingPayBatchChart

ePay Company Settings

In the Company Settings dialog there are hundreds of Setting Names and Setting Values provided to establish how MKMS will be operated by your Company.

Among these are the ePay specific options:

 

HelpFilesUserOptionsCompany-CompanySettings-ePayOptions

In most cases, these ePay options are installed by the system as needed.

Setting Value options may be modified as documented, when required.

Payment Gateways

Payment Gateways have multiple field that need the correct information to properly process Payment Transactions for your Company

 

Field

Description

Default  

Gateway ID

Read-only field for internal use

 

Gateway

Description of the Payment Processor Account, we recommend adding additional info like the bank account last digits to identify where the funds will be deposited when this Gateway is used

 

Get/Set Login/Key

Click this button to enter/edit Gateway Login/Key information provided by the payment processor when the Gateway Account is created

 

Get/Set Password/PIN

Click this button to enter/edit Gateway Password/PIN information provided by the payment processor when the Gateway Account is created

 

Payment Processor

Select one of the Automatic Payment Processor supported by the MKMS system or the Manual Gateway for a non-automatic processor like some banks that require file transfer.

Manual Gateway

Bank Account for Deposit

This is the Bank Account where the Payment Processor will deposit your funds, remember that the bank account needs to be created before the Gateway is created or configured

 

File Format

For Manual Gateways it tells the software the file format when creating a text file to be sent with the payment information to be processed, file formats for most used banks are provided in this list. Select from list of available formats.

 

Active

If Active is checked, the Gateway will be shown in the Auto-Bill and Auto-Draft screens, remove the Check mark in the Active field for any Gateway that you do not use and do not want to see in the system

Checked

Default

This identifies the Gateway that would be used as default in Billing Cycles. Only one Gateway can be marked as Default. If in the Billing Cycle screen the “Use default Gateway” is checked then the Gateway mark as Default will be assign to that cycle

Unchecked

Generate Receipts

Indicates that Receipts will be created for all payments at the moment that the Payment Process run, and the Payment Batch is created, applies only to Manual Gateways.

Automatic Gateway will always generate receipts when a payment transaction gets approved

Checked

Use for Tokenization

If checked, this Gateway will be used for the generation of Tokens, the tokens generated by one Gateway cannot be used to process payments with a different Gateway, be very careful before changing this setting.

Do not check this option if you send a file to your payment processor. If "Use for Tokenization" is checked, the credit card number will be x-out.

Unchecked

Gateway Configuration Parameters

Configuration Parameters varies for each Payment Processor, when you get a Gateway Account depending on the Payment Processor used you may need to update the parameter values for the account

 

 

See the InnoEPay, Authorize.net, and Forte.net chapters for that information.