Base24EPS TransactionProcessing

(1)

TCS

BASE24-eps Transaction

Processing

BASE24-eps™

Saikat 4/17/2014

(2)

Preface

The BASE24-eps Transaction Processing User Guide describes the various features and

processing concepts associated with BASE24-eps transaction processing. It is intended

to provide a general understanding of BASE24-eps transaction processing and to assist

in configuring and implementing various BASE24-eps transaction processing features.

Audience

This user guide is intended for readers seeking an understanding of BASE24-eps transaction

processing and more specifically for those BASE24-eps business users who handle the

configuration of transaction processing business data through the ACI Desktop (e.g., setting

up prefixes and routing).

Prerequisites

This user guide assumes a familarity with the ACI desktop user interface. Windows and

tabs are referenced by name throughout the manual, and menu paths are provided for

accessing windows through the ACI desktop; however, screen shots, information about

the ACI desktop, and procedures for basic window functions (e.g., adding, deleting, updating

and viewing records) are generally left to the BASE24-eps online help and these manuals:

• The ACI DesktopUser Interface Manual describes how to use the ACI desktop user

interface.

• The eps Windows Reference User Guide describes each of the BASE24-eps

windows and tabs available through the ACI desktop user interface. Screen shots of

each window and tab are provided along with information for each field on the window

or tab.

Additionally, much of setting up BASE24-eps transaction processing involves writing and

configuring your own authorization scripts for processing transactions.This manual touches

on different areas where scripts fit into transaction processing, but it does not describe

how scripts are designed or written. Because authorization scripts control a significant

amount of processing, an understanding of the scripts you plan to use is recommended.

(7)

8 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 Preface

Mentions are made throughout this manual to the following BASE24-eps manuals which

provide additional information about scripting.

• The BASE24-eps Scripting Manual provides detailed information on the scripting

capability of BASE24-eps, the Script Repository window, the Script Editor, scriptsyntax,

scriptable objects, exported operators, and writing standards.

• The BASE24-eps Sample Fundamental Authorization Scripts Delivery Document provides

information about delivered sample scripts that are designed for authorization processing,

the naming conventions of these scripts, implementation, and scripted authorization

methods. This manual is delivered with the BASE24-eps install.

Additional Documentation

The following manuals contain supplemental information related to transaction processing:

• The BASE24-eps Transaction Security Manual describes how to configure and implement

BASE24-eps transaction security, including PIN encryption, PIN verification, message

authentication, message data encryption, card verification, dynamic card verification,

EMV card authentication, secure Internet validation, and dynamic key management.

The manual also describes how hardware security modules are integrated into BASE24-eps processing and the duties they can assume as a part of that processing.

• The BASE24-eps Multiple Currency Manual describes the processing and configuration

of the BASE24-eps Multiple Currency add-on module.

• The BASE24-eps EMV Support Guide provides information about configuring BASE24-eps to process EMV (Europay, MasterCard, and Visa) cards and describes the processing of BASE24-eps EMV transactions.

• The BASE24-eps Journal User Guide provides an overview of transaction journals and

their use in a BASE24-eps system.

• The BASE24-eps Environment Management User Guide describes environment attributes

and how to configure these attributes.

• The BASE24-eps ISO 8583:1993 Host External Message Manual provides detailed information on the layout of the external message used by ISO 8583:1993 hosts.

Software

This user guide documents standard processing for the current BASE24-eps version as

of its publication date. Software that is not current and custom software modifications (CSMs) may result in processing that differs from the material presented in this manual.

(8)

Preface

Manual Summary

The following is a summary of the contents of this user guide:

• BASE24-eps Transaction Processing on page 12 - provides a set of introductory

topics defining basic terms and concepts related to transaction processing.

• Prefixes on page 22 - Defines and describes prefixes and how they are used in

BASE24-eps transaction processing.

• Payment Instruments, Cards, and Accounts on page 28 - Defines payment

instruments, cards, and accounts and describes how they are supported by BASE24-eps.

Information is included about how account activity and account balances are handled.

• Transactions Allowed on page 52 - Defines Transactions allowed, which is a

basic

transaction screening function that BASE24-eps provides as a part of routing and authorization, and describes how to configure it for acquirers and issuer endpoints. • Transaction Routing on page 60 - Describes transaction routing and how it is

configured within BASE24-eps.

• File Update Routing on page 103 - Describes file update routing and how it is

configured

within BASE24-eps. File update routing is a specialized form of routing--carried out by

the File Update Router component--that enables the routing of file updates and file update transactions in the BASE24-eps system.

• Authorization, Prescreening, and Impacting on page 113 - Describes the basics

of

authorization, prescreening, and impacting, all of which are carried out by scripts. Basic

information is provided about how scripts are used and identified for processing. Information is also provided about sequential routing, which is a script-based form of routing, and about default authorization.

• BASE24-eps Transaction Limits and Usages on page 141 - Describes

transaction

limits and usages and how they are supported by BASE24-eps. Information is provided

about how limits are set and how usages are tracked.

• Preauthorization Holds on page 161 - Describes preauthorization holds and how

they

are used within BASE24-eps. Information is included about preauthorization transactions

and match and hold process*sing. The latter provides the capability to introduce batch

records of settled transactions into the BASE24-eps system for the purpose of removing

their corresponding holds.

• Check Processing on page 183 - Describes how check processing is supported

by

BASE24-eps. Information is included about MICR data handling by BASE24-eps and how preapproved and predeclined checks can be defined to BASE24-eps.

(9)

• Stop Payment Processing on page 197 - Describes how stop payment

processing is

supported by BASE24-eps.

• Card and Prefix Blocking on page 206 - Describes how card and prefix blocks

are

supported by BASE24-eps.

10 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 Preface

• German Routing and Authorization (Regional) on page 214 - Describes the

German

