Demo Testing and Test Cards

The E-xact Demo is a testing environment that mimics the live production gateway. It allows you to build, test, and troubleshoot your integration without processing live transactions.

🚧
Important Testing Rule
Never use real credit card numbers in the Sandbox environment.

Test Credit Card Numbers

You can use the following test card numbers to simulate successful transactions. When testing, you can use any future Expiry Date (e.g., 1230 for Dec 2030) and a valid-length Security Code / CVV (e.g.123 for Visa/MC/Discover, or 1234 for Amex).

Card Brand	Test Card Number	CVV Length	Expected Result
Visa	`4111111111111111`	3 digits	Approved
Mastercard	`5454545454545454`	3 digits	Approved
American Express	`378282246310005`	4 digits	Approved
Discover	`6011111111111117`	3 digits	Approved
JCB	`3566002020360505`	3 digits	Approved
Union Pay	`6200000000000005`	3 digits	Approved

Triggering Errors and Declines

To ensure your application handles errors gracefully, you need to test how your system reacts when a transaction is rejected. In the Sandbox environment, you can trigger specific error codes by submitting transactions in the $5,000.00 to $5999.99 range.

Depending on whether you modify the dollars or the cents, you can simulate either a Bank Decline or an internal ETG Gateway Error.

1. Bank Declines ($5000 to 5999 Dollar Range)

To simulate a standard bank decline (where the customer's issuing bank rejects the card), submit a transaction where the dollar amount is in the $5000s, ending in .00.

Transaction Amount	Simulated Response	Bank Decline Code
`$5005.00`	Transaction not approved	`05`
`$5100.00`	Transaction not approved	`100`
`$5200.00`	Auth Declined	`200`
`$5300.00`	Invalid Term ID	`300`

2. ETG Gateway Errors ($5000.00 to $5000.99 Cents Range)

Sometimes a transaction is blocked by the gateway before it reaches the bank (e.g., due to invalid formatting, missing fields, fraud filters, or velocity controls).

To simulate these internal ETG Gateway Error Codes, submit a transaction for exactly $5000, and use the cents to specify the ETG error code you want to trigger.

Transaction Amount	Simulated Response	ETG Code	Example Scenario
`$5000.08`	Bad Request	`08`	CVV2/CID/CVC2 Data not verified.
`$5000.12`	Server Error	`12`	Message Timed-out at Host
`$5000.22`	Invalid Credit Card Number	`22`	The credit card is invalid
`$5000.44`	Transaction Error	`44`	Address not Verified.
`$5000.69`	Bad Request	`69`	Invalid Transaction Tag.
`$5000.72`	Server Error	`72`	Transaction sent to bank.

(Note: You can replace the cents above with whichever specific ETG response codes you are building error-handling logic for).

3. Testing CVV/CVD/CVC Functionality:

In the Demo environment, you can simulate specific CVV/CVD/CVC security code verification responses.

1. Simulating a Match (Approval)

To simulate a successful CVV match (M), use the security code 123.

2. Simulating a Mismatch (Decline)

To simulate a failed CVV check (N), use the security code 234.

All Simulated CVV Responses

If you need to test other cases, here is the complete list of simulation triggers:

First Digit	Example Value	Simulated CVV Response	RPM Filter Name / Description
1	`123`	M	Card is authentic (Match)
2	`234`	N	CVV2 does not match
3	`345`	P	Card expiration not provided or card does not have valid CVD code
4	`456`	S	Merchant indicated that CVV2 is not present on card
5	`567`	U	Card issuer is not certified and/or has not provided visa encryption keys

How to Submit the CVV Value:

Hosted Checkout (HCO): Enter your simulated value (e.g., 234) directly into the standard Security Code field on the payment collection form.
API Transactions: Pass the simulated value in the VerificationStr2 attribute of your request. The CVD_Presence_Ind property must also be set to 1for the verification rule to trigger.

📘
Note on CVV Declines
Passing a mismatched CVV will only decline the transaction if your terminal has the matching filter checked inside your RPM Terminal settings under CVV2 Filters.

4. Testing AVS (Address Verification) Responses

You can simulate specific AVS response codes by setting the first character of the billing address value to the exact AVS letter code you wish to trigger.

Simulating a Specific AVS Code

To simulate a response, simply prefix your test street address with the desired response letter.

Example: Simulating a "No Match" (N) If you want to simulate an N (No match) response, you would set the address value to N123 Main St.

How to Submit the AVS Value:

Hosted Checkout (HCO): Enter your simulated address value (e.g., N123 Main St) directly into the standard Billing Street Address field on the payment collection form.
API Transactions: Pass the simulated address value (e.g., N123 Main St) in the VerificationStr1 attribute of your API request.

Supported AVS Response Codes

You can use any of the following letters at the start of your address string to trigger the corresponding AVS response:

AVS Code	Description & Explanation
X	Exact match: 9-digit ZIP
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 Code match only
N	No match: No Address or ZIP Code match
U	Unavailable: Address information is unavailable for that account number, or the card issuer does not support
G	Service not supported: Non-US Issuer does not participate
R	Retry: Issuer system unavailable, retry later
E	Error: Not a mail or phone order
S	Service not supported

📘
Note on AVS Declines
Simulating an N response will only cause the transaction to fail if your terminal has the "No match" AVS filter checked inside your RPM Terminal Administration settings. Otherwise, the transaction may still approve but return the N warning in the response payload.

Verifying Your Tests

Once you have run a few test transactions, you can verify the exact payloads, response codes, and timestamps by logging into the Demo RPM and navigating to the Transactions tab.