Payment Terminal Application Features

In this article we are going to provide a brief description of the common features of a payment terminal application. The features under consideration concern such aspects as payment processing, loyalty programs, management of agreements, and other, more advanced matters.

Let us describe each of these aspects, and respective payment terminal application features, one by one.

Payment Processing-related Features

  • ACH transaction handling – ability to handle bank account payments or capture bank account data for recurring payments. More detailed information on how ACH works can be found in our respective article.
  • Swipe/Manual – ability to handle magnetic stripe cards, as well as manual card entry for processing and recurring payments.
  • PIN Debit – ability to handle encrypted PINs when PIN-debit or EMV transactions are processed.
  • Contact EMV – ability to handle ICC (integrated circuit card) EMV payments. For contact EMV transactions an ICC (chip) is inserted into the terminal.
  • Contactless EMV – ability to handle contactless EMV payments. During contactless EMV payments it is enough to touch the terminal with a card (without inserting it). Check out our respective article on the benefits of EMV standard for more information.
  • Proximity – ability to handle RFID (radio frequency identification) cards and mobile payment systems like ApplePay or Google Wallet. For RFID card handling it is enough to put the card close to the terminal without inserting it.
  • Gift Cards – ability to handle closed loop gift cards, including activation, reloading and redemption. Closed loop cards are accepted only by the company, which issued them to its customers.
  • Offline Transactions – ability to handle transactions when no connection to the host is available (generally due to connectivity issues); exists in two flavors – store and forward (for non-EMV cards) and EMV offline handling.

Features Concerning Loyalty Programs

  • Cards – ability to handle non-payment magnetic cards for loyalty programs. Examples include cards for accumulation of points, bonuses, etc which can be later exchanged for some benefits
  • Phones/Tags – ability to use NFC (near field communication) enabled devices or NFC tags for non-payment operations (check-in, loyalty program, etc).

Features Concerning Agreements Management

These features are common for large-screened terminals, which have an ability to support different non-payment functions, particularly concerning customer agreements. Usually, these features concern interaction with a customer through dialogues and forms displayed on the terminal screen.

  • Custom Dialogs – ability to show custom prompt dialogs and capture customer’s selection.
  • Signature Capture – ability to capture signatures and initials.
  • Custom Forms – ability to present customized input forms to collect arbitrary data.

Features of a Stand Alone Offering

  • Regular Payments – ability to handle payments using terminal without POS (stand alone terminals).
  • Split Payments – ability to handle partial authorization. Partial authorization takes place, for instance, when a customer wants to pay with one of his cards, but gets an “insufficient funds” response, and makes the actual payment with another card.
  • Batch Management – ability to handle voids and settlements using terminal without POS. In terminal management context a batch means a series of transactions accumulated during the day.
  • Tip Management – ability to handle tip adjustments on pre-authorized transactions using terminal without POS.

Advanced Payment Terminal Application Features

  • Tokenization – in addition to standard payment processing functionality, tokenization allows capturing of payment information for its subsequent reuse as part of the recurring billing process. It is often necessary to avoid manual entry of payment information for tokenization purposes. For more information on tokenization, see our respective article
  • P2PE – ability to encrypt PAN data from the point of capture (terminal) all the way to the point of processing (either at the gateway or processor level). While P2PE without formal PCI certification does not provide out-of-scope status for merchants using it, it significantly reduces possible exposure of cardholder’s data. Usage of P2PE methodology imposes additional key injection procedures. For more information on P2PE, see our respective article
  • Advertising – ability to show customized media content (image slideshows or video) on terminal’s screen in idle mode (when terminal is not used for a specific operation). Targeted deliver of marketing content provides additional value to the terminal offering and helps justify costs associated with hardware acquisition.
  • TMS – ability to connect and communicate with terminal management system for remote configuration and updates. While the feature is not required for solutions with local footprint where DLLs are distributed as part of the main application (desktop thick clients), it is necessary for embedded system.
  • Donations – ability to accept donations or surcharges as ‘add-ons’ to primary application payments.


When you make a decision concerning implementation of some terminal solution, make sure that you think through the payment terminal application features that you are going to need, and that they are available in the solution of your choice.

What is an ACH payment gateway?

What is an ACH payment gateway?

An ACH payment gateway is a kind of payment gateway that allows to process ACH transactions. Usually it connects to various banks or ACH processing networks to provide access to all of its financial institutions for its merchants.