regional routing and authorization support provided by BASE24-eps for German cards

processed through German endpoints.

• BASE24-eps Transaction Flows on page 225 - Provides diagrams and

step-by-step

processing descriptions of how BASE24-eps handles various types of transactions. • Primary Transaction Identifiers on page 261 - Provides reference information for

several transaction identifiers that are of primary importance to processing: Message Type Identifiers (MTIs), function codes, message reason codes, point of service data,

processing codes, and action codes.

Publication Identification

Two entries appear at the bottom of each page to uniquely identify this BASE24-eps publication: the publication date (for example, Sep-2009 for September 2009) and the

publication number (for example, ES-CS000-29 for the BASE24-eps Transaction

Processing User Guide).

Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 11 Preface

BASE24-eps Transaction

Processing

BASE24-eps provides the means by which a transaction originator can request and receive

authorization for an action on a customer card or account from a transaction authorizer.

The role of BASE24-eps in transaction processing includes the following:

• Routing transactions from the transaction originator to the appropriate authorizer. • Participating in or carrying out authorization on behalf of the institutions for which it processes.

• Journaling all transactions for later processing and settlement.

BASE24-eps can accept transactions from a variety of sources. Likewise, it can involve a

number of different authorizers in its processing.

12 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 BASE24-eps Transaction Processing

(10)

BASE24-eps Transaction Originators

BASE24-eps can accept transactions for authorization from several different types of originators.

ATM Channels

Automated teller machines (ATMs) can be directly attached to BASE24-eps, in which case

transactions are originated by customers or service personnel at the ATM. Communications

between the ATM and BASE24-eps are controlled by ATM Channel Manager components.

Point-of-Sale Device Channels

Point-of-sale (POS) devices can be directly attached to BASE24-eps, in which case transactions are originated by customers, service personnel, or retail clerks at the point of

sale. Communications between the POS device and BASE24-eps are controlled by Merchant Channel Manager components.

Hosts

Host computers can be set up to control ATM or POS device networks and forward transactions to BASE24-eps. In this case, communications between these acquirer hosts

and BASE24-eps are controlled by an ISO Host Interface component.

Interchanges

Interchanges can act as switches to forward transactions to BASE24-eps for authorization.

In this case, communications between the interchange acquiring the transaction and BASE24-eps are controlled by Interchange Interface components.

Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 13 BASE24-eps Transaction Processing

BASE24-eps Transaction Authorizers

BASE24-eps can route transactions to several types of authorizers.

BASE24-eps

BASE24-eps can be set up to authorize transactions in those situations where cardholder

files are maintained on the BASE24-eps system.

Hosts

Hosts can be set up to authorize transactions in situations where cardholder files are maintained on the host computer. In this case, BASE24-eps can pre-screen the transactions

before sending them to the host and can also be set up to stand in and authorize transactions for a host in situations where communications between BASE24-eps and the

host system are down.

Interchanges

Interchanges can be used to forward transactions to other networks for authorization. 14 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29

(11)

Issuers and Acquirers

Transaction originators and authorizers are generally defined by the EFT industry terms

acquirer and issuer. An acquirer, or transaction acquirer, is the party that originates a

transaction. An issuer, or card issuer, is an institution that issues cards or owns accounts

that can be used in EFT transactions.

Whether an entity is defined as an issuer or an acquirer depends on the perspective from

which the transaction is viewed. Intermediary networks and processors that receive transactions from a transaction originator and authorize them or forward them elsewhere

for authorization can be acting on behalf of both the acquirer and the issuer. From the acquirer point of view, intermediary networks are acting on behalf of the issuer.

For example, a cardholder initiates a transaction at an ATM belonging to institution A. In

this case, institution A is the transaction acquirer. Institution A sends the transaction to an

intermediary network that, in turn, sends the transaction to institution B for authorization.

Institution B owns the cardholder’s account and issued the cardholder the card; therefore,

institution B is the true issuer. However, from the point of view of institution A, the intermediary network is performing as an issuer on behalf of institution B since institution

A had to send the transaction to the intermediary network before it could reach its authorizing

destination.

From the issuer point of view, intermediary networks are acting on behalf of the acquirer.

As in the above example, institution B views the intermediary network as an acquirer since

the intermediary network is the entity that sent it a transaction to be authorized. BASE24-eps can process transactions on behalf of an issuer or an acquirer, depending

on where a transaction originates and who is to authorize the transaction. For example,

when BASE24-eps sends a transaction to a back-end host for authorization, BASE24-eps

represents the acquirer in the message exchange and the back-end host represents the

issuer. On the other hand, when a transaction is sent to BASE24-eps for authorization,

the sending host represents the acquirer and BASE24-eps represents the issuer. Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 15 BASE24-eps Transaction Processing

(12)

Hosts can play a prominent role in the transaction processing performed by BASE24-eps.

A host is an external mainframe computer system with which BASE24-eps interacts, either

online or by batched tape, to authorize transactions and/or update cardholder records.

Although the term host generally refers to an actual computer or system of computers, the

term also refers to the institution or organization responsible for the host computer system

and its processing. For example, in the phrase, “the host can opt to receive advice messages,” the term host actually refers to the BASE24-eps-defined institution in control

of the host computer, rather than the computer itself.

Hosts are assigned identification numbers and are defined to BASE24-eps in the Host

Interface Configuration data source (HISO93_INTERFACE). Each host must have a record

in the HISO93_INTERFACE to be recognized by BASE24-eps.The HISO93_INTERFACE

contains options that allow you to specify individual processing parameters for each host.

Authorization Environments

Authorization environments define the general level of participation BASE24-eps is

to have

in the authorization of transactions.You need to be aware of the level of participation you

want BASE24-eps to have when planning your routing and authorization.

Online Authorization

