# Test Numbers & UAT Testing

This document describes how to use **test numbers** when validating ACH and card payment flows in the **UAT (User Acceptance Testing)** environment.

Test numbers allow you to safely exercise your integration without using real payment credentials and without risk of processing real funds.

## Purpose of Test Numbers

div
strong
Key idea:
br

  Test numbers simulate real-world payment scenarios without touching real accounts or cards.

Use test numbers to:

- Validate end-to-end payment flows
- Exercise success and failure scenarios
- Test refunds, voids, and retries
- Verify error handling and user experience


**WARNING:**
Never use real bank account or card information in the UAT environment.

## Environment Scope

Test numbers are supported **only** in the **UAT environment** and must be used with:

- UAT API endpoints
- UAT API keys
- Tokenization iframe in UAT mode


Test numbers will not work in Production and must never be used there.

## ACH Test Numbers

Use the following values when testing ACH payments in UAT.

### ACH Account Details

| Test Account Number | Test Routing Number |
|  --- | --- |
| `12345678` (account numbers may be 3–17 characters) | `121042882` or `076401251` (must be 9 digits) |


These values simulate valid ACH debit and credit scenarios.

## Card Test Numbers

Use the following test card numbers to simulate card transactions by network.

### Supported Card Networks

| Card Network | Test Card Number | CVV |
|  --- | --- | --- |
| American Express | `345829002709133` | `9997` |
| Discover | `6011010948700474` | `996` |
| Mastercard | `5513402530309795` | `998` |
| Visa | `4929109835947309` | `999` |


### Expiration Date

Use any **future expiration date**, recommended at least **two years in the future**.

Accepted formats:

- `MMYY`
- `MM/YY`


## Using Test Numbers with Tokenization

Test numbers are entered directly into the **tokenization iframe**, just like real payment credentials.

- The iframe accepts test values without special configuration
- Tokenization returns a valid payment token
- The token can be used to exercise the full Payments API flow


This allows you to test:

- Token creation
- Fraud and validation logic
- Payment submission
- Processor responses


## Simulated Outcomes

Test numbers are designed to simulate realistic behavior, including:

- Approved transactions
- Declined transactions
- Validation errors
- Downstream processing behavior (refunds, voids, etc.)


Specific decline scenarios may depend on:

- Transaction type
- Amount
- Merchant configuration


## Best Practices

div
strong
Best practices:
ul
li
Always verify you are using UAT credentials and endpoints
li
Never store or log real payment data
li
Test both success and failure paths
li
Validate refund and void workflows
## Moving to Production

Before switching to Production:

- Remove all test numbers
- Verify Production API keys are in use
- Validate Production endpoints
- Perform a final smoke test using approved production credentials


## Summary

- Test numbers are for **UAT only**
- They simulate real payment behavior safely
- Use test numbers with the tokenization iframe
- Never use real payment data outside Production
- Always verify environment configuration