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.
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.
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.
Use the following values when testing ACH payments in UAT.
| 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.
Use the following test card numbers to simulate card transactions by network.
| Card Network | Test Card Number | CVV |
|---|---|---|
| American Express | 345829002709133 | 9997 |
| Discover | 6011010948700474 | 996 |
| Mastercard | 5513402530309795 | 998 |
| Visa | 4929109835947309 | 999 |
Use any future expiration date, recommended at least two years in the future.
Accepted formats:
MMYYMM/YY
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
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
- Always verify you are using UAT credentials and endpoints
- Never store or log real payment data
- Test both success and failure paths
- Validate refund and void workflows
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
- 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