In an Online Authorization environment, a host performs all authorization processing (i.e.,

the host system is the authorizer). If BASE24-eps cannot communicate with the host (i.e.,

is unable to send transactions for processing), it declines all transaction requests in which

the host is the destination.

Though BASE24-eps is not the authorizer, it can be configured to prescreen transactions

in an online authorization environment. In this case, if a transaction does not meet the

prescreening requirements, the transaction is declined, and BASE24-eps sends a deny

response to the originator and notifies the host. If the transaction does meet prescreen

requirements, the transaction is then forwarded to the host for authorization.

Therefore, in this environment, authorization scripts would be limited to prescreening functions.

(13)

Offline Authorization

In Offline Authorization environments, all authorization processing is performed by BASE24-eps; authorization requests are not forwarded to the host. As a result, scripts will

perform more extensive processing and data checking than those scripts used in an online

authorization environment.

In offline authorization, BASE24-eps maintains account and payment-instrument data and

transaction journal files. As a result, data file information must be exchanged and updated

periodically between BASE24-eps and the host.

In this environment, your authorization scripts would need to handle all aspects of transaction authorization.

Online/Offline Authorization

In a combined Online/Offline Authorization environment, BASE24-eps can be configured

to prescreen transactions for a host as in the online authorization environment. However,

in this environment, BASE24-eps also stands in for the host and authorizes transactions

when communication with the host is down. The transactions BASE24-eps authorizes are

stored in a store-and-forward (SAF) file for forwarding to the host when communication is

restored.

Data file information is exchanged and updated periodically as in the offline authorization

environment.

In this environment, your authorization scripts would typically be divided between prescreening functions to be performed prior to sending a transaction to the host, impacting

functions to update the BASE24-eps data base once a transaction is returned from the

host, and authorization functions to be performed should the host be offline. The latter

functions/scripts might impose tighter restrictions given that the host is unavailable. 18 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29

BASE24-eps Transaction Processing

Transactions and Transaction Messages

From a processing standpoint, transactions are actually carried out through one or more

transaction messages. Messages are the means by which information is exchanged between parties, typically in a request/response interaction where one party requests an

(14)

action and the other either says yes or no or offers an alternative. In some cases, there

may be additional messages. In some cases, one party may have taken an action and

may simply be notifying the other party. In all cases, however, the messages used are

based on a standard and are exchanged based on the protocols established by the standard.

Each message carries pertinent transaction information and is built with unique characteristics that allow transaction processors to identify the intended purpose of the

message and the specific actions or services to be performed related to the message.

From a BASE24-eps perspective, each transaction message can be thought of as a discreet

request for some type of service related to a transaction.

BASE24-eps can receive messages from a variety of endpoints or channels to which it is

connected. Endpoints can include ATM or POS devices, hosts, and interchanges. BASE24-eps can also initiate messages as part of its processing. A transaction message

can represent a request for an authorization or another type of action, a response (and

possible authorization) to a previous request, or a notification that a particular action has

taken place. In any case, the receipt of a message by BASE24-eps from a connected

endpoint, or the creation of a specific transaction message by BASE24-eps, initiates a

prescribed set of actions or services—actions or services as defined by the BASE24-eps

system owner.

Primary Identifiers: Message Type Identifier (MTI) and

Processing

Code

Although there are many transaction message characteristics that can and do influence

the services provided by BASE24-eps, all messages processed by BASE24-eps are differentiated by two primary identifiers: a Message Type Identifier (MTI) and a processing

code. Regardless of the endpoint originating a message, all transaction messages are

defined within BASE24-eps by a set of recognized MTIs and—in almost all

cases—processing codes (network management messages do not carry processing codes).

Transactions to and from various endpoints (entities outside the BASE24-eps system)

must be translated between the business rules, protocols, and processing requirements

(15)

of the respective endpoints and the internally normalized processing values by which BASE24-eps recognizes and processes the transactions. Message translation is one function of the various BASE24-eps channel interfaces on behalf of ATM/POS

devices,

hosts, or interchanges.

Card-based Processors

There are three broad categories into which BASE24-eps card-based processors typically

fall: terminal acquirers, financial switches, and card issuers. Each has its own routing and

authorization requirements. A single BASE24-eps institution could fall into a single category

or any combination of the three.

Terminal Acquirers

Terminal acquirers are processors that use the BASE24-eps system to drive ATM or

POS

terminal networks. These processors typically maintain an extensive terminal database

and route transactions through interfaces to external interchanges. Terminal acquirers

typically have little or no stand-in authorization capabilities and maintain interfaces to multiple interchanges.

Financial Switches

Processors who use the BASE24-eps system to route acquired transactions to card issuers

act as a financial switch. These processors do not drive terminals and are mainly concerned

with routing transactions acquired from an interchange to a card issuer. Financial switches

can have substantial stand-in authorization capabilities.

Card Issuers

Card issuers are processors that use the BASE24-eps system to authorize

transactions.

These processors typically maintain a substantial card database and connect to a host.

Card issuers may or may not drive terminals.Their main concern is authorizing transactions

acquired from an interchange. Because the account of record is maintained on a host, the

host is the primary authorization destination. However, card issuers typically have substantial

stand-in authorization capabilities when the host link is unavailable.

Non-Card-Based Processors

Typically, cards or card numbers are used to initiate financial transactions, and in the interest of clarity, this is the type of processing described throughout the BASE24-eps

(16)

product documentation unless specifically noted to the contrary.

Important to note, BASE24-eps is adaptable to other types of instruments. For example,

where card-based acquirers use a card prefix obtained from the primary account number

(PAN) of a card to determine the issuer, other types of processors might use customized

components to determine the issuer/authorizer of a transaction. For instance, a mobile

phone acquiring component might use an entirely different means—perhaps invoking a

custom component to determine the issuer based on the phone number used to initiate

the transaction.

Prefixes