What is the difference between ACH and credit card transaction processing?

ACH transactions do not involve payment cards – just bank accounts, so credit card transaction processing is usually performed by credit card processors/acquirers, while ACH transaction processing is, mostly, handled by banks. However, in today’s merchant services industry there are payment gateways, allowing merchants to process both credit card and ACH transactions through one and the same API.

What is a lifetime of an ACH transaction?

ACH transaction file is submitted to the bank, which, usually, forwards it to Federal Reserve, which funds a 1005 of transactions in the file. Subsequently the Federal Reserve will dispatch a request to respective banks to complete money transfers.

What is an ACH return and how should it be handled?

An ACH return is a rejection of an ACH transaction due to insufficient funds on the account or for some other reasons (complete list of ACH return codes can be found here). If at the stage, when Federal Reserve requests money from the bank, it turns out that the transaction cannot be processed, since Federal Reserve has already funded the respective merchant, it takes the money back from the bank, while the bank takes it back from the merchant. Verification of availability of funds on the account can take up to two months, during which ACH fraud can occur. Consequently, the best way to deal with ACH returns is to avoid them, i.e. check whether all the information necessary for ACH payment processing is up-to-date, whether account is not included into some blacklist, whether the account (or IP) does not come from some high-risk location, etc.

What is the role of ACH reserves in ACH payment processing?

ACH reserves represent one of the ACH fraud protection mechanisms. ACH reserve is a certain amount withheld by a PSP\underwriter from deposit of a merchant (fixed amount or percentage of ACH transactions, processed by its sub-merchants) to protect its business from potential ACH-returns. More information can be found here.

ACH and Credit Card Transaction Descriptors

The purpose of this article is to familiarize merchants and payment service providers with the concept of ACH and credit card transaction descriptors.

Descriptor definition

A descriptor is a description of a product or service purchased by a customer from a certain merchant that appears on the customer’s statement, explaining a charge (or refund) of the merchant.

Descriptors are fixed in length. For instance, standard credit card transaction descriptor length is 22 characters at most. These, generally, include the DBA name of a merchant and the name of the product/service, separated by asterisk (*) symbol. Some processors also allow to specify telephone number or web-site of a merchant in descriptors; some banks do not display all this information on cardholders’ statements, but most do.

What are descriptors intended for?

A descriptor is designed to remind a customer what the transaction was, and what the money was charged for (in order to avoid groundless chargebacks). Consequently, it is critical for ACH and credit card transaction descriptors to be as informative as possible, especially on recurring billing transactions.

Credit card transaction descriptor configurations

Depending on the processor and the platform, credit card transaction descriptors can be either dynamic or static.

Static descriptors

A static descriptor is associated with the merchant ID. This means that one merchant ID corresponds to one descriptor. All transactions associated with a given merchant ID bear the same descriptor (e.g. look the same on the statement).

Dynamic descriptors

A dynamic descriptor is specified at the transaction level, i.e. different transactions with different descriptors can go through one merchant ID. Even though the same merchant ID is used for all transactions, each transaction can have its own descriptor (verbage).

Dynamic descriptors are the more preferable and flexible option.

Depending on capabilities of a given platform, the information about descriptors can be submitted at different times:

  • Authorization-only – some platforms accept descriptor information at the moment of transaction authorization.
  • Settlement-only – some platforms accept descriptor information at the moment of transaction settlement.
  • Authorization and settlement – some platforms accept descriptor information during both transaction authorization and transaction settlement.

Ability to submit descriptor information during both authorization and settlement is nice, but authorization-only option is sufficient. Settlement-only option is less ideal, so some banks do display transaction description online as soon as the transaction is authorized.

ACH transaction descriptors

Many banks within the US utilize NACHA file format for ACH processing. NACHA format allows to use descriptors in a way similar to the one used for dynamic descriptors. When a file is sent, ACH transactions are grouped into batches, and every batch can have its own unique descriptor, comprised of the merchant name and item description. Although, dynamic descriptor effect can be emulated to some extent, the approach doesn’t really allow to have a unique descriptor of every single transaction processed.

Examples of ACH transaction groups to be marked with unique descriptors are: utility payments, recurring dues, club membership dues, etc.

Descriptors for aggregators and payment service providers

Dynamic ACH and credit card transaction descriptors are particularly important for businesses, that use aggregation model. The reason is that dynamic descriptors allow aggregators and payment service providers to specify which of their merchants originated a given transaction (or batch). In such cases the following descriptor format is used:
[Aggregator name (up to 6 digits)]*[sub-merchant company name]

