> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ecrypt.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments & Keys

> Understand the difference between Sandbox and Production environments, and how to use your API keys correctly.

## Overview

The API operates in two separate environments: **Sandbox** and **Production**. Each environment has its own set of API keys, ensuring your testing and development work never interferes with live transactions.

## Environments

### Sandbox

The Sandbox environment is your safe space for development, QA, and integration testing. It behaves like Production but processes no real money and all transactions are simulated with test payment methods.

* Use test card numbers and ACH account numbers to simulate payment scenarios
* Responses mirror Production behavior without triggering real charges
* Ideal for building integrations, running automated tests, and onboarding new developers

<Info>
  See the [Testing](/testing) guide for a full list of supported test cards and ACH account numbers.
</Info>

### Production

The Production environment processes real transactions with real funds. Only switch to Production once your integration has been validated in Sandbox.

* All API calls result in actual charges and transfers
* Requires an activated merchant account
* Keep Production keys strictly separate from your Sandbox keys

***

## API Keys

Each environment (Sandbox and Production) has its own set of three API keys. Never mix keys across environments.

| Key       | Where It's Used        | Purpose                            |
| --------- | ---------------------- | ---------------------------------- |
| Public    | Frontend / Client-side | Sending tokenization requests      |
| Private   | Backend / Server-side  | All operations post tokenization   |
| Reporting | Backend / Server-side  | Pulling transaction and batch data |

### Public Key

The Public key is used on the **frontend** to submit card or ACH details and request a payment token. Because it is embedded in client-facing code, its scope is intentionally limited to tokenization only — it cannot initiate or modify transactions.

* Used in your frontend integration (Hosted iFrame or Checkout Page)
* Safe to expose in browser environments
* Cannot be used to run sales, refunds, or any other transaction operations

### Private Key

The Private key is used on your **backend** to perform all transaction operations after a token has been obtained. This includes:

* **Charges:** Sale, Authorization
* **Post-transaction operations:** Capture, Void, Refund
* **Customer management:** Create and manage customer profiles and saved payment methods
* **Recurring billing:** Create and manage subscriptions and installment plans

<Warning>
  Your Private key must never be exposed in client-facing code or public repositories. Treat it like a password — store it in an environment variable or secrets manager.
</Warning>

### Reporting Key

The Reporting key provides **read-only** access to your transaction and batch data. It is scoped exclusively to reporting endpoints and cannot be used to initiate or modify transactions.

* Use it to power internal dashboards, reconciliation tools, and financial reporting
* Limit access to trusted internal services only

***

## Managing Your Keys

You can find your Sandbox and Production API keys in the dashboard under **Settings → Developer Tools → API Keys**.

* Keys are environment-specific. Your Sandbox and Production keys are listed separately
* To regenerate a key, navigate to the key in your dashboard and select **Generate Key**
* Rotating a key immediately invalidates the previous key, so make sure to update all services before rotating in Production

***

## Public IP Addresses

Use these IPs to allowlist ECRYPT's servers for webhooks and inbound API traffic.

```text theme={null} theme={null}
52.26.189.58
44.232.175.238
44.224.200.173
52.33.202.58
```

***

## Security Best Practices

* **Never hardcode keys** in your source code or commit them to version control
* **Use environment variables** or a secrets manager (e.g. AWS Secrets Manager, HashiCorp Vault) to inject keys at runtime
* **Restrict Reporting key access** to internal services. It should never be used client-side
* **Rotate keys immediately** if you suspect they have been compromised
* **Audit access regularly** and revoke keys for any services that no longer need them