Build with server-side credentials
Keep merchant API keys in trusted backend services. Browser applications should use only approved public flows and never receive privileged secrets.
Developers
Use governed APIs, webhooks and a controlled integration path. Privileged merchant API keys are never embedded into public client applications.
Keep merchant API keys in trusted backend services. Browser applications should use only approved public flows and never receive privileged secrets.
Use idempotency and request identifiers when creating money-moving operations so repeated delivery can be handled predictably.
Use webhook signatures and event identifiers to verify notifications, update your own systems and reconcile the resulting business activity.
curl --request POST https://api.ekash.co/payments/v1/payments \ + --header "Idempotency-Key: <UUID>" \ + --header "X-Request-Id: <UUID>"
A reliable integration covers more than making a request. It needs clear business ownership, safe credentials, predictable retry behaviour and a way to reconcile event outcomes with your own systems.
Phase 1
Identify the business events, data ownership, supported products and server-side services involved before creating payment or settlement workflows.
Phase 2
Use controlled credentials, request identifiers and expected webhook handling to test the integration without placing secrets or sensitive operational logic in a browser.
Phase 3
Monitor event delivery, reconcile API outcomes and maintain clear ownership for retries, exceptions and support escalation.