Here are some common descriptor formats and examples.


[aggregator name]*[sub-merchant company name]
PSP*convenient store NY
ISO*John’s dehli
[Company]*[product name]
Best clothes*jeans black


It is preferable for businesses (especially, for those using subscription-based or aggregation revenue models) to cooperate with credit card processors and payment gateways supporting dynamic descriptors.

Payment Gateways II: Batch Transaction Processing

The purpose of this post is to familiarize merchants and resellers with the concept of batch transaction processing as an advanced feature to be considered during online payment gateway/credit card processor selection.

If this is the first time you are reading “Payment Gateways II” series, please start with the Introduction, as it will improve your understanding of the current post.

Real-time and batch transaction processing

The two ways in which a credit card transaction can be processed provide the basis for two processing approaches. Processing either happens in real time (transactions are authorized one-at-a-time), or it happens in batch (batch file with many transactions is sent and then processed as a whole). While real-time processing is more common in retail, batch processing is more suitable for recurring billing and bill payment (utility bills etc).

The advantage of batch processing is that it allows merchants to track multiple transactions together. This feature is especially important in recurring billing, where a large number of transactions is involved, as batch transaction processing makes it easier to manage the overall process.

Companies that need to process numerous transactions on recurring basis have two options. One option is processing transactions one-at-a-time (effectively emulating batch transaction processing). The other option is actually generating a file and sending it to the payment gateway to process.

If transactions are processed one-at-a-time, authorization and settlement represent two different steps of the process, and if something goes wrong at settlement stage, it is problematic to manage the entire batch. On high volumes of transactions the process can take very long.

The second approach is “cleaner”, primarily because transaction authorization and settlement happen at the same time: the whole procedure is done “in one shot”, there is no need to do reconciliation of the settlement at the end. File-based batch transaction processing is also suitable for merchants that process e-checks (ACH transactions), because it makes the delivery of ACH transactions somewhat easier (one file, containing all transactions, is generated).

Let us consider a health club example to illustrate how batch transaction processing works.


A health club runs recurring billing daily to collect membership dues. In addition to that it also runs a decline recycling process (reprocesses all the declines on the subsequent day). As part of the decline recycling process another attempt is made on all of the declines. Real-time processing is possible, it makes it very difficult to keep track of the transactions, processed for a given billing date, and can, potentially, be time-consuming on those billing days when large numbers of accounts need to be processed. File-based batch transaction processing, on the contrary, provides an opportunity to view every billing date within the context of a batch and transactions that go through recycling process simply constitute a portion of that main batch (sub-batch), which makes things considerably more manageable for a large-size fitness club chain.


Based on merchant’s current or future/potential needs, the merchant that needs to process considerable number of recurring billing and bill payment transactions should consider looking for a processor capable of processing large files.

The next article will cover credit card decline recycling.

Payment Concepts: ACH Returns

The purpose of this article is to improve the understanding of ACH processing and the concept of ACH returns among merchants, resellers and credit card transaction processors. With better understanding of ACH processing lifecycle in general and nature of ACH returns in particular, considerable money losses from ACH fraud can be avoided.

Our previous post in this topic focused on credit card chargebacks, which are similar in nature to ACH returns. It might be beneficial to review that article before reading current one.

For those unfamiliar with the term, ACH stands for Automated Clearing House – a nationwide fund transferring network. Inter-bank transfers happen through an ACH operator – a Federal Reserve Bank or a private organization used as the central clearing facility. A more detailed explanation can be found here.

Why ACH returns are important

Misconceptions concerning сredit card transactions and ACH transactions are somewhat similar. Without a clear picture of complete credit card transaction processing cycle, people often forget about the possibility of chargebacks. Similarly, without thorough understanding of the full ACH transaction processing cycle, people often concentrate on the initial phase which includes processing and funding. Just like in the case of credit card transactions, ACH transaction approval is not the concluding phase of the processing cycle. To understand the full lifespan of ACH transactions, one needs to devote special attention to ACH returns. (To realize, the importance of ACH returns, it is sufficient to look at ACH return statistics).

Without a clear picture of the full ACH transaction processing cycle, a business can become a victim of ACH fraud. Consequently, the possibility of fraud, induced by the nature of ACH returns, should never be forgotten.

ACH return concept

