E-xact Knowledge Base

Merchant Guide

Click and scroll to view topics contained in our Merchant Guide:

Preparing for Transaction Processing

Business Requirements (Getting Started)

Before starting development of your transaction processing solution, you need to have a clear understanding of your business objectives and business requirements in order to successfully deploy the E-xact Plug-Ins. This guide is intended to help you deploy E-xact’s services through the use of the Plug-Ins. Before launching the E-xact Plug-In services you will need to:

  • Establish merchant accounts through your financial institution for the card types you wish to process.
  • Acquire a 128-bit Secure Socket Layer (SSL) Server Certificate if you plan to use a web online storefront
  • Integrate the E-xact Web Service with your website to enable gateway connectivity between your payment interface and E-xact’s servers.

Key Players in Payment Processing

Merchant – Provides the point-of-sale payment solution in order to sell their product or services to a Customer.

Customer/Consumer – The credit cardholder placing a purchase via the merchant’s payment solution. The cardholder receives their credit card from an Issuer.

Issuer/Issuing bank – The card company (Visa, MasterCard etc) or bank that issues the credit card to a cardholder.

Acquirer/Merchant bank – The financial institution that provides the merchant with the necessary merchant accounts for accepting credit card payments (e.g. Visa, MasterCard). The Acquirer processes authorizations and settlements to the merchant’s accounts and handles the financial exchanges between the merchant and customer’s credit card issuer bank.

Payment Gateway Provider/CSP/third-party processor – This is E-xact. We provide the gateway technology to process payments via the Internet. We are the bridge between the merchant’s Point-Of-Sale and the acquirer’s financial processing system.

Processor/processing network/bank processor – The “clearing house” provider that processes the credit card transactions and settles funds to the acquirer/merchant. The processor works as the central “clearing house” for the acquirer and conducts processing between the merchant site and the acquirer. The processor is connected to the merchant via the Payment Gateway Provider – E-xact Transactions.

The interaction between several key players in online transaction processing is depicted in Diagrams 2.1 and 2.2.

merch1.png
Diagram 2.1 Payment Workflow
merch2.png
Diagram 2.2 Payment Processing

Merchant Accounts

As a merchant business, you will need merchant accounts in order to accept payments. The type of account  will depend on the device and method by which you accept credit card data. Bank discount rates and possible transaction charges are separate from E-xact’s prices. Separate merchant accounts must be obtained for Card Present and Card-Not-Present transactions. E-xact’s technology can process for both Card-Not-Present and Card Present environments.

Card-Not-Present

Card-Not-Present means that the merchant does not handle the card physically or receive the cardholder’s signature. Two variations are:

- Internet Merchant Accounts – specialized for merchants setting up e-commerce and online web businesses.

- MO/TO (mail order/telephone order) – for merchants accepting card numbers by phone or fax. Commonly used by call centers.

Because of the nature of Internet Merchant Accounts there is a higher risk of charge-backs and fraud. Familiarizing yourself with these concerns will help you address the banks’ requirements for your business. When Internet processing is being used, 3-D Secure will help to reduce fraud and help to shift liability to the cardholder or the cardholder’s bank.

Card Present

For businesses that handle the credit card physically and receive the cardholder’s signature. Deployed primarily in brick-and-mortar outlets, usually a card-swipe device is utilized.

Merchant Bank Relationships

E-xact is bank “agnostic” and can process payments for merchant accounts from the majority of Canadian and US banks. Call E-xact’s Sales department for further information. Canadian merchants can set up a merchant account through a credit card merchant account service provider (such as Global Payments, Moneris, Chase Paymentech, etc.) who would be able to provide accounts for multiple credit card brands.

To setup Canadian Dollar non-bank (private label) cards such as American Express, you will need to apply with these companies directly through their Canadian branch.

US Dollar merchant accounts from Canadian Banks

US dollar (USD) merchant accounts are available for Visa, MasterCard, and select Private Label Cards from Canadian merchant service providers.

For American Merchants

