A quick reference of test credit card numbers and payment tokens you can use to make test payments with the Square Sandbox.

Sandbox Payments

The Square Sandbox can be used for testing Square API calls. Some of the APIs require special test values when creating transactions in the Sandbox, especially when processing test payments.

Square platform clients, such as Web Payments SDK and In-App Payments SDK applications, accept payment cards and return one-time-use encrypted payment tokens to be submitted to Square API payment endpoints to take payments. You can avoid testing your code with a real payment card by testing in the Sandbox.


The Sandbox does not accept valid credit cards. You must use test credit card values found in the following sections.

Test client-side card-present logic in your Web Payments SDK or In-App Payments SDK application by using test credit card numbers to generate payment tokens for use with the Square API payments and card-on-file endpoints in the Sandbox.

If you do not need to test your client-side payment token logic, use the test payment tokens provided in the Square endpoint testing section to submit payments in the Sandbox.

You can use Sandbox credit cards with the Web Payments SDK and In-App Payments SDK to input card numbers that generate a payment token for Sandbox testing.

The Sandbox supports a collection of credit card numbers for all Square-supported card brands for simulating the client side of payment scenarios.

Visa4111 1111 1111 1111111
Mastercard5105 1051 0510 5100111
Discover6011 0000 0000 0004111
Diners Club3000 000000 0004111
JCB3569 9900 1009 5841111
American Express3400 000000 000091111
China UnionPay6222 9888 1234 0000123
Square Gift Card7783 3200 0000 0000


  • You can set the card expiration date to any future month and year.

  • Payments in USD (United States), CAD (Canada), or GBP (United Kingdom) require a valid postal code.

  • The Sandbox simulates the use of payment cards in Square-supported countries. In production, card brand and country support might be different. Before releasing your application into production, review Supported Payment Methods by Country.

The Sandbox supports ACH bank transfer payments by accepting the test user name user_good and the test password pass_good. These test values are provided by the Plaid API and might change in the future. For more information, see the Plaid Sandbox test credentials page.

You can reproduce certain error states in the Sandbox by providing special values in the Web Payments SDK or In-App Payments SDK.

If you use one of the following values, the returned payment token generates an error when it is processed by the CreatePayment endpoint.

Test valuesDesired error state
CVV: 911Card CVV incorrect
Postal code: 99999Card postal code incorrect
Expiration date: 01/40Card expiration date incorrect
Card number: 4000000000000002Card declined number
PAN: 4000000000000010Card on file auth declined

To test SCA in the Square Sandbox, you should use a payment token returned by the Web Payments SDK. To test different SCA scenarios, use the cards provided in the following table.

Use the Payments.verifyBuyer function for card-present and card-on-file (CoF) SCA challenges with the following test values.

CVVChallenge typeVerification code
Visa4800 0000 0000 0004111No ChallengeN/A
Mastercard5222 2200 0000 0005111No ChallengeN/A
Discover EU6011 0000 0020 1016111No Challenge123456
Visa EU4310 0000 0020 1019111Modal with Verification Code123456
Mastercard5248 4800 0021 0026111Modal with Verification Code123456
Mastercard EU5500 0000 0020 1016111Modal with Verification Code123456
American Express EU3700 000002 010141111Modal with Verification Code123456
Mastercard5333 3300 0000 0008111Modal with Multiple Verification QuestionsChallenge 1: Thomason
Challenge 2: Select both St Louis & Dallas
Challenge 3. Smith
Visa4811 1100 0000 0008111No Challenge with Failed VerificationN/A

The SCA flow requires buyers to provide a code sent to their mobile phone in an SMS message. When testing in the Sandbox, use the verification code to simulate the code sent using SMS.


  • With cards that do not have challenges, the card completes the SCA process without the need for a verification window.

  • The Web Payments SDK generates a verification token for each call to verifyBuyer (except when a buyer cancels the SCA challenge). The seller should pass the verification token when it is used to create a payment or store a payment card. The seller should be prepared for situations where Square or the issuer bank might reject the payment or reject storing the payment card. An example of this is the issuer bank determines that the payment request is suspicious and marks it as a fraud transaction or the bank locks the buyer's account.

  • In the Sandbox, verifyBuyer creates a buyer challenge across all regions, mandated or otherwise. In production, you only see a buyer challenge for mandated regions.

The SCA flow and these test values are not supported in the legacy Sandbox.

Test your payments logic that uses the CreatePayment endpoint to take a payment or the CreateCard endpoint to store a customer's card on file.

If you are using the Square Payments API to generate payments in the Sandbox, you can use one of the Sandbox test payment tokens as the source_id in the payment request.

Use the values in the following table with calls to the CreatePayment endpoint that succeed in creating a payment.

Payment field: source_idPayment method
ccof:customer-card-id-okCard on file
cnon:gift-card-nonce-okSquare gift card
ccof:customer-card-id-requires-verificationCard (SCA)

In addition, if you want to test errors in the Square CreatePayment endpoint, you can use the following test values.

source_id valueError mapping
Card present. cnon:card-nonce-rejected-cvvBad CVV
Card present. cnon:card-nonce-rejected-postalcode
Card on file. ccof:customer-card-id-rejected-postalcode
Bad postal code
Card present. cnon:card-nonce-rejected-expiration
Card on file. ccof:customer-card-id-rejected-expiration
Bad expiration date
Card present. cnon:card-nonce-declined
Card on file. ccof:customer-card-id-declined
Card declined
Card present. cnon:card-nonce-already-usedCard payment token already used
Card present. cnon:gift-card-nonce-insufficient-fundsGift card insufficient funds
Card present. cnon:gift-card-nonce-insufficient-permissionGift card no permissions

source_id valueError mappingExpected behavior
bnon:bank-nonce-okThe request is successful.
bnon:bank-nonce-failureGENERIC_DECLINEThe request failed.
bnon:bank-nonce-account-unusableACCOUNT_UNUSABLEThe request failed.
bnon:bank-nonce-insufficient-fundsINSUFFICIENT_FUNDSThe request failed.
bnon:bank-nonce-invalid-accountINVALID_ACCOUNTThe request failed.
bnon:bank-nonce-buyer-refused-paymentBUYER_REFUSED_PAYMENTThe request failed.

Note the following:

  • The resulting payment has PENDING as the initial status, which updates to COMPLETED after 1 minute.

  • For failed requests, the resulting payment has PENDING as the initial status, which updates to FAILED after 1 minute.

source_id valueError mappingExpected behavior
wnon:afterpay-or-clearpay-okThe request is successful.
wnon:afterpay-or-clearpay-declinedGENERIC_DECLINEThe request failed.

source_id valueError mappingExpected behavior
wnon:cash-app-okThe request is successful.
wnon:cash-app-declinedGENERIC_DECLINEThe request failed.

You can also use the following test values to create payments using CreatePayment. The benefit of using these token values is that updates to these payments using UpdatePayment always return the following predictable results.

source_id value
Error mappingExpected behavior
cnon:card-nonce-okThe request is successful.
cnon:card-edit-not-allowedBAD_REQUESTThe Payment created using this token has no capabilities. As a result, any UpdatePayment request to update the amount or tip fails.
cnon:card-edit-down-onlyBAD_REQUESTThe Payment created using this token has EDIT_AMOUNT_DOWN and EDIT_TIP_AMOUNT_DOWN capabilities. An UpdatePayment request that reduces these amounts succeeds. However, any attempt to increase these amounts fails.
cnon:card-edit-tip-failureAMOUNT_TOO_HIGHUpdatePayment always returns a tip too high error.
cnon:card-edit-failureAMOUNT_TOO_HIGHUpdatePayment always returns an amount too high error.

In the Sandbox, the following payment amounts in a CreatePayment request generate a Payment object with risk_evaluation identifying the specific risk levels.

Charge amountRisk level
other valuesNORMAL

If you need more assistance, contact Developer Support or ask for help in the Developer Forums.