Skip to main content
All communication between your application and the cNGN platform is protected end-to-end: AES-256-CBC encryption for request payloads and Ed25519 public-key encryption for response data, on top of API-key authentication and IP whitelisting.
Safeguard your encryption key and Ed25519 private key at all times. Never expose them in client-side code, mobile apps, or public repositories. Anyone holding them can read your API traffic.

​
The three security layers

API key

A Bearer token identifies your business and selects the test or live environment.

IP whitelisting

Requests are only accepted from server IPs you have whitelisted.

Payload encryption

Request bodies and response data are encrypted in both directions.

​
Setting up secure communication

Generate API and encryption keys

Retrieve the auto-generated keys from your merchant dashboard:
  • API key (cngn_test... or cngn_live...): sent as your Bearer token
  • Encryption key: used to AES-encrypt request bodies
Store both in a secrets manager immediately; treat them like passwords.

Guide: Generating API Keys

Step-by-step dashboard walkthrough.

Generate an Ed25519 SSH key pair

This creates two files:

Guide: Generating SSH Keys

Key generation and clipboard commands for macOS, Linux, and Windows.

Upload the public key to your dashboard

Upload cngn_api_key.pub to the SSH key slot for the matching environment. Each environment (test and live) has its own slot; requests fail with No Test SSH Key found or No Live SSH Key found if the slot is empty.

Encrypt requests and decrypt responses

Wire the crypto into your integration, or let an official SDK do it for you:
  • Encrypt every POST/PUT body into the {content, iv} format
  • Decrypt the data field of every response with your private key
Full code for both directions is in the Encryption guide.

​
Credential handling rules

​
Best practices

Use a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) rather than environment files checked into repositories. Scope read access to the services that call the API.
If a key may have leaked, or someone with access leaves the team, regenerate the API and encryption keys in the dashboard and replace the SSH key pair. Old keys stop working the moment new ones are issued.
Whitelist only the egress IPs that actually call the API, and remove entries when infrastructure is decommissioned. A short list limits the blast radius of a leaked key, since requests from other IPs are rejected.
Never point production services at cngn_test keys or vice versa. Keep the two credential sets in separate secret scopes so a misconfiguration cannot cross environments.
Watch your transaction history for transfers you did not initiate, and alert on repeated 403 or Decryption failed responses, which can indicate probing.
Keys generated, public key uploaded, secrets locked away? Continue to the Encryption guide to wire up the payload crypto, then verify everything with the Going Live Checklist.