An ACH return is a reject generated by the receiving depository financial institution (RDFI) in response to an ACH transaction, requiring money transfer, because it cannot be processed. The most common reasons (return codes) behind this include:

  • Insuffient Funds
  • Account Closed
  • Invalid Account Number

A complete list of return codes can be found here .

Many people think that once their ACH transactions are funded, this is the final stage of the process. Yet, ACH does not work like credit cards. For example, a person dealing with ACH transactions may think that if after two or three days the ACH return doesn’t arrive, the money already belongs to him\her. In practice the process may take up to two months. As mentioned above, the ACH transaction lifecycle involves the ACH operator, temporarily granting all the funds requested. Later the ACH operator may demand the funds back, if it turns out that the bank holding the account for which the request was placed couldn’t provide the money (possible reasons are mentioned above).

Let us take a more detailed look at how ACH returns occur.

ACH return mechanism

When a request is submitted to the ACH operator, the funds are granted. After that the ACH operator dispatches requests to the respective banks that are holding the accounts. If the request cannot be fulfilled by the bank, holding the account, the ACH operator requires the funds to be returned – and that money is taken back by means of generating an ACH return.

In addition to ACH return, there is a concept of a notice of change (NOC).
A change in bank account information of a customer may result from bank mergers, changes in account numbering schemes, etc. In cases like these, an ACH transaction is properly processed, using outdated information, but updated information to be used in any subsequent request, is returned to the submitter (merchant). This updated information sent to the submitter is called a notice of change. A notice of change requires the submitter to update the bank account information before submitting the next request. If, for instance, outdated routing number is used in a subsequent request, the transaction may not be processed, and can result in an ACH return.

Not all banks have fully automated (computerized) management systems, and in some cases they have to resolve certain issues by mail, telephone, or using other communication means. Consequently, the process of verification of funds’ availability on accounts can take up to two months. As a result, an opportunity for ACH fraud arises.

ACH fraud

As mentioned above, not all banks respond to ACH operator’s queries quick enough. A bank’s response may, take up to 60 days. Consequently, if an attacker (consumer or merchant) finds a bank with a long response time, he\she can use it to commit a fraud.

Consumer fraud

Consumer fraud can be committed by a merchant’s client. Particularly, such a client can order some product\ service from a merchant, pay for it through ACH, and get this product\service within a week. If an ACH operator needs two or three weeks to verify whether the bank account, specified by the client, actually exists and if there are some funds on it, the fraudster has the ability to use invalid account numbers for the purchase, and escape during the week between the purchase and the ACH return.

Merchant fraud

A merchant can commit a fraud against the Payment Service Provider (PSP).

Particularly, to commit a fraud, a merchant can submit ACH transactions specifying non-existent accounts whose routing numbers correspond to the “long-responding” banks. In this case the attacker’s transactions can get funded pretty quickly (as ACH operator initially grants the funds), but they will be returned after banks verify that the accounts do not actually exist (up to 60 days). But during this time the merchant has an opportunity to escape with the money, leaving the financial liability to the PSP.

There is a set of instruments merchants, resellers and processors can use to prevent ACH fraud.

ACH fraud prevention methods

The most common tools used by merchants against consumer fraud include:

  • IP-address-based filtering of accounts (if an account comes from a high-risk geographical location, the transaction is not processed);
  • identity verification against various blacklists (blacklists feature e-mails, addresses etc of potential fraudsters; if an account is on some blacklist, the transaction is declined, and there is no need for further time-consuming verification process);
  • check verification and check guarantee services. (An ACH transaction is, in fact, an electronic check. Check verification services include verification of the check-writer’s name, account number, and routing number data against different blacklists, as well as account status checks; check guarantee service requires all checks to be approved (through a terminal at the POS, voice authorization or I-check approval software installed on a PC) before being accepted).

The most efficient tools used by resellers and PSPs against merchant fraud are:

  • ACH reserves (held by processors\payment gateways and large-scale resellers to compensate potential ACH returns issued to their sub-merchants);
  • so-called “processing caps” (limiting the number and amount of transactions processed by a merchant during a fixed time interval, e.g. per week\day\month);
  • blacklists (for instance, featuring invalid bank accounts, for which ACH returns were previously generated).


Thorough understanding of ACH transaction processing cycle and competent implementation of respective fraud protection tools allows merchants, resellers and PSPs to prevent money losses resulting from fraudulent ACH returns.