The article has been updated successfully.* To download a PDF copy of the Technical User Guide do not click the "Export to PDF" option on the right hand side. Instead, go to the Attachments section at the bottom of the page and download the linked copy provided.
As each merchant’s requirements and technical platforms vary, this document should only be used as a guideline with respect to the general technical features and services of E-xact. For a business overview, please refer to the E-xact Merchant Guide. Additional technical information, such as Plug-In Programming Reference Guides, may be found in the documentation provided within each Plug-In download.- E-xact Payment Solutions
- Plug-in Features
- E-xact Accounts
- Setting up E-xact Gateway Server Options
- Testing Procedures
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 capability (see Sending Track Data)
SSL Requirements
Merchants who deploy web storefronts or web-based orders using E-xact's 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 Hosted Checkout solution are not required to use SSL, but may do so if they choose. E-xact works with Cardinal Commerce to provide 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 Cardinal) 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-xact's 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.
Transactions
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.
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 or planned maintenance.
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:
- Telus (formerly Emergis) (Canada)
- Moneris (Canada)
- TSYS Acquiring Solutions (formerly Vital) (USA)
- Chase Paymentech (USA and Canada)
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-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 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 the Telus 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-xact's system, i.e. Voice Authorizations or other source. The Authorization number provided by the Card Company must be contained in the Forced Post Transaction.
Tagged Transactions
A tagged transaction's primary ability is to process 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.
Tagged Void - sends through a void request to cancel a previously approved Purchase, Pre-Authorization Completion, Forced Post, or Refund type transaction. Note that the transaction to be voided must have been completed before batch closing on the same day as the void request.
iDebit Transactions
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. These documents are part of each Plug-Ins original installation.
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.
Plug-In Features
Configuration of E-xact Plug-InsE-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. 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.
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 e-commerce transactions. These values are displayed in the Reference field of the search report in E-xact's RPM website. 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-xact's software offers support for Tagged Transactions. See Tagged Transactions: Functional Specifications 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 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 the CVV/CVV2/CVD Hotsheet for details regarding the Cardholder Verification Value.
The oldest method is the Address Verification System (AVS). AVS is supported on US and CAD merchant accounts processing transaction for North American and some European cardholders. For further details regarding AVS, please click here.
E-xact Accounts
E-xact ConnectionShop Test AccountAll developers who have downloaded the E-xact Payment Plug-Ins will have access to E-xact's 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-xact's Payment Plug-Ins, the developer set up a connection to E-xact's 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-xact's 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-xact's Customer Service has completed the clients registration. The merchant registrant will receive User IDs for login access to E-xact's RPM 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-xact's Gateway Servers identify a merchant's 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-xact's software defaults to E-xact's 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-xact's RPM at pos.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-xact's 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 RPM. 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-xact's Gateway Options are implemented on the merchants account by E-xact's 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:
- Unrestricted E-xact will pass all transactions through to the bank without question. No checking for duplicate transactions is done.
- Deny All
- ExactID
- Transaction Type
- Credit Card Number
- Amount
- Credit Card Expiry Date
Configuration: Duplicate Checking
-Unrestricted
-Deny All [duplicates] during a ___ minute cycle
For steps on setting up duplicate checking in RPM, click here
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:
- Unrestricted E-xact will pass all transactions through to the bank without question. No Refund checking is done.
- 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.
- Unrestricted
- Refund Volume
-- Total Number of Refunds per day is ___
-- Total Dollar Amount for Refunds per day is ___
For steps on setting up refund checking in RPM, click here
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.
- 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
To set up velocity controls on your gateway(s) please contact E-xact Support.
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-xact's Redirect solutions, AVS Filter is the only option. For further details, see Set up an AVS Filter in RPM.
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.
North American Response Codes
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
International Response Codes
AVS Message/AVS Code
- Global non-AVS participant / G
- Address matches only / B
- Address and Postal Code do not match / C
- Address and Postal Code match / D
- Address and Postal Code match (UK only) / F
- Address information not verified for international transaction / I
- Address and Postal Code match / M
- Postal Code matches only / P
Credit Card Number Filter
Merchants can request that we enter a fraudulent credit card number into E-xact's 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 OutlineDevelopers should follow E-xact's 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 RPM with merchant database)
With Production Codes (Production Environment)
- Connectivity testing
- Transactional testing
- Reconciliation of the records in online reports (E-xact RPM with merchant database)
- Funds Settlement (check bank statements)
Setting Up ConnectionShop Test Credentials
E-xact's 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-xact's 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-xact's 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 here. 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-xact's 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 here.
Test Credit Card Numbers
These are for use in E-xact's 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-xact's Plug-In. See API Connectivity to E-xact 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's RPM) for their Production Account.
To log in:
- Go to pos.e-xact.com.
- Enter your username (this will be your User Login next time you log in) and the password you received via email, upon successful demo or download registration.
- Press the Login button.
- Once logged in you will be on the Home Page. Go to Search.
- Within Search enter the parameters to find your transaction.
- Select the Gateway Terminal you sent transactions to (USD or CAD). To pinpoint your tests, select a date range, and enter the cardholder name.
- Click the Search button.
- The search result(s) will be returned. You will see the transaction records returned with specific information on the transactions.
- By clicking on the magnifying glass icon on left of the record, you can view further details about the transaction.
- If you cannot find the transactions, please read the troubleshooting section and review your configuration of the sample script.
All transactions sent in the Production Environment are active and move real money. This is because your connection is now with E-xact's 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-xact's 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. 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-xact's RPM.
Each merchant receives User Logins and passwords for RPM, 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 RPM to monitor production-level testing.
Viewing live Transactions with E-xact's RPM
- Go to pos.e-xact.com.
- Enter your User Login and Password and press Login. The ConnectionShop Logins will not work for the production environment.
- Once logged in you will be on the Home Page. Go to Transactions.
- Within Transactions, 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.
- Click the Search button.
The search result(s) will be returned. You will see the transaction record returned with the specific information on the transaction. By clicking on a transaction, you can view further details about the transaction. If the transaction is approved and has charged the card, (purchase or pre-authorization completion) an "R" icon appears on the left side of the transaction record. To refund the transaction:
- Click the R
- A mini-POS will appear with the amount to be refunded pre-populated. This can be adjusted down if necessary.
- Click on Submit Refund.
- A CTR receipt will display the response for the refund transaction.
- An additional transaction record for the refund is recorded if the transaction was processed. To view this refund transaction record, run the search again. You will see a separate transaction with refund status. The original purchase's R is replaced by a clock icon once the transaction is fully refunded. For a partial refund the "R" remains.
If you cannot see the transactions, please this article 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).