Banks in the United States issue Visa and MasterCard under one merchant ID. E-xact’s gateway can process transactions with approximately 80% of the American Banks through our bank processor relationships. Contact us to see if your bank is one of them. When processing, non-bank cards are associated with your Visa-MasterCard Merchant ID.

Credit Cards Supported

Cardholders will be charged in whatever currency your merchant account is in. A conversion rate is then applied to the cardholder's purchase by their bank. The ticket price will appear with the converted local currency on a foreign cardholder’s bill. The credit card exchange rate may be different from the standard daily currency exchange rates, and for a purchase versus a refund.

Multiple Currencies

Currently, E-xact has bank network connections that handle US dollar and Canadian dollar accounts. Our system and software is capable of handling other currencies provided they are supported by the bank processing networks.

Bank Processing Networks

E-xact connects with various bank-processing networks. Through these bank networks, E-xact establishes the connectivity needed for you to properly process, capture, and settle your funds. E-xact is currently certified with the following bank processing networks

- Chase Paymentech (Canada and USA)
- Telus (formerly Emergis) (Canada)
- Moneris (Canada)
- TSYS Acquiring Solutions (Formerly Vital Processing Systems) (USA)

Funds Settlement

The Bank Processors that E-xact operates with “close out” the transactions and send the settlement files to your bank(s). Settlement times vary according to the bank network and currency type. Usually Visa and MasterCard settle within 24-48 hours. Non-bank cards may take longer depending on each merchant contract.

E-xact can synchronize Report cut-off times with the cut-off times of your bank(s), in order to match our online reports with those of your bank(s). E-xact’s default reporting cut-off time is 12 Midnight. Please check with your bank regarding their cut-off time.

Transaction Types Available

E-xact’s services can be configured and set up for many transaction types. The transaction types available are listed below:

Standard Transactions

Purchase - sends through sale and request for funds to be charged to cardholder’s credit card.

Pre-Authorization - sends through a request for funds to be “reserved” on the cardholder’s credit card. A standard pre-authorization is reserved for 2-5 days. Reservation times are determined by cardholder’s bank.

Pre-Authorization Completion - sends through a request for reserved funds from a specific pre-authorization to be charged to cardholder. An authorization number is associated between a pre-auth and pre-auth completion.

Refund - sends through a request for funds to be returned to the cardholder.

Void - sends through a void to prevent the settlement of the funds. Voids must be processed on the same day as the authorization.

Authorization Only - a type of transaction that is specific to Telus. This is the same as a
pre-authorization, but it does not apply 15% to the dollar amount for tip allocation, as with regular Pre-Authorizations.

Forced Post – completes a transaction that was not authorized on E-xact’s system i.e. Voice Authorizations or other sources. The Authorization number provided by the Card Company must be contained in the Forced Post Transaction. You will need permissions and procedural outlines from E-xact prior to use.

Tagged Transactions

Tagged transactions enable a transaction to be processed without having to send a credit card number. Tags and how they function are outlined below and in E-xact’s Technical Users Guide.

Recurring Seed – sends through a request to allow a merchant to pre-authorize a credit card. The data produced by the Pre-Authorization creates a seed. The seed may then be used to send many Tagged Purchase transactions or one Tagged Completion.

Recurring Seed Purchase - Applies a purchase against the credit card provided. Funds for the specified amount are settled to the merchant’s account at the end of the day. Tagged Refunds equal to the amount of the original transaction’s amount can be applied against it using the returned TAG. Multiple Tagged Authorizations or Tagged Purchases may be conducted from one Recurring Seed Purchase transaction.

Tagged Purchase – sends through a request for funds to be charged to cardholder that is associated with a previous Recurring Seed transaction. Multiple Tagged Purchases can be conducted from one Recurring Seed Transaction.

Tagged Pre-Authorization – Applies an authorization against the credit card number provided in a previous Recurring Seed or Recurring Seed Purchase transaction. In order to identify the previous transaction, the TAG returned in that transaction must be sent with the Tagged Authorization. The Credit Card Number and the Expiry Date must not be sent. An unlimited number of Tagged Authorizations may be applied to a specific Tag.