Much of BASE24-eps routing and authorization processing is controlled at the prefix level,

meaning that processing can be set up differently for different prefixes. The topics here

describe prefixes and how they are used in BASE24-eps processing.

22 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 Prefixes

What is a Prefix?

A prefix is a number—the first portion of a larger number, such as the primary account

number (PAN) for a credit or debit card account. In BASE24-eps, prefixes are used in

conjunction with the overall length of the PAN to identify the issuer of a card account. In the following example, the indicated card number would be recognized as a match on

the values defined for the prefix and length.

Card Number Prefix Length

5011 1234 1234 1234 5011 16 position

A card issuer can be assigned a single prefix or several. However, with the BASE24-eps

system, each prefix must be unique to a card issuer. That is, no two card issuers can be

assigned the same prefix.This uniqueness enables BASE24-eps to use the prefix to identify

transactions that involve local issuers (institutions) defined to the system.

Also, because of their fundamental uniqueness within BASE24-eps, a significant portion

of authorization processing is defined at the prefix level. That is, BASE24-eps institutions

(17)

can specify different processing parameters for each of their prefixes.

Note: Cards are a typical form of financial instrument used in transactions. The term

card

is used here to mean instrument.

Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 23 Prefixes

Local (On-Us) and Non-Local (Not-on-Us)

Prefixes

As part of BASE24-eps transaction processing, prefixes are defined as local (on-us) or

non-local (not-on-us).

Note: The BASE24-eps definitions of on-us and not-on-us are different from the

strict

industry-standard definition of the terms, where an on-us transaction means the acquirer

and issuer institutions are the same, and a not-on-us transaction means the acquirer and

issuer institutions are different.

Local (On-Us) Prefixes

Card issuers can be local to the BASE24-eps system, which means that the issuer is defined as a BASE24-eps institution and each prefix for which the institution issues cards

is defined as an on-us prefix to the system as well.Transactions acquired by BASE24-eps

on cards with on-us prefixes are referred to as on-us transactions and are typically authorized by BASE24-eps or a back-end host.

On-us prefixes are defined to BASE24-eps using the On-Us Prefix Configuration window

(Configure > Prefix > On-Us). The information from this window is used to populate the

Prefix data source (Prefix).

Non-Local (Not-on-Us)

Card issuers can be non-local to the BASE24-eps system, meaning their prefixes are not

defined as on-us prefixes. Prefixes associated with these non-local card issuers, called

not-on-us prefixes, must still be defined to BASE24-eps in order to be be recognized

and

processed.

Not-on-us prefixes are defined to BASE24-eps using the System Prefix Configuration window (Configure > Prefix > Not-On-Us > System Prefix). The information from this

window is used to populate the System Prefix data source (System_Prefix).

Transactions acquired by BASE24-eps on cards with these not-on-us prefixes are referred

to as not-on-us transactions and are typically sent to an interchange for processing. 24 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29

(18)

Prefixes

BASE24-eps Prefix Processing

The initial identification of a transaction acquired by BASE24-eps is based on the prefix of

the transaction PAN in conjunction with the PAN length.

Prefixes for acquired transactions fall into the following general categories:

On-Us Prefixes Not-On-Us Prefixes

Prefixes Recognized by Unrecognized Prefixes Algorithm

Interchange Prefixes

A prefix that cannot be identified by BASE24-eps by any means available to it. A prefix that is not specifically defined to BASE24-eps, but can be identified based on an algorithm match.

A prefix that is specifically defined to the BASE24-eps in an Interchange prefix data source.

A prefix that is specifically defined to the BASE24-eps in the Prefix data source.

When the Acquirer Interface component invokes the Prefix component to determine the

transaction issuer, it first determines whether the issuer is a known (recognized) issuer by

searching for a match on the prefix in the Prefix external memory table (Prefix_OLTP).

If a match is found, the component invokes the Transaction component to add to the transaction the Issuer Route Profile and Route Type TDEs, as well as several other TDEs

not specifically used in routing and returns control to the Prefix component.

If the Prefix component does not find a match in the Prefix external memory table, it attempts

to find one using the methods defined in the System Prefix external memory table (System_Prefix_OLTP).These methods include searching Interchange Prefix data sources,

testing the transaction prefix against an algorithm, or using a default value. The Prefix

component uses the methods in the order in which they are defined in the System Prefix

external memory table.

When the Prefix component finds a match on the transaction prefix, it invokes the Transaction component to add to the transaction the Issuer Route Profile and Route Type

TDEs and returns control to the Acquirer Interface component.

If a match is not found in either the Prefix or System Prefix external memory tables, the

transaction is denied.

(19)

Setting Up On-Us Prefixes

Local issuers (institutions) must define each on-us prefix to be processed by BASE24-eps

using the On-Us Prefix Configuration window (Configure > Prefix > On-Us). Each prefix

must be explicitly defined, along with the BASE24-eps processing associated with the

prefix.

Much of BASE24-eps routing and authorization processing is controlled at the prefix level,

meaning that processing can be set up differently for different prefixes.

The information from the On-Us Prefix Configuration window is used to populate the Prefix

data source, from which the Prefix external memory table is built.

Identifying a Prefix

The key used to identify a prefix is actually the prefix itself and length of the PAN in which

the prefix can be found. Thus, when you define a prefix you are actually defining it in combination with the PAN length.

Note: An institution must be defined to which an on-us prefix belongs.

Defining On-Us Prefix Routing Parameters

There are only a few routing parameters configured for a prefix, which makes sense because

at the point the prefix is identified, the issuer is known.

On-Us Prefix Configuration Window Setting (for Routing) Tab Field Description

The route type value to be used for the transaction. Values are as follows:

Processing Information Route Type

Acquirer and Issuer — Means that a business relationship should be taken into consideration, and transactions will be evaluated for a route code.

