Authentication
Every Omniware API request is authenticated with two parameters: api_key (who you are) and hash (a SHA-512 signature of the request that proves the body has not been tampered with).
api_key
A 36-character UUID issued at onboarding. It is scoped to a single login/business; if you have multiple login accounts you'll receive one api_key per account.
The api_key is not secret in the way the salt is — it appears in every request — but you should still avoid exposing it in client-side code that you don't control.
hash
A SHA-512 hex digest, uppercased, of:
salt | sorted(value_1) | sorted(value_2) | ... | sorted(value_N)
where values are taken from your request parameters in alphabetical-by-key order, skipping any field whose value is empty. The hash field itself is never included in the hash input.
Full algorithm and code samples in every language: Hash calculation.
Step-by-step algorithm with cURL, PHP, Node.js, Python, and Java samples — plus the response-hash verification flow.
Why both?
api_key tells Omniware which merchant to bill / route to. hash proves that the message you sent has not been altered in flight (or by a malicious user on their browser tab). Together they replace the traditional "API token in an Authorization header" pattern with a body-bound signature, which lets Omniware safely accept requests over HTML form posts as well as server-to-server calls.
Response integrity
Many endpoints — notably the Payment Request return callback and Payment Status — include a hash in the response. Recompute it on your side before treating the response as final. A malicious end-user can intercept a redirect and flip FAILED to SUCCESS, but they cannot forge a hash without your salt.
Encrypted variants
For higher-assurance flows, Omniware provides AES-encrypted versions of the Payment Request and Merchant Registration APIs. The api_key stays in plaintext (so the gateway knows which key to use to decrypt), but the rest of the body is encrypted. See Encryption.