Tagged Completion – sends through a request for reserved funds to be charged to a cardholder. This type of transaction is associated with a previously processed Pre-Authorization or Recurring Seed transaction. Only one Tagged Completion is permitted per Recurring Seed or Pre-Authorization.

Tagged Refund – sends through a request for funds to be returned to a cardholder. This type of transaction is associated with a previously processed Purchase or Completion.

Debit Transactions

Debit Purchase – sends through sale and request for funds to be moved from cardholder’s bank account

Debit Refund – sends through a request for funds to be returned to cardholder’s bank account. Refunds should not be made an automated function or available to cardholders.

Debit Online Tagged Refund – sends through a request for funds to be returned to cardholder’s bank account based on previous Debit Purchase. Tagged online debit refunds must been completed within approximately 5 days or original Debit Purchase after which the PAN value will expire.

Security (Encryption & SSL)

Encryption

E-xact’s Plug-In connects to the transaction-processing networks via an IP socket connection. All data passing through the connection is encrypted. E-xact has firewall protection for its servers.

SSL Requirements

Merchants who deploy web storefronts, or web-based orders using E-xact solutions are required to enable a Secure Socket Layer (SSL), with 128 bit encryption, for their web server. This is optional when using the EBB solution. E-xact does not provide SSL for your website. You will need to enable a Secure Socket Layer (SSL), with 128-bit encryption, for your web server. SSL appears as https:// in a web browser. Check with your Web Host or developer to see if they have SSL services. Otherwise, Digital Certificates can be purchased from Certificate Authorities. Some resources for SSL:

- Entrust (www.entrust.net)
- Thawte (www.thawte.com)
- Verisign (www.verisign.com/products/site/secure/index.html)

E-xact Plug-Ins and Software

The E-xact Plug-Ins use IP Socket connections and banking networks to implement real-time transaction processing for merchant businesses. Once integrated into the merchant’s payment processing environment, the Plug-Ins create an individual payment gateway. The Plug-In software is available in various programming languages, and is most often used to integrate credit card point-of-sale (POS) functionality into web storefronts and other e-commerce solutions. It can also be implemented into recurring billing, reservation systems, IVR telephony, physical POS terminals, and other applications.

Card-Present Card Swipe Capabilities

E-xact’s software can be incorporated into card-present technologies. Magnetic stripe card-reader hardware for PCs can be adapted to port into E-xact’s Plug-Ins. See E-xact’s Technical Users Guide for further details.

Who sets up the Plug-In software?

The merchant is responsible for the integration of the E-xact Plug-Ins into the merchant’s payment processing environment (e.g. website, reservation system etc).

Each Plug-In version has a different installation procedure. An advanced level of programming experience is required for the successful integration of most of the Plug-In software. Only a moderate level of programming experience is need for the successful integration of the Redirect solutions.

E-xact Plug-In software is available for free download and evaluation at www.e-xact.com.

Plug-In Versions

Web Service Version

  • Uses RPC/Encoded technology
  • Requires no software installation (Virtual Point-Of-Sale permits users to manually enter specific transactions through a web browser)

Client Libraries

3-D Secure

Merchants using the E-xact Plug-Ins benefit from added fraud-protection from 3-D Secure (e.g. Verified by Visa). 3-D Secure is a program that requires cardholders to authenticate themselves to their issuing bank, thus helping to reduce fraudulent transactions, and can in turn reduce charge backs to merchants under some circumstances.

This is provided by E-xact as a Thin Client.

3-D Secure Transaction Flow

The following steps illustrate the flow for processing a transaction using 3-D Secure.

1. Customer clicks pay on their website.

2. The 3-D Secure Plug-In installed at the merchant’s site checks the 3-D Secure Merchant Service and Visa’s Directory Server to see if the credit card issuer and card are enrolled in 3-D Secure.

3. The 3-D Secure Plug-In continues handling the enrollment check.

- If the card is not enrolled, the merchant’s 3-D Secure Plug-In hands off the transaction to the payment Plug-In (step 4).

- If the card is enrolled in 3-D Secure, the merchant Plug-In will initiate a dialog between the cardholder’s Internet browser and their card-issuing bank. The cardholder is then required to enter a password that they have previously set up with their issuer as part of their enrollment in the 3-D Secure program.

4. The 3-D Secure Plug-In hands off the transaction to the payment Plug-In.

- If the card was not enrolled or the authentication password was entered correctly, the merchant’s Plug-In is advised to proceed with the transaction. This results in increased charge back protection. (See the Bank Related Issues section below for more information.)

- If the cardholder fails authentication, the merchant should not proceed with processing the transaction.

3-D Secure Set-up and Integration

In order to implement the 3-D Secure functionality, E-xact provides the thin client integration software.

E-xact Account Information

E-xact Test Account

Individuals who install E-xact’s software will have access to E-xact’s testing account, called E-xact ConnectionShop. The test shop connects to our test servers only. All the software includes sample scripts and is pre-configured to E-xact’s ConnectionShop. E-xact’s ConnectionShop is open to the general public and allows your developer to simulate the interaction between your software and/or server and our transactional servers. Further details on testing are to be found in the E-xact Technical Users Guide included with the software.

Individual Test Account (optional)

You can establish an Individual Test Account once you have registered for E-xact’s services. An individual Test Account is different from a ConnectionShop account in that you receive a separate demo/test account area contained within your E-xact Account to view test records. Also, if you plan to test periodically, after your solution has launched, an individual test account is a safe way to test any future changes you may work into your solution. To set up an Individual Test Account, contact E-xact’s Technical Support.

Realtime Payment Manager (RPM)

Each merchant receives access to RPM, a real-time web-based back-office application that logs the transactions conducted through the Virtual POS, POS Batch, WSP Payment Pages or the Web Service. Searches and refunds can be conducted. RPM does not require any software installation, but does require User IDs for access.

User Logins

User Logins are needed o access the RPM at pos.e-xact.com. User Logins consist of Login Name and Password. Users will encounter two sets of User Logins:

Test Login: Provides access to the E-xact ConnectionShop in the test system. If you downloaded the Plug-In software, you will have received a User Login by email. Developers are the primary users of Test Logins.

Production Account User Login: Provides access to the merchant’s E-xact account in the production system. These User Logins are created and provided by E-xact upon your account setup with E-xact.

E-xact Production Account

A Production Account connects live to the banking networks and transfers real transaction information and real money through to the bank processors, cardholder’s accounts and merchant’s bank accounts. An E-xact Account Profile consists of:

- Merchant Address and Contact information (including URL, email contacts, phone numbers)
- User Logins
- Plug-In Terminal IDs (for card types and merchant account data)

E-xact Gateway Terminal Credentials

E-xact’s Gateway Servers identify a merchant’s accounts (test or production) by assigning virtual Gateway Terminals to them. A Terminal is identified by Gateway Terminal Credentials. The Terminal credentials establish the interaction between the E-xact software and our payment
servers.

All Terminal Credentials consist of:
- Gateway Terminal ID (9 character identifier)
- Password (variable length)

There are a series of Gateway Terminal Credentials you and your developer will encounter:

- Test Account Credentials (for test settings). These credentials are contained within the E-xact Plug-In.

- Production Account Credentials (for production settings). The terminal credentials are provided by E-xact at the time of the account setup with E-xact.

When the code is ready to be moved from test mode to production mode, the Test Account Credentials need to be replaced with the E-xact Production Credentials. Please note that without Gateway Terminal Credentials, you will not be able to enable any type of Plug-In account (test or production).

Setting up Multiple Terminals & Currencies

A merchant may receive more than one Production Gateway Terminal ID. They are most likely to receive more than one Terminal ID if they:

- Have merchant accounts in different currencies
- Requested extra virtual Terminals assigned to identify separate payment revenue streams.

More details on setting up multiple Terminals and currencies are included in the E-xact Technical
Users Guide.

Recommended Testing Procedure

E-xact suggests the following testing procedure for your developers to follow prior to launching
your solution:

With Test Account Credentials (Test Environment)
- Connectivity testing
- Transactional testing
- Reconciliation of the records in online reports (Realtime Payment Manager and the Merchant’s database)

With Production Account Credentials (Production Environment)
- Connectivity testing
- Transactional testing
- Reconciliation of the records in online reports (RPM and the Merchant’s database)
- Funds Settlement (checking the bank statements)

For a more detailed outline of testing procedures, please consult the E-xact Technical Users Guide.

E-xact Software Features

E-xact’s Plug-In provides flexibility to the merchant and developer regarding functionality and audit control of transactional data. Many of the features listed below are optional. There are other Plug-In functions available that are not listed in this Guide. Please refer to the E-xact Technical Users Guide or the E-xact Programming Reference Guide for programming details on properties, methods and functions. E-xact’s Redirect solutions and EPOS Applications have more limited data storage and customization available.

Customer Transaction Record (CTR) Display

Most financial institutions require that the CTR be displayed to the cardholder after all transactions. E-xact Plug-In offers a pre-configured CTR for all transactions. The CTR displays bank information, cardholder name, merchant name and address and status of the transaction (approved or declined) to the cardholder and merchant. The format of the CTR is fixed font, plain text. The CTR is available in both English and French language versions.

If the standard format does not meet with the graphical requirements of the merchant’s web page and/or the merchant’s financial institution, the developer can build a customized CTR using existing Plug-In properties (see the E-xact Technical Users Guide or the E-xact Programming Reference Guide).

Data Tracking

Much of the transactional data displayed within E-xact’s Realtime Payment Manager (RPM) can be stored in your company’s database for quality assurance and data mining. Many of the information fields used for reporting are available for storage. The CTR properties can be stored in your company’s database allowing for transactions to be searched and archived.

The properties are:

- Account Information
- Type of Transaction
- Card Type, Amount & Currency
- Cardholder Name
- Date/Time
- Reference #, Customer Ref# (determined by merchant)
- Authorization # (from bank)
- “Approved” or “Declined” and Bank Processor Response Code
- SMWP Response Code
- CAVV
- CAVV Result
- Electronic Commerce Indicator
- Secure AuthRequired
- Secure AuthResult

Please refer to the E-xact Technical Users Guide for further details on CTR Properties.

Transaction Reference Numbers

You can include a Reference Number and Customer Reference Number along with the other transaction details sent to E-xact servers. These references are optional and interact with the E-xact system only. Refer to the E-xact Technical Users Guide for implementation and application of these reference fields. Please note these Reference numbers are separate from the Bank Reference # that appears on the CTR.

Reference_No is a merchant-defined transactional property. It can be alphanumeric and up to 20 characters long. This appears on the CTR.

Customer_Ref is a merchant-defined transactional property. It can be alphanumeric and up to 20 characters long.

Response Codes

Both the bank networks and E-xact generate Response Codes for each 3-D Secure authentication and transaction processed. If there is a decline or a failure in transmission, these Response Codes give further information on the transaction. Both the 3-D Secure authentication and transaction Response Codes are detailed in the E-xact Technical Users Guide.

Tagged Transactions

Tagged Transactions can be used for recurring billing and for referencing credit card numbers without having to store the card numbers in the merchant’s database (the use of tags can significantly lower the security risk to the merchant and cardholder). To initiate tags for recurring billing, a Recurring Seed transaction is first executed for a nominal dollar amount. E-xact’s system produces two values, Tag and Approval Number, and associates them with the Recurring Seed.

This type of transaction is similar to a Pre-Authorization. The two values need to be stored (by the merchant) and referenced when the merchant wishes to process a Tagged Purchase or Tagged Completion. Multiple transactions can be processed using one Recurring Seed. For more information on transaction types and the use of tags, see the E-xact Technical Users Guide.

Card Swipe Track Data

E-xact supports the transmission of Track 1 and Track 2 data to support card present transactions submitted by a card swipe device. Card readers can be attached to the PC and interfaced with the Plug-In and EPOSLite. See the E-xact Technical Users Guide for further details.