Issuer Only — Means that a business relationship does not exist for this prefix and transactions will not be evaluated for a route code. This value is moved to the Route TypeTDE.

Refer to Enabling and Disabling the Use of Routing Codes at the Prefix Level on page 99 for more information about how this field is used.

The instrument type to be assumed for the transaction. Issuer Information Instrument Type

This value is moved to the Instrument Type TDE.

The name of the Destination Routing Profile to use for the transaction. Destination Routing

Profile

This value is moved to the Issuer Routing Profile TDE.

26 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 Prefixes

Setting Up Not-On-Us Prefixes

The controls for recognizing and processing transactions with not-on us prefixes are defined

through the Source Routing Profile, which are assigned to the various acquiring endpoints.

(20)

Refer to Source Routing Profiles on page 88 for information about the Source Routing

Profile.

Payment Instruments, Cards, and

Accounts

The topics here describe payment instruments, cards, and accounts and how they are

used in BASE24-eps processing.

28 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 Payment Instruments, Cards, and Accounts

Payment Instruments

A payment instrument is a device by which consumers can initiate payment transactions.

Cards are the typical payment instrument used in the payments industry, and in the interest

of clarity, cards are the instrument type assumed throughout the BASE24-eps product

documentation unless specifically noted to the contrary. Important to note, however, BASE24-eps is adaptable to other types of instruments as well.

Instrument Types

Instrument type is a one- or two-character user-defined identifier (code) used

throughout

BASE24-eps to identify types of payment instruments. Each instrument defined to the

system must have a corresponding instrument type associated with it.

In a card-based payment system, the instrument type represents the branding of the card,

such as Visa Debit, Visa Credit, American Express, and MasterCard, among others.

Defining Your Instrument Types

Instrument types are defined for the BASE24-eps system in the Instrument Type (Instrument_Type) data source and can be viewed and managed using the Instrument

Type Configuration window (Configure > Instrument Type). Once defined, instrument

types can be selected as valid types for the various instruments (i.e., cards) you want to

define.

Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 29 Payment Instruments, Cards, and Accounts

Cards

Cards—that is plastic debit or credit cards—are a type of payment instrument. They

(21)

as evidence of one or more accounts and act as a mechanism for accessing the accounts

using the many electronic funds transfer (EFT) channels available.

Configuring Cards

Cards are configured on the Card Management window (Customer Management >

Card)

or the Administrative Card Configuration windows (Configure > Administrative

Card).

Associating Cards and Prefixes

Any cards to be processed by BASE24-eps must have their prefixes defined to the system

as on-us (known) prefixes. For information on on-us prefixes, refer to Setting Up On-Us

Prefixes on page 26 for information about setting up on-us prefixes.

Prefix definitions specify processing parameters and associated limits for a prefix. These

parameters and limits can be used in authorization or prescreening processing for cards

that belong to the prefix—if the parameters and limits have not been defined more specifically for the card.

Associating Accounts with Cards

BASE24-eps supports up to 80 accounts associated with a single card. Refer to Accounts

on page 40 for more information about accounts and associating them with cards.

How Cards are Identified in BASE24-eps

Cards are identified to BASE24-eps using several identifiers that are important to understand.

Primary Account Numbers (PANs)

Cards are identified by a primary account number (PAN) that is embossed on the front of

the card and encoded on the magnetic strip.

The PAN is a composite number that contains a prefix consisting of the bank identification

number (BIN) of the card issuer followed by a possible regional identifier, an individual

account identifier that includes part of the account number, and a check digit or code that

verifies the authenticity of the embossed account number or the PAN on the track. The

length of a PAN varies by card type but is typically 16–19 digits.

You can view the PAN of a card defined to BASE24-eps in the Card Number field on the

Card Management window (Customer Management > Card).

(22)

The member number is a card sequence number used to identify an individual member

when several members have the same card number. This enables you to issue different

plastics with the same PAN, but different member numbers, and define each with its own

unique card record in BASE24-eps. If a card has only one member, the corresponding

member number would be 000, and there would only be one BASE24-eps record representing the card. If there were multiple members (e.g., 001, 002, 003), each could

have his or her own plastic and each plastic would have its own BASE24-eps record. The member number associated with a card is identified in the Member Number field of

the Card Management window (Customer Management > Card).

Institution (Card Issuer)

The institution that issued a card is identified by its institution ID. All cards defined to the

BASE24-eps system must have a corresponding issuer institution defined to the system—prior to adding the cards.

The card issuing institution is identified for the card in the Institution ID field of the Card

Management window (Customer Management > Card).

Institution records are accessed and updated using the Institution Configuration window

(Configure > Institution).

Card Information Maintained by BASE24-eps

Card information is maintained in the Card, Card Account, and Card Account Multibyte

data sources.

Customer ID

The customer ID of the Card record identifies the name of the customer or business to

which the card was issued.

You can view or change the customer ID associated with a card on the General tab of the

Card Management window.

Note: Depending on your environment, a multibyte version of the customer ID can

be

entered. If present, the multibyte value is carried in the Card Account Multibyte data source.

Depository Type

The depository type specifies the preferred type of deposit for the card used by the customer: Standard or Commercial.

Your scripts can use this value to set the Depository Type TDE. The Depository Type TDE

(23)

can then be used by those device handler components that support the capability to specify

to terminals the depository to open for deposit transactions.

You can view or change the depository type associated with a card on the General tab of

the Card Management window.

Card Types

Card types are a specific form of instrument type. They are a one- or two-character

user-defined identifier (code) used throughout BASE24-eps to identify the type of card.

Each card defined to the system must have a corresponding card type associated with it.

Refer to Payment Instruments on page 29 for information about how available instrument

types are defined in the system.

You can view or change the card type associated with a card on the General tab of the

Card Management window.

Note: The INSTRM_TYP Card object script operator returns the one or

two-character

