VisaNet overview

Vital Processing Services

Vital Processing Services is a recognized leader in technology-based commerce enabling services. Vital solutions provide transaction processing capabilities that enable acquirers to strengthen their relationship with both traditional brick and mortar merchants and Web-based merchants operating in the virtual environment of Internet commerce. Vital Processing Services provides connectivity to VisaNet by its VirtualNet gateways. VirtualNet offers Internet Service Providers (ISP), Commerce Service Providers (CSP) and merchants two connectivity options:

• IP Gateway (using a leased-line connection)
• Secure Sockets Layer (SSL) Gateway

The two gateways that offer connectivity into the VisaNet transaction network are VirtualNet IP and VirtualNet SSL. As already noted, the VirtualNet IP Gateway provides connectivity via a private circuit. The private circuit is provided by the Internet Service Provider, Commerce Service Provider or the merchant. The Cassette for VisaNet does not provide additional security because transactions occur over a Virtual Private Network directly to VisaNet and not over the Internet.

The Vital VirtualNet SSL Gateway provides acquirers the ability to receive real-time credit card transactions from the Internet using the encryption capability of SSL technology. The service is provided on behalf of Vital by UUNET, using an SSL server that interfaces to the UUNET Transaction Network. The gateway uses HTTP and operates over SSL.

When communicating with the Vital host, the cassette enables merchants to use the E-Commerce credit card segment of the VisaNet's 6.0 Authorization and Data Capture services. Authorization messages are formatted in accordance with the EIS 1080 Version 6.0 specification. Data Capture messages are formatted in accordance with the EIS 1081 Version 6.0 specification.

FHMS

FHMS is a leading provider of transaction processing and bankcard acquiring services. FHMS provides processing services for major credit cards and debit cards. FHMS is a subsidiary of First Tennessee National Corporation (FTNC), which provides processing services for major card types, as well as most regional and national debit and EBT cards. FHMS also offers merchants similar connectivity options:

• IP Gateway (using a leased-line connection)
• SSL Gateway

Communication methods

The Cassette for VisaNet supports the use of either a leased-line or SSL gateway to communicate with backend host systems.

The communication method is determined by the account that is set up with the provider of processing services. Consideration of the type of communication method includes these factors:

• Cost. The cost of using SSL is typically less than that of a leased line.
• Transaction volume. If you expect to process a high volume of payment transactions, performance is normally better on a leased line.
• Availability. Leased-line communication is typically more reliable than communication over the Internet.

The type of backend host (Vital or FHMS) with which to communicate is specified for an account by the Account settings.

The cassette can be configured, on an account basis, to communicate with either Vital or FHMS. However, communications with the backend host can occur only one way--either by a leased line, or SSL. In other words, you cannot use the cassette, for example, to communicate with FHMS by both leased line and SSL.

VisaNet merchant registration

Before you can use the Cassette for VisaNet, you must ensure that the merchant has been registered to process VisaNet transactions. Merchant registration information is required by the cassette to process payment transactions. The following sections describe more about the registration process.

Registering when using Vital Processing Services

Vital does not directly perform merchant registration. Merchants must contact a processing bank that uses VisaNet as a processor. Merchants can contact their existing bank or local banks and ask for their merchant services department and then ask if they support VisaNet. The processing bank sets up the account and then works with Vital to complete the registration. If a merchant requires special test accounts, they should work with the processing bank to get that established. The output of the registration is a merchant profile. The merchant profile contains several values for use in processing VisaNet transactions. Values:

Acquirer BIN

Identifies the merchant's acquiring financial institution (a VisaNet member bank).

Agent Bank Number

Identifies the agent of the acquirer which signed the merchant. This value is provided to the merchant by the acquirer.

Agent Chain Number

Identifies a specific chain of an agent organization. Assigned by the merchant's bank or processor.

Store Number

A number assigned by the signing member, processor, or merchant to identify a specific merchant store within the VisaNet system.

