Submitting requests

Looking for some tips to get started? The following section covers how you should construct your API messages, where you should send them for testing and live processing plus information about response codes and messages.

Get your credentials

In order to handle your request securely and reliably, you will need to submit credentials specific to your organisation with each request. You will also be issued with at least one installation identifier. If your company has multiple websites you may have a separate installation for each.

To get credentials for our Merchant Integration Test Environment (MITE), sign up for an Explorer account. You can use this environment to explore our products and start your integration. We’ll email you all the information you need to start using:

Our Implementations team will provide your Live credentials once your integration is complete and your account is set up and ready to use.

Endpoints

All requests to our services must be submitted as HTTPS using TLS v1.2 or higher.

Use the following endpoints to submit requests:

MITE Endpoints

API Requests
https://api.mite.pay360.com

LIVE Endpoints

API Requests
https://api.pay360.com

Anatomy of a request

All of our API requests are submitted as a URL. This is of the form:

<endpoint path><request path>

For example, a new transaction in the test environment might be:

https://api.mite.pay360.com/acceptor/rest/transactions/{instId}/{resourceId}/action

Additionally, the request path for our server-to-server APIs calls have the following structure:

Base URL
The base URL for our rest services.

Examples:

https://api.pay360.com

Resource Type
The type of resource you are submitting the request for.

Examples:

/acceptor/rest/transactions

/acceptor/rest/customers

/hosted/rest/sessions

InstId
The ID for your installation as provided by our Client Management team.
ResourceID
The ID for a resource either being fetched or operated on. This isn’t present when creating a new resource.

Examples:

/<CustomerID>

/<TransactionID>

/<CustomerID>/cards/<tokenID>

Action
The action being performed.

Examples:

/payment

/refund

The body of the requests and responses uses the JSON format. All our requests are either POST or GET. When the operation is successful the response code will be a 200, or 201 in the case where a new resource is created.

Our APIs are continuously evolving. We will not take any fields away without giving advanced notice, but we may add new response fields at any time. Your integration must be able to cope with the appearance of new fields.

Your credentials need to be sent with every request in the header using the HTTP Basic format, for example:

Accept: application/json
Content-Type: application/json
Authorization: Basic cGF5cG9pbnQubmV0IHVzZXJuYW1lOnBhc3N3b3JkcGFzc3dvcmRwYXNzd29yZA==

Testing connectivity

You can test basic connectivity to our services using a Ping request:


APIHosted

API Examples

Ping


Detail
GET /acceptor/rest/transactions/ping
HTTP/1.1 200

API Endpoint
endpoint: /acceptor/rest/transactions/ping
method: GET
summary: ping


Hosted Examples

Ping


Detail
GET /hosted/rest/sessions/ping
HTTP/1.1 200

Hosted Endpoint
endpoint: /hosted/rest/sessions/ping
method: GET
summary: test connectivity