code representing the instrument type of the card used in a transaction.

PIN Information/PIN Verification Value (PVV)

PIN verification during transaction processing can require the use of a PIN verification

value (PVV), which is combined with the customer-entered PIN and other data to allow for

verification.

BASE24-eps enables you to configure—at the prefix level—whether the PVV will be acquired from the card itself (in the track data), or from the Card record, or not at all. This

prefix setting is specified in the PIN Location fields on the On-Us Prefix Configuration window. If the prefix setting indicates the PVV is to be acquired from the Card record, the

PVV needs to be placed in the Card record for those cards associated with the prefix.

The PVV is not displayed; it is carried in the Card data source, but you can change it from

the General tab of the Card Management window. The PIN verification value is masked

on the window and must be entered twice to ensure that it is entered correctly. For information about PIN verification, refer to the BASE24-eps Transaction Security

Manual.

Last PIN Change Date

The date and time of the last PIN and PIN verification value change for the card is displayed

in the Last PIN Change field on the General tab of the Card Management window. This

(24)

date is updated in the following situations:

• A new PVV is entered on the Card Management window.

• The new PVV is created as the result of an online PIN change transaction. • A new PVV is created as the result of the cardholder choosing a PIN on the first online

transaction for the card.

• The PVV is set by a partial-file refresh or file update transaction.

• The PVV change date is set explicitly by a partial-file refresh or file update transaction.

Check Processing

BASE24-eps check processing enables you to specify at the prefix and card level whether

to evaluate check-based transactions against your total cash advance and total withdrawal

limits. If defined at the card level, these settings are on the General tab of the Card Management window. For information about these check settings, refer to Check Limits/Usages on page 196.

Card Status

Card status indicates whether a card is open, closed, lost, stolen, or pending

activation.

This information is critical to authorization processing in that the status of a card is a major

factor in determining processing allowed on the card. For example, transactions would

typically be denied for lost, stolen, and closed status cards, however, transactions on cards

that are lost or stolen might also provide the opportunity to retain the card on behalf of the

card issuer.

Status values are user-defined for your system in the CommonCodesValues.properties

file. Values of 00–15 are intended for Open statuses; values 16-99 are for other values.

The default values here correspond to values in the standard authorization scripts delivered

with the BASE24-eps application. These values can and should be changed for specific environments. Value Description 0–15 Open 60 Denied - Lost 70 Denied - Stolen 80 Denied - Closed

You can view or change the card status associated with a primary or secondary card on

the Status tab of the Card Management window.

Note: The system tracks the date and time the status last changed for primary and

secondary cards defined in the BASE24-eps system. This information is displayed in the

(25)

Status Last Change Date fields on the Status tab of the Card Management window.

Effective Date

If you want a card to become usable as of a specific date, you can set an effective date

for the card. The effective date is intended to be the first date BASE24-eps will authorize

transactions on a card and can be used by your authorization scripts for that purpose (currently, the sample authorization scripts do not include this processing).

You can view or change the effective date associated with a primary or secondary card

on the Status tab of the Card Management window.

Placing a check mark in the Use Effective Date field on that tab enables the associated

date field and can also be used by your authorization scripts to control whether or not to

use the effective date field in processing.

Note: The system tracks the date and time the effective date last changed for

primary

and secondary cards defined in the BASE24-eps system. This information is displayed in

the Effective Last Change Date fields on the Status tab of the Card Management window.

Expiration Date

If you want a card to expire as of a specific date, you can set an expiration date for the

card.The expiration date is the last date BASE24-eps will authorize transactions on a card.

You can view or change the expiration date associated with a primary or secondary card

on the Status tab of the Card Management window.

Placing a check mark in the Use Expiration Date field on that tab enables the associated

date field. The date placed in that date field is the last date the card will be usable.

Note: The system tracks the date and time the expiration date last changed for

primary

and secondary cards defined in the BASE24-eps system. This information is displayed in

the Expiration Last Change Date fields on the Status tab of the Card Management window.

Card Limits

The limits profile and the limit overrides to be used by a card are specified on the Limits

tab of the Card Management window. For information about these limit profiles and overrides, refer to Assigning Limit Profiles to Cards, Accounts, and Prefixes on page 149.

Note that card usages are maintained in their own data source and are not part of the card

record.

(26)

Payment Instruments, Cards, and Accounts

Cardholder Address/Address Verification Settings

The cardholder address associated with a card consists of two lines of cardholder address

information and the postal code for the cardholder address. This information can be entered

for informational purposes or it can be used in address verification service processing (AVS

processing).

AVS processing gives merchants the capability to use the cardholder’s address information

to confirm that a customer is entitled to use an account in situations where it is not possible

to physically examine the card and the customer’s signature.

You can view or change the address information on the Address tab of the Card Management window.

If you want to use the cardholder address information for address verification, place a

check mark in the Use Address Verification field on the Address tab of the Card Management window. Leaving this field blank means the cardholder address information

is being used for informational purposes only and will not be used for address verification.

Note: Depending on your environment, multibyte versions of the two customer

address

lines and postal codes can be entered. If present, these multibyte values are carried in the

Card Account Multibyte data source.

Note: The CRD_AVS_FLG Card object script operator is used to check the Use

Address

Verification field. If the flag is enabled, the ADDR_VRFY Card object script operator can

be used to invoke address verification processing.

Accounts

BASE24-eps supports up to 80 accounts associated with a single card. These are set up

on the Accounts tab of the Card Management window. Refer to Accounts on page 40 for

more information about accounts and associating them with cards.

Primary and Secondary Cards

When institutions reissue cards, there can be a period of time when two physical cards

are in circulation with the same card number (and member number), but different expiration

dates.

BASE24-eps enables you to configure the following information separately for primary and

secondary cards in the same Card record. • Card Status

(27)

• Effective Date • Expiration Date