Terminal Number

A number assigned by the signing member, processor, or merchant to identify a unique terminal within a merchant location.

Merchant Name

The merchant name is provided by the signing member or processor.

Merchant Number

Merchant's account number with acquirer (assigned by the merchant's bank or processor).

Merchant Category Code

The merchant industry classification.

Registering when using FHMS

The registration process and outputs of the registration process are the same as that for Vital.

American Express CID support

American Express CID is a card verification tool designed to reduce fraud losses, typically on transactions when the card is not available. The CID is a 3 or 4 digit value (following the credit card account number) on the signature line of the credit card.

A merchant does not automatically get American Express CID verification by setting the $CARDVERIFYCODE keyword. In addition to setting this parameter (described in AcceptPayment), the acquiring bank must enable CID verification, for the merchant, by contacting American Express merchant services.

Merchant identification

The reporting structure in FHMS is different than that of Vital Processing Services. Vital assigns a single merchant number to a merchant, whereas FHMS can assign more than one merchant ID to a merchant. FHMS provides transaction reports to the merchant based on these merchant IDs.

In WebSphere Commerce, a store maps a single WebSphere Commerce Payments merchant to multiple FHMS merchant IDs (to associate multiple departments, for example, to a single store). If you are using the FHMS backend host and have more than one FHMS merchant ID and need to see transaction reports based on these IDs, you can specify a unique FHMS merchant ID for every account you create for the merchant.

Cassette features

The following sections describe special features of the Cassette for VisaNet:

• Address Verification Service support
• Purchasing card support
• Sensitive data protection

Address Verification Service

The Address Verification Service (AVS) is a payment card fraud prevention tool that enables mail order and electronic commerce merchants to verify U.S. cardholder shipping addresses against the address that the payment card issuer has on file for the consumer.

The cardholder's billing address, specifically street address and zip code, are sent in the electronic authorization request message to the issuer. The issuer compares the street address and zip code to those it has on file and returns an AVS response code to advise you of the comparison status. This information enables decision making that limits risks when shipping merchandise. Risk reduction for the financial institution can result in reduced transaction fees for the merchant.

The WebSphere Commerce Payments Cassette for VisaNet allows the use of this tool by its merchants. It is up to the merchant to decide what risks are allowable if AVS data does not compare favorably.

If you are interested in additional information regarding AVS and merchant chargeback liabilities, contact your acquiring financial institution. See the Vital Processing Services, Authorization Record Formats EIS 1080 Version 6.0 specification, and Address Verification Service (AVS) result codes for more information about possible AVS codes.

Purchasing cards

Purchase transactions can also involve the processing of purchasing card data. Purchasing cards (or procurement cards) are credit cards that a business can offer its departments or employees to allow them to buy business-related items. Typically a business will make arrangements with the card issuer to govern the purchases that cardholders can make. For example, maximum limits can be imposed and the cards can be restricted to allow purchases of certain items only (for example, only stationery goods). Purchasing cards can also have pre-programmed limits for purchase amounts. Purchase-related details (such as the tax amount and merchant category code) and the details of the items being ordered by a purchasing card are passed to the financial network so that the authorization of the purchase can be influenced by the details of the goods being ordered. Purchasing cards are a form of payment commonly used by many businesses because it streamlines the corporate purchasing process.

For example, typically, companies use a purchase order process to receive goods or services. The process typically works like this:

1. An employee requests/creates a purchase order (PO), including a list of goods or services to be purchased.
2. The manager approves the PO.
3. The purchasing department sends the PO to the supplier and files a copy.
4. The receiving department receives the goods and invoice from the supplier.
5. The employee receives goods from receiving department.
6. Accounts Payable receives the invoice from the supplier.
7. Accounts Payable matches the PO to the invoice and then approves the payment.
8. Accounts Payable makes the payment to the supplier.
9. Accounts Payable reconciles the purchase activity.

