API Request & Response General Structure

This page describes the structure that all Hyp API requests should follow, as well as the structure of the responses you receive from Hyp. This is a general overview that applies to all commands and requests, regardless of the specific command you are using.

Request

Every Hyp API call involves sending a POST request to the Hyp CreditGuard API endpoint https://your-hyp-environment-url/xpo/Relay, where your-hyp-environment-url should be replaced with the test or production base URL provided to you during registration.

Every API call includes three parameters in the body that represent your API credentials (the user and password parameters) and transaction details (the int_in parameter):

curl -X POST --location "https://your-hyp-environment-url/xpo/Relay" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d 'user=your-api-username&password=your-api-password&int_in=xml-payload'

In the int_in parameter, include transaction details in the form of a URL-encoded XML payload. The basic structure of the XML payload is always as follows:

<ashrait>
  <request>
    <version>2000</version>
    <language>{language}</language>
    <command>{commandName}</command>
    <{commandName}>
        ...
    </{commandName}>
  </request>
</ashrait>

Every request must include the ashrait root element, which contains a request element.

The request element contains several child elements that provide information about the request:

  • version defines the version of the API being used. Current implementations should use 2000.

  • language defines the language of text values in the response. If a request is for a payment page, it also defines the UI language in the payment page. Use HEB for Hebrew or ENG for English. Other language codes are not supported and will fall back to English.

  • command is the name of the command you want to perform. The value of command must match the commandName element name.

  • commandName: this is a command-specific element that contains the parameters for the specific command you are invoking. The name of this element must match the value of the command element. For the list of available commands, see the Commands section below.

Other elements that may be included as direct children of the request element in certain circumstances are:

  • mayBeDuplicate: indicates that the current request could be a duplicate of a previous request, which can be useful following a server timeout after sending the previous request. If set to 1, Hyp checks whether the transaction has already been made and if all the details of the current request are identical to the previous request. If the two requests are identical, Hyp checks the completion status of the previous request. If it is complete, Hyp simply re-sends the response. If the previous request is incomplete, Hyp completes the transaction and returns the response. Using mayBeDuplicate requires the merchant to generate and include a unique requestId with every transaction (see below). This element requires explicit terminal configuration. If not used, this element can be omitted, left empty, or set to 0.

  • requestId: request ID if generated by the merchant. This is optional in most cases but becomes required if the mayBeDuplicate element is used. In this case, the requestId value should be a string up to 20 characters that is explicitly included in every request.

This is an example of an XML payload that includes the doDeal command to request a payment page:

For more details on requesting a payment page, see Integrating Hyp's Payment Page and Accepting Payment.

Response

The response is returned in XML format. It's structured similarly to the XML payload in the request:

In the response:

  • command, requestId, version, and language elements are exactly the same as in the request.

  • dateTime contains a timestamp of the response in the format YYYY-MM-DD hh:mm.

  • tranId is the transaction ID assigned by Hyp to the handled request. This ID is unique for each transaction request and can be used to track it.

  • result contains the 3-digit result code of the command execution. Successful commands return 000, while errors return a specific code.

  • message contains a technical description of the result, which can be used for debugging or logging purposes. In responses with result code 000, this element reads "Permitted transaction".

  • userMessage contains a user-friendly message that can be displayed to the end user. In responses with result code 000, this element reads "Permitted transaction".

  • additionalInfo may contain additional details about the command execution.

  • {commandName} contains a mix of parameters you specified for the command in the request and the result of its execution.

Here's an example of a response for an inquireTransactions command. This is a successful response, as evidenced by the 000 value of the result element:

Show response

In case of an error response, the error code is provided in the result element, the message element contains a technical description of the error, userMessage contains a user-friendly message that can be displayed to the end user, and the command-specific element is not returned.

Here's an example of an error response for a refundDeal command:

Show response

Commands

Below is a list of commands supported by the Hyp API, along with links to their respective API reference pages and general documentation covering their usage.

Last updated

Was this helpful?