Request Format

All requests to the InterPay™ gateway are sent over HTTPS on port 1443. Both GET and POST methods are supported.

Send TERMID as the first field of every request.

Tag/Value Format

Requests are constructed by concatenating fields and values, separated by ampersands:

TERMID=MYTERM01&PASS=mypass&TYPE=W&ACTION=StartSession&AMT=125.00&[email protected]

Field values must be URL-encoded to allow special characters. If an ampersand (&) is needed within a field value, send it as a double ampersand (&&) to avoid confusion with field separators.

For structured data, fields can represent groups using nested brackets:

&PYMTS=[DATE=20260401&AMT=125.00][DATE=20260501&AMT=135.00]

JSON Format

Requests can be submitted as JSON in the body of a POST request with Content-Type: application/json:

{
  "TERMID": "MYTERM01",
  "PASS": "mypass",
  "TYPE": "W",
  "ACTION": "StartSession",
  "AMT": "125.00",
  "CUSTEMAIL": "[email protected]"
}

Structured data uses arrays of objects:

{
  "PYMTS": [
    { "DATE": "20260401", "AMT": "125.00" },
    { "DATE": "20260501", "AMT": "135.00" }
  ]
}

Send amounts as strings with exactly two decimals ("125.00"), not as numbers.

GET vs POST

Method	How to send data	When to use
GET	Fields in the query string	Quick browser-based testing
POST	Fields in the query string or the request body (tag/value or JSON)	Production integrations

Both methods produce the same result. GET is useful for early testing — you can paste a request URL into a browser and see the response directly. Use test credentials only with GET, since full URLs are often recorded in browser history and server logs.

Response Format

The gateway matches the response format to your request:

You send	You get back	Content-Type
Tag/value	Tag/value	`text/plain`
JSON body	JSON	`application/json`
Tag/value with `JSON=Y`	JSON	`application/json`

A JSON body always returns JSON, so JSON=Y is optional there. To get a JSON response to a tag/value request, include JSON=Y:

TERMID=MYTERM01&PASS=mypass&TYPE=W&ACTION=StartSession&AMT=125.00&JSON=Y

Standard Response Envelope

Every gateway response includes these fields:

Field	Description
`CODE`	Result code. `0000` means success. Any other value indicates an error or decline.
`TEXT`	Human-readable result message (e.g. `SUCCESS`, `APPROVED`, `DECLINED TEST`, `MISSING CUST EMAIL`).
`DATE`	Date the response was generated (`YYYYMMDD`).
`TIME`	Time the response was generated (`HH:MM:SS`).
`DUR`	Request processing duration in seconds (e.g. `0.412`).

Additional fields vary by request type and are documented in each method's Parameter Descriptions page.

Tag/value response example:

TEXT=SUCCESS&CODE=0000&SECUREID=1ef3a4c0-1234-6abc-b6f0-0607737344b4&URL=https://svra.interpaypos.com:1443/api/HOSTPYMT/pay/?SecureID=1ef3a4c0-1234-6abc-b6f0-0607737344b4&DATE=20260412&TIME=14:23:01&DUR=0.412

JSON response example:

{
  "CODE": "0000",
  "TEXT": "SUCCESS",
  "SECUREID": "1ef3a4c0-1234-6abc-b6f0-0607737344b4",
  "URL": "https://svra.interpaypos.com:1443/api/HOSTPYMT/pay/?SecureID=1ef3a4c0-1234-6abc-b6f0-0607737344b4",
  "DATE": "20260412",
  "TIME": "14:23:01",
  "DUR": "0.412"
}

Approved-Transaction Fields

The following fields are added automatically when a financial transaction is approved:

Field	When returned	Description
`AUTH`	Approved transactions	Authorization number from the card network
`GATEREF`	Approved financial transactions (Type `E`)	Gateway reference for settlement and reconciliation. Store this alongside your own transaction record.
`TOKEN`	When card data was processed	Permanent token for reusing this card on future transactions
`HASH`	When card data was processed	Hash of the card data for deduplication or fraud checks

These fields will not appear on declines, validation errors, or non-financial calls.

HTTP Status Codes

The gateway always returns HTTP 200 OK, including for declines and errors. Always check the CODE field in the response body to determine the result — do not rely on the HTTP status code.

Error Handling

Errors are returned in the same format as the request with a non-0000 CODE and a descriptive TEXT message.

Example error response:

{
  "CODE": "9014",
  "TEXT": "MISSING CUST EMAIL",
  "DATE": "20260412",
  "TIME": "14:25:33",
  "DUR": "0.003"
}

Check CODE on every response. A value of 0000 means the request succeeded. Any 9xxx code indicates a validation or gateway error. Any 0xxx code (other than 0000) indicates a decline from the card network.

If a gateway server does not respond or returns a 99xx error code, send the same request, unchanged, to the other gateway server. See Production for server URLs.

XML Format

XML responses are also supported by including XML=Y in the request. The response will be returned with Content-Type text/xml. JSON is recommended for new integrations.

Integration Checklist

Every integration should follow these rules. Each links to the page with full details.

All Gateway Requests

Send TERMID as the first field.
Send amounts as strings with exactly two decimals: "125.00", never 125 or 125.0.
Check CODE on every response. HTTP status is always 200, even for declines and errors.
REQUESTID is 5–20 digits only, and must be unique per terminal.
If a server doesn't respond or returns 99xx, retry the same request on the other gateway server. See Production.
Keep PASS on your server. Never include it in client-side code.

Hosted Payments (Customized Checkout and Embedded Components)

Never call GetResult before the customer returns to your SUCCESSURL or FAILUREURL. Calling it early cancels the session. See Customized Checkout Steps.
Don't rely on the Status parameter on your return URL. Confirm the result with a server-side GetResult.
Acknowledge every approved transaction within 3 minutes, or it is automatically reversed.
The cardholder's total is AMT + USERFEE + PLATFEE (where present). See CustomerPay.

Platform Billing

Send exactly one of PLATFORM, PLATFEE or PLATCHRG.
The Platform Fee is not refundable. Include PLATCHRG on the refund to return a Platform Charge. See Platform Billing.

Payment Schedules

Acknowledge each scheduled payment notification with a response body starting with OK. Notifications are sent as tag/value by default; ask SportsPay to switch your terminal to JSON. See Payment Schedules.

Onboarding and Provisioning

An application update replaces the whole application. Send every field, every time. See Onboarding.
Store each Merchant Credential Callback as a new record keyed on termID, never on orgID. See Merchant Provisioning.

Testing

Amounts ending in 1, or a card expiry month of 04, return DECLINED TEST. Avoid both when testing approvals. See Development & Testing.
Test and production credentials are always different.