In processing, the primary and secondary cards are differentiated by their expiration date

(i.e., the expiration date on the card can be compared to the expiration dates for the primary

and secondary cards in the Card record).

You can view or change the primary and secondary card information on the Status tab of

the Card Management window.

Script Operators

The following Card object script operators are used in support of primary and secondary cards: SCND_STAT SCND_STAT_SET PRI_STAT PRI_STAT_SET IS_PRI_EFF IS_PRI_EXP

IS_SCND_EFF PRI_STAT_SET_NOTIFY SCND_STAT_SET_NOTIFY IS_SCND_EXP

These operators can be used to determine whether the card used to initiate a transaction

is the primary (original) or secondary (reissued) card by comparing the expiration date of

the card to the primary and secondary card expiration dates in the Card data source. The

operators can also be used to activate the secondary card when the first transaction using

the card is received and/or the operators can be used to promote the secondary card to

become the primary card. Refer to the BASE24-eps Scripting Manual for more information

about these and other script operators.

Refreshing Card Information

Card information is carried in the Card (Card), Card Account(Card_Account), and Card

Account Multibyte (Card_Account_Multibyte) data sources. These data sources can be

refreshed using full-file or partial-file refreshes.

For information about refreshes, refer to the BASE24-eps File Refresh User Guide.

The Last Time the Card Information Was Refreshed

At the bottom of the General tab on the Card Management Window is information about

the last time (Refresh Timestamp) the card record was refreshed from a host and the identifier of the batch (Refresh ID) used to refresh the record.

If timestamp and ID information is not provided, it indicates that the card record has not

(28)

been updated by a refresh.

Note: Card information in the Card (Card), Card Account(Card_Account), and Card

Account

Multibyte (Card_Account_Multibyte) data sources can also be updated using file update

transactions. This type of update does not update the refresh date information. 36 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 Payment Instruments, Cards, and Accounts

Administrative Cards

Administrative cards are a special type of card identified within BASE24-eps for

different

forms of administrative channel processing.

The processing and configuration requirements of an administrative card can vary depending

on the type of channel in which they are used:

• ATM terminal-owning institutions issue administrative cards for servicing and settling

terminals.

• Point-of-sale terminal owners typically issue administrative cards at the merchant level

for settlement purposes.

Administrative cards enable terminal-owning institutions or merchants to initiate administrative transactions at an ATM or point-of-sale terminal, respectively. Cardholder

transactions, such as a return or an adjustment, can be configured to require the input of

an administrative card as well as the cardholder’s card.

For transactions acquired in the BASE24-eps system from a channel device (e.g., ATMs

or point-of-sale terminals) using an administrative card, transactions are authorized in

scripts using the same Card script operators in scripts that are used to access non-administrative card information.

Transactions Allowed

The Admin Card Required field on the Acquirer Transactions Allowed Profile Configuration

window (Configure > Transactions Allowed > Acquirer Transactions Allowed) specifies

whether an administrative card is required to enter a transaction.

Prefix Considerations

Large ATM or point-of-sale network owners may want to issue administrative cards using

a card prefix reserved for just administrative cards while smaller ATM or point-of-sale network owners may want to designate a range of card numbers from within their cardholder

base to be used as administrative cards. In either case, the card prefix for administrative

(29)

If an entire card prefix is configured to be used exclusively for ATM administrative cards,

set the Instrument Type field on the Issuer Information tab of the On-Us Prefix Configuration

window to AD (Administrative).

Setting Up Administrative Cards for Use with

Point-of

Sale Terminals

Administrative cards for point-of-sale terminals are configured and accessed on the Administrative Card Configuration window (Configure > Administrative Card). Data from

this window is stored in the Administrative Card data source (Admin_Card). Before entering an administrative card record, you must configure the on-us card prefix to

be used to recognize the administrative card number and the merchant with which the

administrative card is associated.

Identification Information

The following information identifies the administrative card.

Field Description

Card Number The number of the administrative card.

User Name The user name associated with the administrative card.

The merchant ID associated with this administrative card. The administrative card can only be used at POS terminals associated with this merchant.

Merchant ID

PIN Information

The following information identifies the PIN information associated with the administrative

card.

This is not displayed, but can be changed on the Administrative Card Configuration window. To change it, the value must be entered twice.

PVV

PVV Key Index Specify the PVV Key Index to be used with the PVV.

Usage Information

The following information identifies the usage information associated with the administrative

card.

Last Used The date the card was last used.

The number of bad PIN tries attempted for the administrative card since the bad PIN tries was last reset.

Bad PIN Tries

The date the bad PIN tries were last reset. Typically, the entry of a correct PIN causes the bad PIN tries to reset to zero.

Last Reset

(30)

Administrative cards can only be used to initiate those transaction types that are specifically

enabled for the card.

The check boxes in the Allowed Transaction Types section of the Administrative Card Configuration window indicate the transactions the administrative cardholder is allowed to

perform with the card. A check mark in the box next to the transaction type means the

administrative cardholder is allowed to perform that transaction; otherwise, the transaction

is not allowed. The following is a list of transaction types that can be enabled for an administrative card.

Allowed Transaction Types

Administrative Shift Close 95 (Administrative Subtotal) (94)

Administrative Day Close (93)

Administrative Batch Close (92)

