Test your app

Before you deploy your application to production and let merchants process real customer transactions, it is important that you adequately test your application.

Development environment

We recommend first developing and testing your application in the development environment. Doing so will help ensure that:

The test environment is not connected to the production payment gateway, so all your transactions are simulated. They also settle immediately, so you can not void transactions.

Production environment

In order to understand the authorization and settlement of transactions and to test your application in real world conditions, it is important that you test your application in production before you deploy. This will ensure:

Tip

To list your app on QuickBooks Apps.com, you must include the Accounting API.

OAuth access tokens

The OAuth access token is an important item that links a specific merchant to a specific application in a given environment (development or production). It enables an application to process requests on behalf of the merchant through the Payments REST API. If the access token is not valid, then an authentication error will be returned in the response. Click hereto learn more about OAuth access token management.

Testing Credit Card Transactions

Credit cards are specified in the following contexts:

Click here for further information about credit card processing with the Payments API.

Emulating credit card numbers

When your application is using the sandbox environment, all transaction requests are sent to an emulated version of Intuit Payments. Use credit card test numbers in the table below to emulate real-world transactions. This request processing is emulated in order to return appropriate responses—no real processing takes place. The AVS values, CVS values, account limits, and status are not checked. The card number is checked against the valid card numbers listed below and the expiration date is checked against the current date.

Card Type Test Number
MasterCard 5111005111051128
AMEX 378282246310005
Visa 4112344112344113
Diners 36438999960016
Discover 6011000995500000
Discover 6510000000000000069
JCB 3530111333300000
Emulating credit card transaction failures

Use the test cardholder names listed in the following table to emulate various transaction failures in the sandbox environment. These names trigger the real world responses such that you can code your app to appropriately handle the situation. As an example, here is a sample transaction request to the charges resource using card.name of emulate=10301 to trigger an invalid card error:

Sample Charges request body

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
{
    "amount": "10.55",
    "card": {
       "expYear": "2020",
       "expMonth": "02",
       "address": {
          "region": "CA",
          "postalCode": "94086",
          "streetAddress": "1130 Kifer Rd",
          "country": "US",
          "city": "Sunnyvale"
       },
       "name": "emulate=10301",
       "cvc": "123",
       "number": "4111111111111111"
    },
    "currency": "USD"
}

emulate=10201

emulate=10301

emulate=10401

Payment system error.

1
2
3
4
5
6
7
8
{
   "errors": [{
      "code": "PMT-6000",
      "type": "system_error",
      "message": "A temporary issue prevented this request from being processed.",
      "infoLink": "https://developer.intuit.com/v2/docs?redirectID=PayErrors"
   }]
}

Card number is invalid.

1
2
3
4
5
6
7
8
9
{
   "errors": [{
      "code": "PMT-4000",
      "type": "invalid_request",
      "message": "card.number is invalid.",
      "detail": "card.number",
      "infoLink": "https://developer.intuit.com/v2/docs?redirectID=PayErrors"
   }]
}

General decline.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
{
   "created": "2015-11-04T17:27:06Z",
   "status": "DECLINED",  <---EMULATED STATUS
   "amount": "10.55",
   "currency": "USD",
   "card": {
      "number": "xxxxxxxxxxxx1111",
      "name": "emulate=10401",  <---EMULATED NAME
      "address": {
         "city": "Sunnyvale",
         "region": "CA",
         "country": "USA",
         "postalCode": "94086",
         "streetAddress": "1130 Kifer Rd"
      },
      "cardType": "Visa",
      "expMonth": "02",
      "expYear": "2020"
   },
   "capture": true,
   "avsStreet": "Pass",
   "avsZip": "Pass",
   "cardSecurityCodeMatch": "NotAvailable",
   "id": "EIS8H1O39X76",
   "context": {
      "recurring": false,
      "isMobile": false
   },
   "authCode": "372060"
}
Credit card void

The sandbox development environment considers transactions settled by default, and void transactions cannot succeed on settled transactions; the error 10405 would be returned in this case.

Testing EChecks transactions

Use this checking account information when testing echeck transactions.

Entry Test Number
Routing Number 322079353
Account Number 11000000333456781
Transaction amount testing

The table below describes values that can be used to test EChecks transactions.

Disclaimer: Any dollar amount debited that is not in the table below will have a default status of “PENDING”.

Value Returned Status
$1.11 PENDING
$2.22 PENDING
$3.33 DECLINED
$4.44 DECLINED
$5.55 SUCCEEDED
Refund testing

This table provides sample values that can be used to test EChecks refunds.

Note: The original debit amountmustbe $5.55.

Value Returned Status
$1.11 PENDING
$2.22 PENDING
$3.33 DECLINED
$4.44 DECLINED
$5.55 SUCCEEDED
Void status testing

To generate a VOIDED status, issue a debit that has a value other than $3.33, $4.44, or $5.55 and then issue a refund for the debit with an empty payload.