Cardholder Verification Systems

Validating a cardholder’s identity helps protect against fraudulent transactions. Three methods exist for validating a cardholder’s identity when processing card not present (MOTO and e-commerce) transactions. US based merchants who do not utilize AVS, CVD/CVV2 or 3-D Secure verification system may be subject to additional fees imposed by their acquiring institution or bank.

3-D Secure

The generic system name is labeled Verified by Visa (VbV) by Visa and SecureCode by MasterCard. 3-D Secure is supported on US and Canadian merchant accounts processing transactions for Visa and MasterCard credit cards issued internationally. The merchant account support varies from bank to bank. The client card participation in the program also varies from bank to bank. The 3-D Secure program enables a liability shift away from the Merchant for charge back situations. Such liability shift is not offered by AVS or CVV2.

Performing a 3-D Secure card enrollment and authentication check produces Authentication Request and Authentication Result codes. The combination of those codes will determine whether a transaction should be processed or not and whether liability shift, in the case of fraud, would shift away from the Merchant or not.

The 3-D Secure system is called before processing each transaction. First, the cardholder’s enrollment in the program is checked. This is done by having the Merchant’s server connect to a 3-D Secure MerchantService server. If the cardholder is not enrolled, the transaction is processed normally. No liability shift will occur. If the cardholder is enrolled, they are redirected in a pop-up window to an Access Control Server (ACS) that is run by the cardholder’s bank. The cardholder is then requested enter a PIN number they have set up for their card. The cardholder’s identity is authenticated and sent back the Merchant’s server. Based on the authentication result, the Merchant’s system chooses to proceed with processing the transaction or not. Liability shift away from the Merchant may also occur.

Cardholder Verification Value (CVV2, CVC2 and CID)

Another new method of cardholder verification uses the Card Verification Value (CVV). The generic system name is labeled Card Verification Value 2 (CVV2) by Visa, Card Validation Code 2 (CVC2) by MasterCard and Cardholder Identification Code (CID) by American Express.

Card Verification information is not contained in the magnetic stripe information nor does it appear on sales receipts. It is an additional 3 to 4 character value, printed on the front or back of Visa, MasterCard, and American Express cards. To use Card Verification, the 3 to 4 character value along with the other transactional information at the time of processing the transaction. If the 3 to 4 character value is not authenticated by the cardholder’s bank, the transaction will be declined. If the 3 to 4 character value is authenticated, the transaction will be processed normally.

Address Verification System

The oldest method of cardholder verification is the Address Verification System (AVS). AVS is now supported on US and CAD merchant accounts processing transaction for North American and some International cardholders.

When setting up AVS through E-xact’s Plug-In you can choose to setup your system to have a positive or negative match. AVS works on a system of inclusion or exclusion. The AVS result should be treated as an indicator of whether or not to accept the authorization that was provided. This determination is to be made by the merchant. You either choose to approve transactions with specific AVS Codes or reject transactions with specific AVS Codes. Most clients like to approve all transactions except in case of N (which equals No match), therefore not limiting international cardholders.

E-xact can also setup AVS filtering through our gateway. For more details, see AVS Filter in the E-xact Gateway Server Options section. Further details on setting up AVS and AVS filtering are in E-xact’s Technical Users Guide.

AVS Table

AVS Code AVS Definition Explanation
X Exact match, 9 digit zip

Street Address, and 9 digit ZIP Code match
Y Exact match, 5 digit zip

Street Address, and 5 digit ZIP Code match
A Partial Match

Street address matches, ZIP Code does not
W Partial Match ZIP Code matches, Street address does not
Z Partial Match 5-digit ZIP match only
N No Match No address or ZIP matches.
U Unavailable

Address information is unavailable for that account
number, or the card issuer does not support AVS
G Service Not supported Non-US. Issuer does not participate
R Retry Issuer system unavailable, retry later
E Not a mail/phone order

S Service not supported

E-xact Gateway Server Options