The use of purchasing cards can remove several of these steps. For example:

1. Employee makes purchase directly from Supplier using Purchasing Card (and logs details of transaction if required by company policy).
2. The employee receives a monthly purchasing card statement, verifies the charges, and send it on to accounts payable.
3. Accounts Payable reviews and approves the statement. The statement may include general purchase information (such as purchase date, amount, commodity code, merchant/supplier info, tax info). It may also include details about line items associated with the purchase (such as the item quantity, unit of measure, part numbers, description, unit cost, tax info). This purchase information is known in the e-commerce industry as Level I, Level II, and Level III information.

The benefits of using purchasing cards include:

• Accounts Payable costs are reduced by not requiring costly EDI implementation.
• Bills are consolidated into a single corporate purchasing card billing statement.
• Check processing is eliminated.
• Suppliers can receive immediate payment and potentially qualify for the low interchange rates by meeting card association requirements for collecting enhanced data.
• Purchases can be paid for electronically and the overall purchase process is more automated.
• Purchasing cards can contain additional authorization controls such as limits for purchase amounts, and where and what types of purchases can be made.

Levels of purchasing card data supported

The Cassette for VisaNet supports two levels of purchasing card information as follows:

Level I data

The standard commercial transaction data for the purchase.

Level II data

Additional data to Level I data about each purchase which includes: sales/local tax and customer reference number.

Purchasing card data processing

Purchasing card data can be passed in on the AcceptPayment and Deposit commands only under the following circumstances:

• When purchasing card data is passed in on the AcceptPayment command, the $NUMPAYMENTS protocol data must either not be specified, or, if specified, must be 1.
• Purchasing card data is then sent to the backend processor during the batch settlement.
• If purchasing card data is sent on the Deposit command, then it overrides any purchasing card data sent on the AcceptPayment command.

Sensitive data protection

As an option, you can prevent sensitive financial data such as credit card numbers and expiry dates from being returned in query results when users enter query commands. A JVM system parameter called wpm.MinSensitiveAccessRole can be specified to define the minimum access role a user must have to view sensitive data returned in query command results. The parameter is defined by using the Configuration Manager by setting the Minimum Access Role field for the Payments instance to a value of clerk, supervisor, madmin (Merchant Administrator), psadmin (Payments Administrator), or none (no one is allowed to view sensitive data).

When a user enters a query by using a query command, WebSphere Commerce Payments checks the user's role against the minimum role specified for the wpm.MinSensitiveAccessRole parameter and determines whether sensitive data should be returned in full view or masked out. The following table lists the data elements that are considered sensitive by the Cassette for VisaNet:

If the wpm.MinSensitiveAccessRole parameter is not specified, an access role of Clerk is assumed, which allows all users to see sensitive data. If the user's role matches or exceeds the role value, the actual values are displayed for the sensitive data.

WebSphere Commerce Payments roles

WebSphere Commerce Payments enforces roles such that each user is presented with a different view based on the user's role, for example, from the perspective of a Payments Administrator versus a Merchant Administrator. Within the merchant organization, WebSphere Commerce Payments enables the notion of different roles so that the merchant can monitor their own users. For example, a Clerk is restricted to operations such as approving an order, while a Merchant or Payments Administrator can modify a relationship with a financial institution.

When you create users within the Organization Administration Console, you must first assign those users a WebSphere Commerce role. Then the users will display in the Payments user interface where you can assign them a Payments roles. It is recommended that these roles be assigned to WebSphere Commerce users having the roles shown in Table :

For more information about WebSphere Commerce roles, refer to the Roles topic in the WebSphere Commerce Production online help.

Both Payments Administrators and Merchant Administrators can manage WebSphere Commerce Payments. Supervisors and Clerks are financial roles. While they do not administer WebSphere Commerce Payments, they do manage the payment-processing functions. The following table describes the responsibilities for each Payments role: