Test your Application

Square provides developers with a test environment and tools that you can use to make the correct REST API calls to integrate your application with Square.

Overview Permalink Get a link to this section

You can use the following tools to help build and test your applications:

  • Square Sandbox. To learn about the fully segregated Sandbox test environment, see Sandbox Overview.

  • Square API Explorer. To learn about the Square-hosted API exploration tool that you can use to mock up Square API calls in an interactive experience, see API Explorer Overview.

  • API Logs. You can view the request and response for a Square API call by viewing it in API Logs.

  • Webhooks. You can use Square webhooks in both the Sandbox and in production to notify an application of webhook events. For more information about webhooks, see Webhooks Overview.

  • Postman. If you are familiar with Postman and want to see how it is used with Square APIs, see Postman Overview.

  • Command-line tools. Square APIs use the REST format so you can call Square APIs from a client command-line tool such as cURL or Windows PowerShell. To make the calls, you must have an access token. You can use a test account access token from the Developer Dashboard or your Sandbox personal access token to make the example API call.


Data created with Sandbox access tokens (such as customers and payments) appears in the Sandbox Seller Dashboard.

Data created with production access tokens appears in the Seller Dashboard, so exercise care before posting a request.

Testing for supported countries Permalink Get a link to this section

If you are a developer trying to build on Square APIs for a seller based in a Square-supported country, you should use the following test solutions:

  • Test eCommerce payment APIs for the account default country in the Sandbox. Use Sandbox default test account credentials to test payment-related APIs. For more information, see Test Square APIs in the Sandbox.

  • Test eCommerce payment APIs for other supported countries in the Sandbox. In the Sandbox, add a test account for the location you are testing and then use Sandbox credentials for that account to test payment-related APIs.

  • Test non-payment APIs or eCommerce payment APIs in production. Ask the seller who is based in a Square-supported country to provide you with a valid application ID, personal access token, or both. Because payments must use the currency of the seller account, you should hire beta testers in a Square-supported country to test your functionality before release. The Sandbox supports testing eCommerce payment APIs in the Sandbox environment and applies all payment validation rules to simulate production payments in that location. It is no longer necessary to test payments in production code.

  • Test in-person payment APIs. The Reader SDK and Point of Sale SDK are not supported in the Sandbox and Square hardware only works in Square-supported countries. Test payment requests for in-person payments in production using the CASH tender type.

The Square Reader SDK and Point of Sale API are not currently supported in the Square Sandbox and Square hardware only works in Square-supported countries. As a result, mobile developers of in-person applications must test in production with real credit cards. If you are a developer trying to build with a Square in-person mobile solution in supported regions, you should:

  • Start with cash. You can test cash payments without spending actual money using the CASH tender type.

  • Use small card payments. When you are ready to test card payments, you can charge small amounts, view the transaction details, and refund payments while in the Seller Dashboard.


    The In-App Payments SDK is supported in the Square Sandbox. To learn how to test your In-App Payments application, see Sandbox Payments.

Test Square APIs with a local web server Permalink Get a link to this section

To test asynchronous requests and code written in a server-side programming language (such as Node.js or PHP), you need access to a developer server or the ability to run a local web server (localhost). Running a local web server lets you render web pages locally in a browser without making them publicly available to other people.

To enable development and testing on local computers, some Square APIs have reduced security requirements when calls are made from localhost. For example, the Square payment form iframe does not load on HTTP websites unless they are served on localhost. To take advantage of these reduced security requirements when testing, you must serve local pages using the "localhost" keyword instead of an explicit IP address (such as

Some programming language interpreters include a built-in web server that you can use for development and testing purposes. To start a built-in web server:

  1. Open the Mac Terminal or Windows Command Prompt.

  2. Navigate to the root folder containing the code you want to test.

  3. Enter the language-specific command from the following table.

Language Local web server command Default URL
PHP $ php -S localhost:8000 http://localhost:8000
Rails $ rails server http://localhost:3000
Python $ python -m SimpleHTTPServer 8000 (Python 2)
$ python -m http.server 8000 (Python 3)
Node.js (Express framework) $ npm start No default. Must be explicitly configured programmatically:

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