Test Transactions

Last updated: October 12th 2021, @ 6:58:00 pm


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 Express378282246310005
American Express371449635398431
American Express Corporate378734493671000
Diners Club30569309025904
Discover6011111111111117
Discover6011000990139424
JCB3530111333300000
JCB3566002020360505
Mastercard2221000000000009
Mastercard2223000048400011
Mastercard2223016768739313
Mastercard5555555555554444
Mastercard5105105105105100
Visa4111111111111111
Visa4012888888881881
Visa4222222222222
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.
Visa4999991111111113 or 4999992222222229
Mastercard5199999999999991 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.

AmountResult
$0 - $1000RESULT value 0 (Approved)
$1001 - $2000Certain 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 PlatformRESULT Values Available for Testing
American Express0, 12, 13, 104, 1000
Elavon0, 12, 13, 104
FISERV North0, 4, 5, 12, 13, 23, 24,114, 1000
FISERV Nashville0, 12, 13, 104
Global Payments0, 4, 5, 12, 13, 23, 24, 30, 100, 104, 114, 1000
Paymentech Salem0, 12, 13, 104
Paymentech Tampa0, 3, 4, 5, 12, 13, 23, 24, 1000
PayPal (Payflow Simulator)See Using the Payflow Simulator for testing
TSYS Acquiring Solutions0, 4, 12, 13, 23, 104, 114, 1000
Vantiv0, 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 valueDefinitionHow to test using Payflow Gateway
0ApprovedUse an AMT of 1000 or less
Credit (C) and force (F) transactions will always be approved regardless of dollar amount or card number
1User authentication failedUse an invalid PWD
2Invalid tenderUse an invalid TENDER, such as G
3Invalid transaction typeUse an invalid TRXTYPE, such as G
4Invalid amountUse an invalid AMT, such as -1
5Invalid merchant informationUse the AMT=1005. Applies only to the following processors: Global Payments and American Express
7Field format errorSubmit a delayed capture transaction with no ORIGID
12DeclinedUse the AMT=1012 or an AMT of 2001 or more
13ReferralUse the AMT=1013
19Original transaction ID not foundSubmit a delayed capture transaction with an invalid ORIGID
22Invalid ABA numberApplies only to ACH transactions. Submit an invalid ABA number (eight digits)
23Invalid account numberSubmit an invalid account number, for example, 000000000000000
24Invalid expiration dateSubmit an invalid expiration date, for example, 0298
25Transaction 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
29Invalid XML documentPass a bad XML document (XMLPay users only)
30Duplicate TransactionUse the AMT=1030. Only applies to Global Payments.
50Insufficient funds availableUse the AMT=1050. Only applies to Paymentech
99General errorUse the AMT=1099. Only applies to Global Payments.
100Invalid transaction returned from host (Processor)Use the AMT=1100. Only applies to Global Payments.
101Time-out value too smallSet timeout value to 1
103Error reading response from host (Processor)Use the AMT=1103
104Timeout waiting for processor responseUse the AMT=1104
105Credit errorAttempt to credit an authorization
108Void errorAttempt to void a captured authorization
111Capture errorThe 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.
112Failed AVS checkYou 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
113Cannot exceed sales capApplies to ACH transactions only
114CVV2 MismatchUse the AMT=1114. Only applies to TSYS Acquiring Solutions, Merchant e-Solutions and Global Payments.
1000Generic Host (Processor) ErrorUse 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 BILLTOSTREETExample BILLTOSTREET ValueAVSADDR Result
000-33324285 ElmY
334-66649354 MainN
667 or higher or begins with a non-numeric character79232 MapleX

The following table tests AVSZIP.

Submitted Value for BILLTOZIPExample BILLTOZIP ValueAVSZIP Result
00000-5000000382Y
50001-9999994303N
Any value (if street address is 667 or higher or begins with a non-numeric character)BILLTOSTREET=79232 Maple&BILLTOZIP=20304X

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 ValueCVV2MATCH Value
000Y
001-300Y
301-600N
601 or higherX

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:

  1. Login to PayPal Manager.
  2. Click on Service Settings.
  3. Click on Set Up under Hosted Checkout Page.
  4. 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:

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.

ResultDefinitionHow to test
0ApprovedUse an AMOUNT of 10000 or less
3Invalid transaction typeUse the AMOUNT 10402
4Invalid amountUse any of these as AMOUNT:
  • 10400
  • 10401
  • 10403
  • 10404
5Invalid merchant informationUse any of these as AMOUNT:
  • 10548
  • 10549
7Field format errorUse any of these as AMOUNT:
  • 10405
  • 10406
  • 10407
  • 10408
  • 10409
  • 10410
  • 10412
  • 10413
  • 10416
  • 10419
  • 10420
  • 10421
  • 10509
  • 10512
  • 10513
  • 10514
  • 10515
  • 10516
  • 10517
  • 10518
  • 10540
  • 10542
12DeclinedUse any of these as AMOUNT:
  • 10417
  • 15002
  • 15005
  • 15006
  • 15028
  • 15039
  • 10544
  • 10545
  • 10546
13ReferralUse the AMOUNT 10422
23Invalid account numberUse any of these as AMOUNT:
  • 10519
  • 10521
  • 10522
  • 10527
  • 10535
  • 10541
  • 10543
24Invalid expiration dateUse any of these as AMOUNT:
  • 10502
  • 10508
30Duplicate TransactionUse the AMOUNT 10536
105Credit errorAttempt to credit an authorization
112Failed AVS checkUse the AMOUNT 10505
114CVV2 MismatchUse the AMOUNT 10504
1000Generic Host (Processor) ErrorUse 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 parameterUpdated card number returned in ACCT response parameter
41111111111111114321432143214321
40128888888818814012000033330026
51051051051051005454545454545454
55601367612782445105105105105100

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 parameterUpdated expiration date returned in EXPDATE response parameter
00000919
12131218
01200150
02300250
03400350

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 parameterTest case
1000.00 > AMT >= 500.00Both an updated credit card number and an updated expiration date
500.00 > AMT >= 400.00Only an updated credit card number
400.00 > AMT >= 300.00Only an updated expiration date