Test Data

Test cards you can use in the PCE Sandbox to safely simulate approvals, declines, and common payment scenarios.

Important: Use these numbers only in sandbox/test environments. Do not use real payment cards for testing. Follow your organization’s PCI and security guidelines.

Definitions

• AVS (Address Verification Service): Validates the billing address (street/ZIP) against issuer records.
• CVV / CVC: Verifies the accuracy of the card security code.
• Issuer Response Codes: Numeric codes that indicate the result of a transaction.
• Authorization Message: A human-readable message associated with the response code (e.g., “Do Not Honor”).
• EMS/Fraud Score: Mastercard’s risk score and reason code derived from fraud screening.

General test cards

Test cards are fake card numbers used in development and testing to safely simulate payment transactions.

Why they matter

• No real money involved — safe for testing.
• Simulate approvals/declines, fraud, insufficient funds, expired cards, etc.
• Validate behavior for AVS, CVV, 3-D Secure (3DS), and partial approvals.
• Ensure proper error handling and user-friendly messages.
• Avoid fraud, chargebacks, or compliance issues that arise from using real cards.
• They’re essential for developers, testers, and QA teams working on payment integrations.

Use these in the PCE Sandbox. Expiry date and CVV rules may vary by gateway; follow the gateway’s test guide when a specific CVV/AVS is required.

Usage tips

• Scope: These values are for sandbox only; production gateways will reject most test PANs.
• Scenarios: Pair with gateway-specific AVS/CVV values to trigger approvals, soft/hard declines, and error codes.
• Logging: Capture request/response payloads to verify error handling and user messages.
• Data hygiene: Do not store PANs in logs or screenshots outside approved secure tools.

Issuer response codes

When you submit a payment authorization, the issuing bank (or card network) returns a response code that indicates approval or the reason for decline. These codes drive your next steps (retry, prompt the cardholder to call their bank, collect another payment method, or handle a partial approval).

Reference: PCE provides an “authorization code messages” list that maps raw codes to human-readable messages.

Where you’ll see it in responses

• responseCode — primary numeric code from the processor
• issuerResponseCode — issuer-specific variant (if provided)
• authMessage / authMessageText — human-readable explanation
• approvedAmount — present when a partial approval occurs

Common response codes & meanings (across brands)

Actual mappings can vary by bank/processor. Use this table to design user messaging and fallback logic, and verify against your sandbox docs.

Test cases for issuer response codes

• Mapping between responseCode / issuerResponseCode / authMessage and business outcomes (Approved / Decline / Partial approval).
• UI behavior on device receipts, web receipts, and in PCE.
• Automatic logic paths — retry, fallback, “call your bank,” or request an alternate method.
• Edge cases — partial approvals, timeouts, network failures, AVS/CVV mismatches.