Getting started

Getting started with the Squarepay API is simple, on signup you would have already received access to your Sandbox Portal and API keys.

Environments

The following environment are made available such that developers maybe fully test their integrations before moving to live.

Environment	API URL	Portal URL
Sandbox	https://api-sandbox.squarepay.com.au/v2	https://portal-sandbox.squarepay.com.au
Live	https://api.squarepay.com.au/v2	https://portal.squarepay.com.au

TIP

Please be aware our PayTo API implementation has been versioned and is accessible on Version 2 of our API /v2/.

All requests made to the Squarepay API must be via HTTPS. Any requests made over a non-secure transmission are simply ignored.

The PayTo API Reference can be found here: https://api-docs.squarepay.com.au

Authentication

All requests to our API require your private API key. This key is unique to you and should be kept safe, do not use in client-side code or any place that is publicly accessible.

Squarepay API uses HTTP Basic Auth to authenticate requests. Simply provide your API key as the basic auth username value and leave the password blank (empty string).

For example if your API key was your-super-secret-apikey-keep-me-safe, the resulting header value would be eW91ci1zdXBlci1zZWNyZXQtYXBpa2V5LWtlZXAtbWUtc2FmZTo=, the resulting request header being:

Authorization: Basic eW91ci1zdXBlci1zZWNyZXQtYXBpa2V5LWtlZXAtbWUtc2FmZTo=

IMPORTANT

See our API reference on how to Authenticate - https://api-docs.squarepay.com.au

How to manually compute the header

If your chosen language does not support HTTP Basic Authentication, you may manually compute the header and attach the header to your request. This can be achieved by following:

1. Concatenate your {apikey} and :.
2. Base 64 encode the computed string above.
3. Assign the base 64 encoded string to tge Authorization header in all requests.

Breaking vs Non-Breaking Changes

TIP

Please read the below carefully to ensure your implementation can handle additions to this API.

To allow Squarepay to continuously to innovate and regularly update our API's, the following rules are followed. Where a breaking change is required, we will create a new version of the API and maintain the previous versions.

Non-Breaking Changes

The following changes are permitted by us to allow for continuous innovation and allows us to regularly update our API with improvements.

• Adding new API endpoints and consequently new versions of the API.
• Implementing new HTTP verbs.
• Adding optional request parameters to existing API endpoints.
• Adding new properties to the responses from existing API endpoints.
• Adding new response header information.
• Reordering properties returned from existing API endpoints.
• Altering the message attribute returned by validation failures / other errors.
• Altering the format or length of IDs - These strings will never exceed 64 characters, but you should be able to handle anything up to that length.
• Adding or removing TLS ciphers.
• Changing supported TLS versions.
• Changing the SSL certificate or the certificate issuer.

Breaking Changes

Anything outside the Non-Breaking changes is considered a breaking change. Some examples are listed below:

• Removing and renaming parameters to existing API endpoints.
• Removing or changing the location of a resource.
• Changing existing API endpoints.

Idempotency

All HTTP requests that result in creating a new resource are able to enforce idempotent behaviour. This identifier is required when creating new PayTo Agreements and Payments.

Rate Limiting

To offer a high availability service we rate limit all API endpoints.

Each request made to the API will return HTTP header information in the response to indicate the current rate limit status. These rate limits reset every minute.

Exceeding the rate limit results in a rate_limit_exceeded error as detailed in the error types section.

Date and Time

All responses will have date times formatted as yyyy-mm-ddTHH:MM:SS, e.g. 2024-01-16T16:00:30.

Any Endpoints that require a timestamp as a request parameter, please use the format yyyy-mm-ddTHH:MM:SS e.g. 2014-01-16T16:45:15.

For endpoints that require a date as a request parameter, please use the format yyyy-mm-dd e.g. 2024-01-16.

TIP

Note: Sorry we don't store time zone information. Please assume all timestamps to be relative to Sydney time (AEST). Across Australia all banks operate on Sydney time, despite their location.

Asynchronous Operations

Our API is designed to be asynchronous to maintain consistently fast response times. As such to determine the outcome of your request, you may choose to implement one or both of the methods below:

• Webhooks - Each outcome will fire a webhook to notify your application in real-time the result of the transaction.
• Polling - In the event an outcome needs to be checked out of sequence, the resource may be queried directly until an outcome has been met.