Technical User Guide
- E-xact Payment Solutions
- Plug-in Features
- E-xact Accounts
- Setting up E-xact Gateway Server Options
- Testing Procedures
- Appendices
Payment APIs
E-xact Transactions Ltd. specializes in the real-time, secure movement of financial information through IP-based Point-of-Sale (POS) interfaces. Whether creating automated payment processing for websites, billing cycles for recurring payments, card-swipe and PC terminals for brick & mortar outlets, wireless POS, or full provisioning for an enterprise-wide platform.
E-xact offers a wide range of credit card purchase capabilities.
E-xact Payment Web Service APIs
The API is a build-your-own offering, typically used by experienced developers in order to create the merchants Point-of-Sale conduit. The Web Service API description and Verified-by-Visa plug-ins along with other integration guidelines can be found on the API Page.
- Requires no software installation
- Uses RPC/Encoded technology
- Can be integrated into any server environment that has access to a SOAP interface
- Tagged Transaction capabilities
- Track Data/Port Card Swipe capabilit
SSL Requirements
Merchants who deploy web storefronts or web-based orders using E-xacts solutions are required to enable a Secure Socket Layer (SSL), with 128 bit encryption, for their web server. E-xact does not provide website certificates; this is the responsibility of the merchant. Merchants using the EBB solution are not required to use SSL, but may do so if they choose. E-xact provides the certificates needed for the 3-D Secure connection to the 3-D Secure Merchant Service.
Note: Renewal and maintenance of merchant SSL certificates (except any 3-D Secure certificates provided by E-xact) is the responsibility of the merchant.
Realtime Payment Manager (RPM)
RPM is our web-based back-office product that audits all transactions conducted through our services. RPM does not require any software installation, but does require User Logins (login ID and password) for access. RPM is accessible via our website at www.e-xact.com and is SSL secured.
Features of RPM
VPOS
E-xacts VPOS (Virtual Point-of-Sale) permits users to manually enter specific transactions through a web browser. E-xact merchants log in to RPM for access to VPOS. It does not require any software installation.
Activity
For viewing all transactional activities through your E-xact account. Includes approved and declined transactions. Downloadable CSV Format Activity Report available. The CSV format is compatible with applications such as Excel.
Deposits
For viewing all approved transactions sent for settlement within a 24-hour period. Report time is customizable. It has separate screen reports by Card types and by Terminal.
Search
A search engine for all transactions and details on individual transactions. Data updated in real-time. Refunds can be conducted from this area, from the associated purchases/completions.
Help
Includes Bank Processor Response Codes and E-xact Response Codes. User Logins Individual Logins are assigned to each individual for access to E-xacts Member Services Manager. The passwords have 30-day expiry date (modified
by user online).
Email Reports
Daily and monthly emails can be sent to individual Users. The emails detail deposits for terminals on an account. Alert emails can also be set to notify of any possible E-xact or processor outage.
Cards supported by E-xact
E-xact supports all major credit card types (Visa, Mastercard) plus private label cards (American Express, Discover, JCB, Sears, and Diners Enroute)
Bank Processing Networks
E-xact connects with various bank-processing networks (processors) to authorize your credit card transactions. When credit card information is sent from your Point-of-Sale it passes through the IP network to E-xact. From there, the transaction is authorized in real time: through these processors, E-xact establishes the connectivity for your merchant bank information to properly process, capture and settle your funds. In effect, the bank processors are the clearinghouse for your transactions. E-xact is certified with the following bank processing networks:
- Emergis (Canada)
- Moneris (Canada)
- Vital Processing Systems (USA)
- Chase Paymentech (USA and Canada)
This processor information is subject to change, as E-xact expands its business relationships.
Funds Settlement
The bank processors E-xact operates with close out the transactions and send the settlement files to each respective financial institution. Settlement times vary according to card type and when the transactions were sent (cut-off times apply). Usually Visa and MasterCard settle within 24-48 hours. Non-bank cards (such as American Express) may take longer depending on each merchant/acquirer contract.
Transaction Types Available
E-xacts 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 credit card.
Pre-Authorization - sends through request for funds to be reserved on cardholder credit card. A standard Pre-Authorization is reserved for 2-5 days. Reservation times are determined by cardholder bank, not E-xact.
Pre-Authorization Completion - sends through a request for reserved funds from specific Pre-Authorization to be charged to cardholder. An authorization number is associated between a Pre-Authorization and Pre-Authorization Completion.
Refund - sends through a request for funds to be returned to cardholder. Refunds should not be made an automated function or available to cardholders.
Void - sends through a void to prevent the settlement of the funds. Voids are only successful if they are done on the same day as the authorization.
Authorization Only - type that is specific to BCE Emergis processor and the same as a pre-authorization. This transaction type can be associated with a Forced Post. Forced Post does a completion of a transaction that was not authorized on E-xacts system, i.e. Voice Authorizations or other source. 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 primary ability is to process a transaction without re-sending a credit card number.
Recurring Seed sends through a request to allow a merchant to preauthorize a credit card and reference the returned data to send multiple Tagged Purchase transactions or one Tagged Completion. This transaction will temporarily reserve funds on the card. It is suggested a small amount is processed for each Recurring Seed, such as $1.00.
Recurring Seed Purchase - Applies a purchase against the credit card provided. Funds for the specified amount are settled to the merchants account at the end of the day. Tagged Refunds equal to the amount of the original transactions amount can be applied against it using the returned TAG. An unlimited number of Tagged Authorizations or Tagged Purchases may be associated with it using the returned Tag.
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 amount 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 that is associated with a previous Pre-Authorization or Recurring Seed transaction. Only one Tagged Completion is permitted per Recurring Seed or Pre-Authorization transaction.
Tagged Refund - sends through a request for funds to be returned to a cardholder that is associated with a previous Purchase or Completion transaction.
iDebit Transactions
Debit Purchase - sends through sale and request for funds to be moved from cardholders bank account
Debit Refund - sends through a request for funds to be returned to cardholders 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 cardholders 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.
Interactions between Transaction Types
Secondary Action On Primary Transaction Type
Plug-In Features
Configuration of E-xact Plug-Ins
E-xact Plug-Ins have been designed for developers to customize features as much as possible.
This section outlines the necessary configurations and some options of the various functions that can be programmed for the merchant solution.
Each Plug-In has a unique set of public properties and methods available within it, described in the technical documentation specifically related to it. The following table provides a list of documents available. These documents are part of each Plug-Ins original installation.
Setting up Multiple Terminals
A merchant may receive more than one Production ID for their account. They are most likely to receive more than one terminal if they:
- Have merchant accounts in different currencies.
- Requested extra terminals to be assigned to identify separate payment sources.
Developers need to implement custom logic to divide the currency streams or multiple terminals. In the case of multiple currencies, this may include defining a customer profile or creating separate order pages for Canadian dollars and US dollars.
Setting up Multiple Currencies
In the case of multiple currency merchant accounts, E-xact sets up separate Production Plug-In Terminal IDs for each currency. Developers need to implement custom logic to divide the currency streams according to the appropriate Plug-In Terminals and 3-D Secure Merchant IDs. This may include defining a customer profile or creating separate order pages for Canadian dollars and US dollars (see the example above, Setting up Multiple Terminals).
Customer Transaction Record (CTR) Display
The Plug-In offers a pre-configured Customer Transaction Record (CTR) for transactions. The CTR is like a receipt that displays bank information, cardholder name, merchant name, merchant address and status of the transaction (approved or declined). It is a requirement of most financial institutions that a CTR be displayed to the cardholder after all transactions. The format of the CTR is fixed font plain text. The CTR can be displayed in French language as well.
The developer may also choose to store the CTR properties in the merchants database allowing for transactions to be searched on the merchants system.
CTR Example:
Reference Numbers
A merchant may need unique identifiers for each transaction conducted through the E-xact system. The Plug-In can capture and send reference information in addition to credit card information to our servers. Reference numbers are optional fields that interact with the E-xact Gateway System only. Reference numbers are not passed through to the Bank Processing Network or Settlement files. Exception: accounts using the Vital Systems must send a Reference Number that is passed to the Vital-processing center.
Reference Number (Reference_No) is a user-defined transactional property that is returned unchanged once the transaction is completed. It can be alphanumeric and up to 20 characters long. The Reference_No property is sent through only for ecommerce transactions. These values are displayed in the Reference field of the Search report in E-xacts Member Services Manager. This should not be confused with the Bank Ref # that is listed on the CTR (which is a combination of the Sequence-Authorization numbers returned from the bank).
Customer Reference Number (Customer_Ref ) is a user-defined transactional property. It can be alphanumeric and up to 20 characters long. This should not be confused with the Bank Ref # that is listed on the CTR (which is a combination of the Sequence-Authorization numbers from the bank).
Writing Transactional Information to Merchant Database
The developer can set up a great number of the fields that are sent and returned from the Gateway Servers, Directory Server and ACS. These values can be stored on your own servers for data tracking. Refer to E-xact Programming Reference Guide to find out more about the various properties and methods available.
About Tagged Transactions
A merchant may want to do recurring (batch) billing without having to store credit card numbers on their system, since storing credit card numbers locally is a security risk. To enable this, E-xacts software offers support for Tagged Transactions. See Appendix E for further details.
About Cardholder Verification Systems (CVV and AVS)
Validating a cardholders identity helps protect against fraudulent transactions. Three methods exist for validating a cardholders identity when processing card not present (MOTO and e-commerce) transactions.
Another new method 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. Please see Appendix C for details regarding CVV.
The oldest method is the Address Verification System (AVS). AVS is only supported on US merchant accounts processing transaction for US cardholders. Please see Appendix D for details regarding AVS.
E-xact Accounts
E-xact ConnectionShop Test Account
All developers who have downloaded the E-xact Payment Plug-Ins will have access to E-xacts test servers and a test account called E-xact ConnectionShop. E-xact ConnectionShop is a shared testing resource that records all test transactions sent to the test servers. E-xact recommends that after integrating E-xacts Payment Plug-Ins, the developer set up a connection to E-xacts testing environment. All development should be done in this environment prior to moving any newly developed code to the production environment.
- Please note test credentials apply to credit card processing only. For credentials specific to iDebit, contact E-xact Transactions.
Individual Test Account (optional)
Developers can establish an individual test account for their software testing after the merchant business has registered for E-xacts services. An individual Test Account is different from a regular test account in that a separate viewing area is provided for only your private test transactions. Also, if you plan to continue testing periodically after your merchant solution has launched, an individual test account is a safe way to test any changes you work into your solution. To set up an Individual Test Account, the merchant will need to contact E-xact technical support.
Production Account
Production accounts are activated only after E-xacts Customer Service has completed the clients registration. The merchant registrant will receive User IDs for login access to E-xacts Member Services Manager as well as production Gateway Terminal credentials. Production Accounts connect live to the bank processors and merchant banks and therefore move money and funds in real-time.
Gateway Terminal Credentials
E-xacts Gateway Servers identify a merchants various accounts (test or production) by assigning one or more virtual Gateway Terminals. Each set of Gateway Terminal credentials consist of:
- Gateway ID (9 character identifier) {Property name: ExactID}
- Password (variable length) {Property name: Password}
These terminal credentials establish the interaction between the E-xact software and our payment servers. As a developer, you will encounter a series of accounts that require Gateway Terminal credentials. There are Gateway Terminal credentials for:
- The E-xact ConnectionShop Test Account. E-xacts software defaults to E-xacts test server account (ConnectionShop).
- Individual Test Accounts.
- Production Accounts.
Test Mode to Production Mode
When the new code is ready to move from test mode to production mode, either the ConnectionShop or Individual Test Account Credentials would be replaced with the appropriate Production Account Credentials.
Terminal Configuration of Card Accounts
There is no need to change credentials to process different credit card types, as the E-xact Gateway Terminal automatically maps to the card type(s) supported by the merchant. For example, Production Gateway Terminal ID: A00001-01 is set up with two Canadian dollar accounts: a Visa merchant account and a MasterCard merchant account, so it accepts both Visa and MasterCard under this Gateway Terminal ID profile.
Note that it is possible for merchants to receive more than one test or production Gateway Terminal, and that different currencies will always be assigned separate Gateway Terminal IDs. Also, one Gateway Terminal can be assigned additional Terminal appendages, so that a single Production Gateway Terminal ID may have multiple terminals credentials under its profile. For example, Gateway Terminal ID: A00001-01 accepts Canadian Visa and MasterCard. IDs A00001-02, A00001-03 can also be assigned and associated with the 01 Gateway ID. All three IDs will then process under the one profile with the same accounts from your bank(s).
Test Mode to Production Mode
When new code is ready to move from test mode to production mode, either the ConnectionShop or Individual Test Account Credentials would be replaced with the appropriate Production Account Credentials.
User Logins
User Logins are used to access E-xacts Member Services Manager at www.e-xact.com. User Logins consist of a Login Name and Password. Developers will encounter two types of User Logins with E-xact:
Test User Login
Provides access to E-xacts ConnectionShop Test Manager. The Test User Login provides a connection to the test server. When you download and register the E-xact software, you automatically receive a Test User Login by email.
Production User Login
Provides access to the merchants E-xact account profile within the Member Services Manager. The Production User Login provides a production (live) server connection. E-xact creates Production User Logins and provides them to developers on request.
Setting Up E-xact Gateway Server Options
E-xacts Gateway Options are implemented on the merchants account by E-xacts Technical Support. These features are set up with default values of Unrestricted but can be modified upon request from the merchant. These features are optional.
The Risk Management tools described below are intended to help eliminate human error and fraud from transactions:
Duplicate Checking
All merchants are set up with a default duplicate-checking status value of Unrestricted. The currently supported Duplicate Checking types are:
1. Unrestricted
E-xact will pass all transactions through to the bank without question. No checking for duplicate transactions is done.
2. Deny All
All duplicate transactions received with a given period of time are declined by E-xact and are not sent through to the Bank Processing Networks. The time period is measured in minutes. The normal time period is 10 minutes. Duplicate transactions are defined as two or more transactions occurring within a specified period of time with the following fields exactly the same:
- ExactID
- Transaction Type
- Credit card Number
- Amount
Invalid Duplicate If an incoming transaction is flagged as a duplicate, it is not passed on to the financial institution, and is returned to the client with an Invalid Duplicate message and a Transaction Not Completed status. A message indicating that it was a duplicate is returned in the CTR response, and will appear in the transaction Search Detail within Member Services.
Configuration: Duplicate Checking
Unrestricted
Deny All [duplicates] during a ___ minute cycle
Refund Checking
All merchants are set up with a default Refund Status (or value) of Unrestricted. Most financial institutions place few limits on the number of refunds that a merchant may process, or how those refunds match up to existing purchase transactions. The currently supported E-xact Refund Checking types are:
1. Unrestricted
E-xact will pass all transactions through to the bank without question. No Refund checking is done.
2. Refund Volume
On a daily basis, refund transactions are limited by both of the following criteria:
- Total Number of Refunds
- Total Dollar Amount of all Refunds
If either of or both of these limits are surpassed on a given day, all subsequent Refunds will not be completed.
Configuration: Refund Checking
- Unrestricted
- Refund Volume
– Total Number of Refunds per day is ___
– Total Dollar Amount for Refunds per day is ___
Velocity Controls
All merchants are set up with a default Velocity status (or value) of Unrestricted. Controls which can be set to restrict transactions, based upon dollar amount, card usage, or transactional volume. Velocity Controls will restrict transactions based upon:
1. Individual Transactions:
- Maximum Dollar Amount for an individual transaction.
- Minimum Dollar Amount for an individual transaction.
2. Unique Credit Card Number:
- 1 or 30-Day Card Usage (cumulative amount charged to the same credit card number over a selected time frame). Purchase type transaction only.
- 1 or 30-Day Volume (cumulative amount processed through the merchants E-xact account over a selected time frame). Purchase type transaction only.
Configuration: Velocity Checking
- Unrestricted
- Maximum Amount $___ per transaction
- Minimum Amount $___ per transaction
- 1 or 30 day Card Usage $___ total dollar amount on a credit card number
- 1 or 30 day Volume $____ total dollar amount on merchants account
AVS Filter Use
The AVS Filter works on negative matching: the AVS codes that the merchant wants to use will be set up on each Gateway. When the specific AVS code criteria are met, the transaction will be rejected. The AVS Filter can be set up in lieu of the Plug-In being configured for AVS. In the case of E-xacts Redirect solutions, AVS Filter is the only option. For further details, see Appendix D.
Configuration: AVS Filter
Contact E-xact with the AVS codes you wish to reject and, in turn, drop. Provide only the letters for AVS codes you wish to turn away and not process transactions for.
AVS Message / AVS Code
- Exact match, 9 digit zip / X
- Exact match, 5 digit zip / Y
- Address match only / A
- 9-digit zip match only / W
- 5-digit zip match only / Z
- No address or zip match / N
- Address unavailable / U
- Non-US Issuer does not participate / G
- Issuer system unavailable / R
- Not a mail/phone order / E
- Service not supported / S
Credit Card Number Filter
Merchants can request that we enter a fraudulent credit card number into E-xacts database so that all E-xact customers are protected from the fraudulent card number. The card number needs to be verified as fraudulent by E-xact prior to filtering. Further details available upon request. E-xact recommends that you save the E-xact Response Codes that are returned from the E-xact system, if you or the merchant wishes to investigate transactions that have been affected by any of the Gateway Server Options.
Testing Procedures
Testing Procedure Outline
Developers should follow E-xacts recommended Testing Procedure prior to launching an E-xact solution:
With Test Account Codes (Test Environment)
- Connectivity testing
- Transactional testing
- Reconciliation of the records in online reports (E-xact Member Services with merchant database)
With Production Codes (Production Environment)
- Connectivity testing
- Transactional testing
- Reconciliation of the records in online reports (E-xact Member Services with merchant database)
- Funds Settlement (check bank statements)
Setting Up ConnectionShop Test Credentials
E-xacts test servers support all clients who have downloaded and registered an E-xact Payment Plug-In. The sample scripts provided with the Plug-Ins are set with the following Test Credentials for E-xacts ConnectionShop Test Account.
Canadian Dollars
- Plug-In Credentials
– Gateway: A00049-01
– Gateway Password: test1
US Dollars
- Plug-In Credentials
– Gateway: A00427-01
– Gateway Password: testus
The test environment simulates transactions only. No real money is transferred because there is no connection to the bank processing networks.
Transactions in the test environment are processed in the same way transactions are processed in the production environment. In addition, the test environment simulates the expected response times for the network. The development done in the test environment can thus be easily changed over for use in a production environment: the developer can simply replace the Test Credentials with the Production Credentials when necessary.
Test Error Triggers
A particular bank response code can be triggered in the test environment by sending a transaction with the dollar amount equal to 5000 plus the numeric error code as the transactions dollar amount value.
For example, to generate bank response code 076 (insufficient funds), the dollar amount $5076 (that is, 5000 + 076) would be sent.
Test error triggers are for use in E-xacts Test Environment only The bank response codes that are available for simulation using test error triggers depend on the Processing Network the Merchant Account is set up for. The Bank Processor Response Codes for the available processing networks are defined in Appendix H. The test Gateway A00049-01 is used for the Moneris network (CAD); the test Gateway A000427-01 is used for the Vital network (USD).
Sample Scripts
Please use the sample scripts provided with the Plug-Ins to test the different transaction types. This sample code can be used to simulate the various transaction types and interact with E-xacts test servers.
E-xact does not provide real credit card numbers for testing purposes. Using real credit cards is the only way to ascertain your ability to authenticate a credit card.
Sending Test Transactions
Select the type of transaction you would like to conduct. You can use the test error triggers with the test credit card numbers listed below or with real credit cards. All test transactions sent interact with the test processing servers (transactions sent to these servers are not processed by the bank processing networks.)
You can simulate various processing responses / failures by sending a test transaction for a certain dollar amount. Processing a transaction for the dollar amount of $5000 plus the number for the Bank Processor Code will do this. In example, to simulate a transaction that will return a Bank Processor Code of 100, you would processes the test transaction for $5100.00 (5000 dollars plus the Bank Processor Code 100). The Bank Processor Codes that can be used to simulate responses / failures are defined in Appendix E.
Test Credit Card Numbers
These are for use in E-xacts Test Environment only. Other people are using these test numbers in the ConnectionShop testing environment, so be sure to use your name or other identifier in order to track the transactions you send to that test account. Do not enter spaces within the card number.
Test Credit Card Numbers
Visa 4111 1111 1111 1111 expiry date: Any future date (e.g. 12/12)
MasterCard 5500 0000 0000 0004 expiry date: Any future date (e.g. 12/12)
American Express 3400 0000 0000 009 expiry date: Any future date (e.g. 12/12)
JCB 3088 0000 0000 0009 expiry date: Any future date (e.g. 12/12)
Discover 6011 0000 0000 0004 expiry date: Any future date (e.g. 12/12)
Note: If the test transaction does not succeed, it could be due to improper card data entry, a lack of Internet connectivity, or connectivity problems between your system and E-xacts Plug-In. See Appendix I for suggestions about checking connectivity.
Response messages returned by sample scripts
Responses returned by sample script(s) using a Test Gateway ID consist of one of the following:
- Approved
- Denied
- Transaction not completed
For further details on the responses, or to view the transaction details, go to the E-xact ConnectionShop Test Manager (see below).
Viewing your tests within ConnectionShop Test Manager
The E-xact ConnectionShop Test Manager can be used to confirm the responses received by the sample script(s) by viewing the test transactions once they have been sent. To view test transactions, developers will need to log into the E-xact ConnectionShop Test Manager.
Note: Merchants also receive a similar interface (E-xact Member Services Manager) for their Production Account.
To log in:
1. Go to www.e-xact.com.
2. Enter your email address (this will be your User Login next time you log in) and the password you received via email, upon successful demo or download registration.
3. Press the Login button.
4. Once logged in you will be on the Home Page. Go to Search.
5. Within Search enter the parameters to find your transaction.
6. Select the Gateway Terminal you sent transactions to (USD or CAD). To pinpoint your tests, select a date range, and enter the cardholder name.
7. Click the Search button.
8. The search result(s) will be returned. You will see the transaction records returned with specific information on the transactions.
9. By clicking on the magnifying glass icon on left of the record, you can view further details about the transaction.
10. If you cannot find the transactions, please read the Troubleshooting section and review your configuration of the sample script.
Testing within the Production Account
All transactions sent in the Production Environment are active and move real money. This is because your connection is now with E-xacts Production servers, and any transactions are sent directly through to the processing networks and banks. To make sure your connection is properly established, we strongly suggest you test your solution using real credit cards.
Setting up Production Account Credentials
When ready to move from Test mode to Production mode (which means that the merchant is ready to send live transactions through to the banks), developers must replace the Test Credentials with Production Credentials.
Production Account IDs will be distributed to the Merchant and/or Registrar once the production account(s) have been set up on E-xacts system. Keep these IDs secure. If the Test Gateway Terminal ID, Gateway Terminal Password and Merchant ID are hard coded into the script, then comment out the Test Gateway Terminal ID, Gateway Terminal Password and Merchant ID and un-comment the Production Gateway Terminal ID, Gateway Terminal Password and Merchant ID. The AcquirerID and MerchantID Password will not likely change between testing and production environments.
For example:
‘Test Login Information
‘ExactID = “A00001-01″
‘ExactIDPassword = “testPassword”
Production Login Information
ExactID = “A0XXXX-01″
ExactIDPassword = “productionPassword”
Once the Production IDs have been entered, the Point-of-Sale should now connect to the production servers.
Sending Test Transactions in the Production Environment
The sample credit cards provided for the testing environment will be rejected in the production environment and cannot be used to determine if authorization and settlement is functioning. E-xact does not provide test credit card numbers for production-level testing. Please use real credit card numbers for the various card accounts you have established. Using real credit cards is the only way to ascertain that the production account is active and working. When testing, conduct the transaction types you have enabled with the E-xact software. Keep in mind that:
- A pre-authorization will reserve funds on a card for a limited period of time, and expire if not completed.
- A purchase will charge a card automatically.
Recommended guidelines when testing with credit cards
When you are ready to test the production environment with real credit cards, please use common sense. Here are some guidelines:
- Do not enter large dollar amounts. You will shortly exceed the credit limit on the card, and possibly block the cardholders card. We suggest you input small currency amounts, such as a dollar, so as to not exceed any credit limit on the card.
- Avoid repeated use of one card. Duplicate transactions or multiple transactions on one card can alert the processors of possible mischievous activity and could result in the card being denied and blocked from use.
- Do not forge an expiry date or name. The bank may view this as mischievous conduct on the card and block usage.
- Make sure to void or refund any purchases or pre-authorized completions made with the card if you do not want the cardholder charged.
Steps for testing card transactions
- Select the transaction type.
- Enter the cardholder name, credit card number, expiry date, and amount into your POS.
- Submit the transaction. A response is returned in the CTR (Customer Transaction Record).
- Confirm the transaction response in E-xacts Member Services Manager.
E-xact Member Services Manager User Logins
Each merchant receives User Logins and passwords for the Member Services Manager, which is accessed at our website at pos.e-xact.com.
Developers will only be provided a User Login if assigned one by the Merchant. The developer should use the Member Services Manager to monitor production-level testing.
Viewing live Transactions with E-xact Member Services Manager
1. Go to pos.e-xact.com.
2. Enter your User Login and Password. Press Login. The ConnectionShop Logins will not work for the production environment.
3. Once logged in you will be on the Home Page. Go to Search.
4. Within Search, enter the parameters to find your transaction. Select the Terminal you sent the transactions to (if you have more than one set up). To narrow your search, select the date range and then enter the cardholder name.
5. Click the Search button.
6. The search result(s) will be returned. You will see the transaction record returned with the specific information on the transaction.
7. By clicking on the magnifying glass icon on the left, you can view further details about the transaction.
8. If the transaction is approved and has charged the card, (purchase or pre-authorization completion) a red R icon appears on the left side of the transaction record. To refund the transaction:
1) Click the red R
2) A POS record will appear with the amount to be refunded.
3) Click on Refund Transaction.
4) A CTR receipt will display the response for the refund transaction.
5) An additional transaction record for the refund is recorded if the transaction was processed. To view this refund transaction record, run the Search report again. You will see a separate transaction with refund status. The original purchases red R is replaced by a green R once the transaction is refunded. For a partial refund it remains red.
9. If the transaction is declined, click on the detail record to view the Transaction Detail. This will list the Bank Processor response message and/or code
1) If the transaction was declined due to a Transmission Failure, this points to an internal problem with the connection between the Merchant solution and the E-xact servers, or between the E-xact servers and the Bank Processing Network.
2) If the transaction was Declined and received a Bank Response, this indicates that the transaction was declined by the Bank Processing Network. You can investigate further by checking the Bank Response Code in Appendix H.
3) If you cannot see the transactions, please use Appendix I to help you troubleshoot and review your configurations.
Checking Settlement of Funds
Settlement is a separate step from the transaction authorization, and is independently handled by the Bank Processing Network and bank(s), and not by E-xact Transactions. Developers should check that funds settle properly to the merchants account(s). Run purchases through and wait a few days before refunding, in order to check that the settlement of funds occurs from the merchants Point-of-Sale and between the bank processor and bank. Wait 24 to 48 hours after you have put through a purchase or pre-authorization completion and have the merchant confirm funds have been settled to their deposit account(s). Point-of-SalePoint-of-Sale
Appendices
Appendices are available for download in the full document (.pdf) or on their own (.pdf)