E-xact’s Gateway Server Options consist of various settings that can be configured on each E-xact account. Their primary purpose is to reduce human error and fraud. Each account is set up with a default of “Unrestricted” for all of these options. The Unrestricted status can only be modified by direct request to E-xact Customer Service See E-xact Technical Users Guide for further details on setting up these options.

Duplicate Checking

Duplicate checking will monitor for duplicate transactions within a specified time frame. If any duplicates are found, they will be denied by E-xact’s system.

Refund Restrictions

Refund Restrictions will limit the number of refunds and the total dollar amount that can be refunded on a given day. The refund count and dollar amount is limited, and if exceeded, the transactions will be denied by E-xact’s system.

Velocity Controls

Velocity Controls place limits on the total purchase dollar amount by credit card number or by merchant account over a specified period of time. The purpose of velocity controls is to potentially lessen the opportunity for a cardholder to perpetrate fraudulent transactions.

AVS Filter

The AVS Filter works on negative matching. AVS codes are specified, and then set up on the AVS Filter. If a transaction meets the AVS criteria it is rejected. The AVS Filter can be set up in lieu of Plug-In based AVS.

Credit Card Number Filter

Merchants can request that we enter a fraudulent credit card number into the E-xact database so that all E-xact customers are protected from the fraudulent card number. The card number needs to be verified as fraudulent by the credit card issuer prior to filtering. Further details available upon request to E-xact Customer Service.

Please Note: E-xact recommends that you save the E-xact Plug-In Gateway Response Codes (see the E-xact Technical Users Guide) that are returned from the E-xact system, in case you wish to investigate transactions that have been affected by the Gateway Server Options.

Using the E-xact Realtime Payment Manager (RPM)

Each merchant receives access to RPM, a real-time, web-based back-office product that audits your E-xact transactions. Site functionality includes:

- Activity – for viewing all transactional activities through your E-xact account. It includes approved and failed transactions.

- Deposits – for viewing all approved transactions sent for settlement within a 24-hour period.

- Search – a search engine for all transactions and details on individual transactions. Data is updated in real-time. Refunds can be conducted from this area, from the associated purchase/completion.

- POS – virtual Point-Of-Sale for manually entering sales.

- Administration – User and account administration page (Merchant Admins only, Invoices are also available in this section.

RPM is SSL secured, and requires a User Login (with User ID and Password).

Logging On to RPM:

1) Go to https://pos.e-xact.com.

2) Enter your User Login and Password and press Login (Please note – upon your first login, you will be prompted to change your password to a new 8 digit alphanumeric password. Once reset, you will be prompted to change your password every 90-days)

3) Once logged on you will be on the Home Page.

4) Familiarize yourself with the various screens available for viewing and interaction.

User-Level Definitions

Users can have different access levels. Some of the more common access levels include:

- Merchant Administrator - access to change account address, view bank terminal information, edit E-xact Production Gateway Password, and can add and edit other Users in your account.

- Read Only – access to screens except POS. Also no transactional functions in Search

- Merchant – access to all screens. Can use POS and transactional functions through Search

Merchant users can be restricted to perform a limited combination of transaction types. For example, Purchases only, Purchases and Pre-authorizations only, Refunds only, etc.

Email Notifications

Individuals can receive different email reports. These are:

- Alert – sends notification of possible scheduled or unscheduled interruptions in service.

- Daily – daily deposit report (of total deposits on record through E-xact). This selection automatically includes the monthly deposit report.

- Monthly – the monthly deposit report.

Options also include a combination of reports, i.e. Alert/Daily and Alert/Monthly.

Daily email reports provide breakdowns of terminal deposits for a 24-hour period.  The Daily report appears as follows:

merch5.png

Making Changes to Users

If you need to change your login and/or password, add a new user or remove a current user please contact your Merchant Administrator.

Bank Related Issues

Cardholder’s statements: Changing what appears on it

E-xact’s system does not affect cardholder statement information for Canadian banks. What appears on the cardholder’s credit card statement is determined by the acquiring bank, and in rare cases bank processor. To change what appears on a cardholder’s statement, please contact your bank agent or service department.

