Introduction
Introduction
The beginning of an awesome article...HTTP Message details When sending a message using POST, build a URL using the Praxell production domain name, which is api.praxell.com and the standard SSL port 443. (e.g. https://api.praxell.com/). Example of request message content: POST / URL HTTP/1.1 \r\n Content-Type: application/x-www-form-urlencoded \r\n Content-Length: LENGTH \r\n Host: api.praxell.com \r\n \r\n data=<?xml …> \r\n IP Restriction Systems communicating with Praxell API interfaces must be explicitly allowed on Praxell’ infrastructure. Customers must provide Praxell with its originating IP addressess for API calls.
XML Content
Praxell APIs are XML messages sent to the server, received by the client, and must adhere to the XML rules. Specifically, all free text fields which send special characters must be encoded properly (e.g. < should be <). Failing to encode the parameters will not pass the initial message parsing and will return an invalid message error response. If "not" required field was not sent (no XML tag) - the field's value will be empty in the database (it will have the same behavior as if the field has been sent with empty value).
Currencies and Formats
Currently, Praxell supports only the USD currency. The amounts used in the APIs are numbers without decimal points. For example, 99 is 99¢ and 212 is $2.12.
Common Request Message Structure
All messages are composed of a common part, which is made of the several consistent parameters; this part is made of several logical sub elements. The actual parameters used in this common structure documented below, the relevant sub elements are: • Common (Used in all Request APIs)
Authentication details (with an OR relation between them)
User name based authentication parameters
Card based authentication details
Terminal based authentication details
ClientSourceIP (Used in all Request APIs)
Optional field providing Source IP
Format: XXX.XXX.XXX.XXX (ivp4) (ivp6 values are not supported)
Non repudiation and duplication
In order to avoid executing multiple requests, which are identical, the API server requests a unique request identifier for each API call.
The uniqueness of a request is checked only after a successful authentication login has been performed, which implies that the user and customer already authenticated and recognized by the system.
This unique identifier managed on the level of the requester
Customer A can send request ID 111, as can Customer B
Customer A cannot send request ID 111 more than once
SQL injection prevention & special characters
In order to prevent SQL injection attacks, all free text fields (e.g. description) are verified using several positive and negative validation components and are limited in the characters they can contain. Specifically, these fields cannot contain the “single quote character” (‘); however “"e;” can be sent, will be stored, and returned upon retrieval a “tab” will be taken as a “null” value and will be ignored.
Last updated