Introduction
Omniware is a full-stack payments platform that lets you accept money, send money, bill customers, and onboard sub-merchants from a single set of APIs.
This documentation covers every endpoint you'll need to integrate.
Accept payments via cards, UPI, net banking, wallets, EMI, BharatQR, and more on a hosted page or seamlessly on your own UI.
Disburse funds to vendors and customers over NEFT/IMPS with real-time status callbacks.
Programmatically create, dispatch, and reconcile invoices that customers pay through a hosted link.
Register sub-merchants on Omniware from your own dashboard with an encrypted API.
How the platform fits togetherโ
Solid arrows are synchronous API calls. Dotted arrows are asynchronous callbacks Omniware fires back to your server.What every Omniware API has in commonโ
- HTTPS POST
All endpoints accept
POSTover HTTPS. Most expectapplication/x-www-form-urlencoded; a few accept JSON (noted per endpoint). - api_key + hash auth
Every request includes your
api_keyand a SHA-512hashof the request parameters salted with yoursalt. See Authentication and Hash calculation. - JSON responses
Responses are JSON. Successful responses contain a
dataobject; failures contain anerrorobject withcodeandmessage. See Error handling. - Verify the response hash
Many endpoints return a
hashin the response. Recompute it on your side to defend against tampering before treating the response as final.
Get your credentialsโ
You'll need four secrets to integrate. They are issued by Omniware at onboarding and visible in your dashboard.
| Credential | Purpose |
|---|---|
api_key | Identifies your merchant account on every request. |
salt | Used in SHA-512 hash calculations. Server-side only. |
encryption_key | AES key for encrypting payment requests (when using encrypted variants). |
decryption_key | AES key for decrypting payment responses returned on return_url. |
Treat salt, encryption_key, and decryption_key like passwords. Never expose them in HTML forms, mobile binaries, or client-side JavaScript.