For US clients, E-xact has more control on what appears on cardholder statements. The processor, TSYS Solutions, has the following formula for cardholder statements:

- For non e-commerce accounts what appears is: name, city
- For e-commerce accounts what appears is: name, phone number.

Please provide E-xact with the business name as it should appear on the cardholder statement. It is important that the business information E-xact, the processor, and the bank have on record match. E-xact’s CTR information is drawn from E-xact’s database, so if you do make a change to your business name, inform E-xact so that we can update our information. We will need written verification of any company name change.

Merchant Category Code

Banks assign a merchant category code to describe your type of business. If your business description on a cardholder’s statement is not accurate, please contact your bank to have your record modified.

Call/Voice Authorizations

Depending on what Bank processor you are using, voice authorizations can be processed through E-xact’s system. There are different transaction types associated with processing voice-authorized transaction. Please contact E-xact for the access and information needed to process voice authorization transactions.

Refund or Purchase Limits

If you have high dollar amount refunds, or ticket items that you are not able to process through E-xact, it is possible that you may have restrictions set on your merchant account(s). Please contact your bank agent to investigate. Refund limits are set for each merchant account by the bank. However, if you have set refund restrictions on E-xact’s Gateway Servers, then you may have two parties limiting transaction volumes on your account.

Charge Backs

E-xact is not involved in charge-backs. Charge-backs are charged against your merchant account if a cardholder contests a charge made to their credit card as either being mistaken or fraudulent and requests that it be charged back to the merchant. Banks monitor charge-back activities, expecting charge-backs to remain in the 1% range. If the percentage is higher, your discount rate and/or you account may be reviewed by the bank.

3-D Secure reduces charge back exposure to merchants for fraudulent credit card purchases where the cardholder’s identity is in dispute. If a transaction has been fully authenticated, a merchant is not liable for 3-D Secure transactions where the identity has been questioned. Merchants can still be charged back for other reasons.

Talk about charge-back procedures with your bank representative or their customer service personnel. Also refer to online resources and merchant associations for further information on how to minimize charge-backs and potential fraud.

Verified by Visa (3-D Secure) Charge Backs Procedures

For Visa transactions processed using 3-D Secure, charge backs are handled using the following sequence.

1. When charged back, you will receive either a notice that you have been charged back or a sales draft request letter. This letter will reference a particular transaction, providing the date, the amount of that charge back, and the charge back reason.

2. If the reason for the charge back is one the following:

- 83 Non-possession of card
- 23 Invalid T&E Transaction

Proceed to the next step, in order to exercise your rights under Verified by Visa’s charge back protection. Otherwise, your merchant account will remain debited.

3. Log onto the E-xact Realtime Payment Manager (RPM) and isolate that particular transaction.

Click on the transaction details link for that particular transaction.

4. If the transaction has an ECI of 7, you have been charged back for a legitimate reason, and there is nothing that can be done to dispute this transaction.

5. If the transaction has an ECI (Electronic Commerce Indicator) of 5 or 6, click on the ‘transaction log request’ button to notify us of the charge back. In order for E-xact to look into your 3-D Secure transaction logs for proof of authentication, you are required to provide the following information about the disputed transaction (information can be found on the charge back / draft retrieval notice):

- Transaction reference number
- Transaction date
- Transaction amount
- Business Name
- Merchant #
- Charge back Reference Number

6. Your bank will then proceed to investigate the charge back and your merchant account will be credited if Verified by Visa rules allow.

For more information on the Verified by Visa program please visit www.visa.ca/verified. For more information on Charge backs, please refer to the Merchant Charge back FAQ that accompanied your Verified by Visa info package.




Article Details

Last Updated
24th of September, 2008

Would you like to...

Print this page Print this page

Email this page Email this page

Post a comment Post a comment

Subscribe me

Add to favorites Add to favorites

Remove Highlighting Remove Highlighting

Edit this Article

Quick Edit

Export to PDF

User Opinions (0 votes)

No users have voted.

How would you rate this answer?



Thank you for rating this answer.

Continue