30 (Available Funds Inquiry 31 (Balance Inquiry) 38 (Card Verification Inquiry) 03 (Check Guarantee) 04 (Check Verification) 22 (Credit Adjustment) 02 (Debit Adjustment) 00 (Purchase)

01 (Withdrawal/Cash 20 (Return) A0 (Activation) Advance)

09 (Purchase with Cash Back)

5C (Bulk Authorization) 2A (Funds Disbursement) 9U (Offline Phone Top Up) 0A (Phone Top Up)

Setting Up Administrative Cards for Use with ATMs

Administrative cards for ATM terminals are configured and accessed on the Card Management window and are stored in the Card data source (Card). They are similar to

customer cards—the major difference is that the Card Type field on the General tab of the

Card Management window must be set to a value of AD - Administrative. Also, a usage

would typically be configured for the administrative card to accumulate bad PIN tries on

the Usages Management window.

Before entering an administrative card record, you must configure the on-us card prefix to

be used to recognize the administrative card number.

Accounts

Accounts, in the context of the BASE24-eps configuration, typically refer to the

accounts

tied to a card rather than to the card itself. Accounts basically represent the underlying

card-issuer institutional accounts to which a card has access, such as the cardholder’s

checking, savings, and credit accounts.

(31)

The association, or tying, of accounts to cards within BASE24-eps is very flexible. A card

can have single account tied to it, it can have up to 80 different accounts tied to it of varying

types, or it can have no accounts tied to it at all.

Accounts are set up on the Accounts tab of the Card Management window. Account balance

information is accessed using the Positive Balance Management window.

The reason for associating accounts with cards is that while transactions are initiated using

cards, transactions also typically involve or affect different types of accounts (e.g., withdrawal

from savings, a purchase on a credit account, or a transfer from savings to checking).

By associating one or more accounts with cards, your authorization scripts can involve

specific account information in authorizing transactions initiated with the card.The following

are typical purposes for which account information is used.

Verifying Cardholders Have Access to an Appropriate Account

The presence of accounts can enable your authorization scripts to determine whether a

cardholder has access to the type of account(s) needed for a particular transaction. Every

account defined to BASE24-eps has a type and status associated with it. Thus, if a transaction is attempted on a card that does not have access to an account of the required

type and status, the transaction can be denied. For example, on an attempted withdrawal

from savings, authorization scripts can check for the presence of an open savings account

associated with the card and deny the transaction if one is not found.

Enabling Cardholders to Access and Select From Multiple

Accounts

Associating multiple accounts with a card can enable a card to transact business on different—and sometimes many different—accounts. A straightforward example might be

setting up a checking and credit account for the card to be used for debit and credit transactions. A more involved example might be used in processing environments where

the transaction-originating devices support multiple account selection—also know as Open

Account Relationships (AOR). In these cases, BASE24-eps can be configured to return

all of a cardholder’s defined accounts to the transaction-originating device to allow the

cardholder to choose the account to be used for the transaction.

(32)

The latter approach might be useful, if for example, a cardholder was set up to make certain

types of purchases for a number of clients. In this case, each client might establish his or

her own account and each of those accounts would be associated with the card. Then, for

transactions on the card—assuming the originating device supports it—the accounts would

be passed back to allow the cardholder to choose the account for making the purchase.

Verifying Cardholders Have Sufficient Funds Available on Their

Accounts

Beyond simply associating accounts with the card, BASE24-eps also supports the capability

of maintaining balance and usage information for each of these accounts—as well as other

account-level activity information. This is supported through the Positive Balance data

source, which enables authorization processing to take balance information into consideration when evaluating a transaction for approval. In this case, once the account

is chosen for a transaction, the authorization scripts can take additional steps—using the

Positive Balance data source and account balance usages—to determine whether sufficient

funds are available to allow the transaction.

Identifying Accounts to BASE24-eps

Accounts are identified to BASE24-eps using several identifiers that are important to understand. These identifiers are used in both the Card record and the Positive Balance

records to identify an account.

Institution ID

The institution ID is the identifier of the institution that owns the account. This institution

ID must match the institution ID of the card with which the account is associated.

Account Number

The account number is the primary identifier for the account. The length of an account

number varies but is typically 11–16 digits.

You can view the account numbers of the accounts associated with a card in the Account

Number field on the Accounts tab of the the Card Management window (Customer

Management > Card).

Account Types

The account type is a code used to identify the type of account represented by the account

number.

Base24EPS TransactionProcessing

BASE24-eps Transaction

Processing

BASE24-eps™

Contents

Preface

Audience

Prerequisites

Additional Documentation

Software

Manual Summary

Publication Identification

BASE24-eps Transaction

Processing

BASE24-eps Transaction Originators

ATM Channels

Point-of-Sale Device Channels

Hosts

Interchanges

BASE24-eps Transaction Authorizers

BASE24-eps

Hosts

Interchanges

Issuers and Acquirers

Authorization Environments

Online Authorization

Offline Authorization

Online/Offline Authorization

Transactions and Transaction Messages

Primary Identifiers: Message Type Identifier (MTI) and

Processing

Code

Card-based Processors

Terminal Acquirers

Financial Switches

Card Issuers

Non-Card-Based Processors

Prefixes

What is a Prefix?

Local (On-Us) and Non-Local (Not-on-Us)

Prefixes

Local (On-Us) Prefixes

Non-Local (Not-on-Us)

BASE24-eps Prefix Processing

Setting Up On-Us Prefixes

Identifying a Prefix

Defining On-Us Prefix Routing Parameters

Setting Up Not-On-Us Prefixes

Payment Instruments, Cards, and

Accounts

Payment Instruments

Instrument Types

Defining Your Instrument Types

Cards

Configuring Cards

Associating Cards and Prefixes

Associating Accounts with Cards

How Cards are Identified in BASE24-eps

Primary Account Numbers (PANs)

Institution (Card Issuer)

Card Information Maintained by BASE24-eps

Customer ID

Depository Type

Card Types

PIN Information/PIN Verification Value (PVV)

Last PIN Change Date

Check Processing

Card Status

Effective Date

Expiration Date

Card Limits

Cardholder Address/Address Verification Settings

Accounts

Primary and Secondary Cards

Script Operators

Refreshing Card Information

The Last Time the Card Information Was Refreshed

Administrative Cards

Transactions Allowed

Prefix Considerations