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 never 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")

iv.EFT Canada

➢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 that 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 the actual 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

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

▪This 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

▪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

▪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

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 “AutoBillingOn” option 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 “DayPriorToCylceStart”option 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 “DayPriorToCylceStart”option 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 “GenerateLateFees” option 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

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:

▪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

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