Test Transactions
Last updated: Sept 18th, 8:14pm
Before you activate your website or application for use by buyers, test your integration. A simulated payment network handles transactions, enabling you to verify the configuration and operation of your website or application. No money changes hands.
For detailed steps on how to integrate and test hosted checkout pages, see Set up and test hosted pages with Payflow Gateway.
Set Up the Payflow Gateway Testing Environment
Before testing transactions be sure you are linked to the test servers.
Direct all transactions to the host URL for testing. See Host URL Addresses. PayPal's simulated network processes transactions directed to the URL.
Testing Data and Guidelines
Processors Other than PayPal
Note: If your processor is PayPal but you are not using the PayPal Sandbox for testing, then you'd use the testing parameters in this section too.
Follow these guidelines for testing.
- While testing, use only the credit card numbers for testing. Other numbers produce an error.
- Expiration date must be a valid date in the future. Use the format
mmyy. - To view the credit card processor that you have selected for testing, see PayPal Manager.
Credit Card Numbers for Testing
The following credit card numbers are used for Payflow testing.
| Standard Test Cards | |
| American Express | 378282246310005 |
| American Express | 371449635398431 |
| American Express Corporate | 378734493671000 |
| Diners Club | 30569309025904 |
| Discover | 6011111111111117 |
| Discover | 6011000990139424 |
| JCB | 3530111333300000 |
| JCB | 3566002020360505 |
| Mastercard | 2221000000000009 |
| Mastercard | 2223000048400011 |
| Mastercard | 2223016768739313 |
| Mastercard | 5555555555554444 |
| Mastercard | 5105105105105100 |
| Visa | 4111111111111111 |
| Visa | 4012888888881881 |
| Visa | 4222222222222
Note: Even though this number has a different character count than the other test numbers, it is the correct and functional number. |
| HSA / FSA |
Note: These cards are only supported on Chase Paymentech Salem. |
| Visa | 4999991111111113 or 4999992222222229 |
| Mastercard | 5199999999999991 or 5299999999999990 |
Result Values Based on Amount Submitted
You can use the amount of the transaction to generate a particular result value. The following table lists the general guidelines for specifying amounts to submit in requests.
| Amount | Result |
|---|---|
|
|
RESULT value 0 (Approved) |
|
|
Certain amounts in this range return specific PayPal results. You can generate the results by adding $1000 to that RESULT value. For example, for RESULT value 13 (Referral), submit the amount 1013. If the amount is in this range but does not correspond to a result supported by this testing mechanism, Payflow returns RESULT value 12 (Declined). |
| $2001+ | RESULT value 12 (Declined) |
Result Values Based on Amount Submitted and Processor
This table lists the RESULT values that you can generate using the amount of
the transaction. To generate a specific value, submit an amount of 1000 plus the
RESULT value number (for example, submit an amount of 1013 for a RESULT
value of 13).
| Processing Platform | RESULT Values Available for Testing |
|---|---|
| American Express | 0, 12, 13, 104, 1000 |
| Elavon | 0, 12, 13, 104 |
| FISERV North | 0, 4, 5, 12, 13, 23, 24,114, 1000 |
| FISERV Nashville | 0, 12, 13, 104 |
| Global Payments | 0, 4, 5, 12, 13, 23, 24, 30, 100, 104, 114, 1000 |
| Paymentech Salem | 0, 12, 13, 104 |
| Paymentech Tampa | 0, 3, 4, 5, 12, 13, 23, 24, 1000 |
| PayPal (Payflow Simulator) | See Using the Payflow Simulator for testing |
| TSYS Acquiring Solutions | 0, 4, 12, 13, 23, 104, 114, 1000 |
| Vantiv | 0, 4, 5, 12, 13, 23, 24,114, 1000 |
Result Values Based on Alternate Generation Methods
The following table shows another method for obtaining RESULT values. Servers
do not return non-zero RESULT values from processors. Therefore, you cannot
simulate non-zero RESULT values using the amount. In some cases, you may
obtain certain results using the RESULT value plus 1000 even though this table
suggests an alternate means of obtaining the RESULT value.
| RESULT value | Definition | How to test using Payflow Gateway |
|---|---|---|
| 0 | Approved | Use an AMT of 1000 or less Credit (C) and force (F) transactions will always be approved regardless of dollar amount or card number |
| 1 | User authentication failed | Use an invalid PWD |
| 2 | Invalid tender | Use an invalid TENDER, such as G |
| 3 | Invalid transaction type | Use an invalid TRXTYPE, such as G |
| 4 | Invalid amount | Use an invalid AMT, such as -1 |
| 5 | Invalid merchant information | Use the AMT=1005. Applies only to the following processors: Global Payments and American Express |
| 7 | Field format error | Submit a delayed capture transaction with no ORIGID |
| 12 | Declined | Use the AMT=1012 or an AMT of 2001 or more |
| 13 | Referral | Use the AMT=1013 |
| 19 | Original transaction ID not found | Submit a delayed capture transaction with an invalid ORIGID |
| 22 | Invalid ABA number | Applies only to ACH transactions. Submit an invalid ABA number (eight digits) |
| 23 | Invalid account number | Submit an invalid account number, for example, 000000000000000 |
| 24 | Invalid expiration date | Submit an invalid expiration date, for example, 0298 |
| 25 | Transaction type not mapped to this host (Processor) | Submit a transaction for a card or tender you are not currently set up to accept, for example, a Diners card if you aren't set up to accept Diners |
| 29 | Invalid XML document | Pass a bad XML document (XMLPay users only) |
| 30 | Duplicate Transaction | Use the AMT=1030. Only applies to Global Payments. |
| 50 | Insufficient funds available | Use the AMT=1050. Only applies to Paymentech |
| 99 | General error | Use the AMT=1099. Only applies to Global Payments. |
| 100 | Invalid transaction returned from host (Processor) | Use the AMT=1100. Only applies to Global Payments. |
| 101 | Time-out value too small | Set timeout value to 1 |
| 103 | Error reading response from host (Processor) | Use the AMT=1103 |
| 104 | Timeout waiting for processor response | Use the AMT=1104 |
| 105 | Credit error | Attempt to credit an authorization |
| 108 | Void error | Attempt to void a captured authorization |
| 111 | Capture error | The attempt to capture failed. This may be that the transaction is not an authorization, the attempt to capture an authorization transaction has already been completed, or the amount of the capture is above the allowable limit of the authorization transaction. |
| 112 | Failed AVS check | You cannot generate this RESULT value by submitting an amount of 1112, but must submit a value for Address Verification Service that will fail; in production, this error occurs only if your account is configured by PayPal customer service to use the "AVS Deny" feature |
| 113 | Cannot exceed sales cap | Applies to ACH transactions only |
| 114 | CVV2 Mismatch | Use the AMT=1114. Only applies to TSYS Acquiring Solutions, Merchant e-Solutions and Global Payments. |
| 1000 | Generic Host (Processor) Error | Use the AMT=2000. Does not apply to Elavon, American Express, or Global Payments. |
Test the Address Verification Service
The Payflow testing server simulates address verification service by returning a
value for AVSADDR based on the first 3 characters of the submitted value for
BILLTOSTREET.
The testing server returns a value for AVSZIP based on the submitted
BILLTOZIP value as shown in the table.
If BILLTOSTREET starts with 667 or higher or begins with a non-numeric
character, then the simulator returns AVSADDR=X, AVSZIP=X.
The following table tests AVSADDR.
| Submitted Value for BILLTOSTREET | Example BILLTOSTREET Value | AVSADDR Result |
|---|---|---|
000-333 |
24285 Elm | Y |
334-666 |
49354 Main | N |
667 or higher or begins with a non-numeric character |
79232 Maple | X |
The following table tests AVSZIP.
| Submitted Value for BILLTOZIP | Example BILLTOZIP Value | AVSZIP Result |
|---|---|---|
00000-50000 |
00382 | Y |
50001-99999 |
94303 | N |
Any value (if street address is 667 or higher or begins with a non-numeric character) |
BILLTOSTREET=79232 Maple&BILLTOZIP=20304 |
X |
Test the Card Security Code
If you submit a value for the card security code, the card holder's bank returns
a Yes / No / Not Supported (Y / N / X) response on whether the value
matches the number on file at the bank. Card security code is described in "Card
Security Code Validation".
Note: Some processors will decline (RESULT value 12) a transaction if
the card security code does not match without returning a CVV2MATCH value.
Test the results and check with your processor to determine whether they
support card security code checking.
CVV2 value determine the CVV2MATCH result, as shown here.
Test CVV2MATCH
| CVV2 Value | CVV2MATCH Value |
|---|---|
000 |
Y |
001-300 |
Y |
301-600 |
N |
601 or higher |
X |
Processor is PayPal
For the PayPal processor, there ware two ways of testing based on how your account is setup:
- Using the Payflow simulator
- Using the PayPal sandbox
To verify which one is being used do the following:
- Login to PayPal Manager.
- Click on Service Settings.
- Click on Set Up under Hosted Checkout Page.
- Verify if an email is listed under PayPal Sandbox email address.
If an email address is listed, you are using the PayPal Sandbox and use the data below; otherwise use the testing data and guidelines under Processors Other than PayPal.
Note: Regardless of which testing service you are using, see PayPal Credit Card Transaction Request Parameters for the request parameters specific to the PayPal Processor.
Using PayPal Sandbox for Testing
Important: Payflow uses a set of specific credit card numbers for testing. However, PayPal allows you to generate card details which can be "real" numbers. Since PayPal requires you to setup two different accounts for production and sandbox, this doesn't cause any issues. However, with Payflow you use the same account for both production and pilot (sandbox) testing. The problem is that if you test using generated credit card numbers and you forgot to move your application from pilot to production, real credit cards will be approved, but will be invalid as they were posted to the pilot servers. You must make sure that once your testing is complete that you change the host URL from pilot to the production URLs.
For testing parameters for PayPal Sandbox using the following:
- Use the Credit Card Generator for Testing.
- Use the negative tests for Sandbox.
Using the Payflow Simulator for testing
The testing data below should only be used if you are using the Payflow Simulator and not the PayPal Sandbox.
Result Values Based on Amount
The following table shows another method for obtaining RESULT values. The
servers do not return non-zero RESULT values from processors.Therefore you
cannot simulate non-zero RESULT values using the amount. In some cases, you
may obtain certain results using the RESULT value plus 1000 even though this
table suggests another means of obtaining the RESULT value.
| Result | Definition | How to test |
|---|---|---|
| 0 | Approved | Use an AMOUNT of 10000 or less |
| 3 | Invalid transaction type | Use the AMOUNT 10402 |
| 4 | Invalid amount | Use any of these as AMOUNT:
|
| 5 | Invalid merchant information | Use any of these as AMOUNT:
|
| 7 | Field format error | Use any of these as AMOUNT:
|
| 12 | Declined | Use any of these as AMOUNT:
|
| 13 | Referral | Use the AMOUNT 10422 |
| 23 | Invalid account number | Use any of these as AMOUNT:
|
| 24 | Invalid expiration date | Use any of these as AMOUNT:
|
| 30 | Duplicate Transaction | Use the AMOUNT 10536 |
| 105 | Credit error | Attempt to credit an authorization |
| 112 | Failed AVS check | Use the AMOUNT 10505 |
| 114 | CVV2 Mismatch | Use the AMOUNT 10504 |
| 1000 | Generic Host (Processor) Error | Use an AMOUNT other than those listed in this column |
Litle Account Updater
The Litle Automatic Account Updater feature identifies outdated card information, "repairs" it, and substitutes new card information before submitting the transaction to the network. See the Litle Automatic Account Updater section for more information.
Merchants utilizing this feature should check for the presence of the
CCUPDATED=Y response parameter, and if it is returned, should also check for
the presence of the ACCT and EXPDATE response parameters to determine what
card information has been updated.
Merchants can test their integration for the Litle Automatic Account Updater feature in the Payflow pilot test environment by doing the following.
In the ACCT request parameter, pass one of the following testing card numbers:
Card number passed in ACCT request parameter |
Updated card number returned in ACCT response parameter |
|---|---|
| 4111111111111111 | 4321432143214321 |
| 4012888888881881 | 4012000033330026 |
| 5105105105105100 | 5454545454545454 |
| 5560136761278244 | 5105105105105100 |
Note: Only the last 4-digits of the updated credit card number will be returned.
In the EXPDATE request parameter, pass one of the following expiration dates:
Expiration date passed in EXPDATE request parameter |
Updated expiration date returned in EXPDATE response parameter |
|---|---|
| 0000 | 0919 |
| 1213 | 1218 |
| 0120 | 0150 |
| 0230 | 0250 |
| 0340 | 0350 |
In the AMT request parameter, pass an amount that falls within one of the
following ranges to bring about different account updater test cases:
Amount passed in AMT request parameter |
Test case |
|---|---|
1000.00
>
AMT >
= 500.00
|
Both an updated credit card number and an updated expiration date |
500.00
>
AMT >
= 400.00
|
Only an updated credit card number |
400.00
>
AMT >
= 300.00
|
Only an updated expiration date |