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

# Go-Live Checklist

# Overview

This checklist covers everything required to move your integration from sandbox to production. It is designed to be worked through **live, on a call** with your Push Cash representative, so that any missing information can be supplied in the moment and any blockers resolved before you go live.

Please have an engineer with access to your production backend and production cashier domain present. By the time the call wraps, you will have:

1. **Production API key access + IP address restriction** for the production API (`api.pushcash.com`)
2. **Account identifiers** for the accounts you will transact against
3. A **configured & verified Apple Pay domain** for your production cashier (Apple Pay integrations only)

<Info>Throughout this guide, production requests are made to `api.pushcash.com`. The same API surface is available in sandbox at `sandbox.pushcash.com` for testing beforehand.</Info>

## Step 1: Production API key & IP allowlisting

Production keys are scoped to your organization and follow the format `pcsk_{env}_{public_id}.{private_key}`. Confirm the `production` segment is present — for example:

```text theme={null}
pcsk_production_ct0hVCfF6C.FDlfQgAUpcfiRxBN2JvT9TgkFQri6d9XpJfzX1mu8RqD
```

Verify the key is valid and resolves to the correct organization by calling `POST /keys/verify`. The API responds with `200` (OK) and your organization name.

```bash theme={null}
export APIKEY=pcsk_production_...
curl --request POST \
  --url https://api.pushcash.com/keys/verify \
  --header 'Authorization: Bearer '$APIKEY
```

```text theme={null}
Hello Sportsbook
```

### IP address restriction

As an additional layer of security, Push Cash can restrict **write requests** (`POST`, `PUT`, `PATCH`, `DELETE`) so they are only accepted from a set of source IP addresses that you specify. This protects your account even if an API key is leaked, since a stolen key cannot move money from an unrecognized network. Read requests (`GET`, `HEAD`) are not restricted, so dashboards, monitoring, and reconciliation jobs are unaffected.

IP allowlisting is configured by Push Cash — it is not self-serve. During the call, provide the **stable egress IPs** of your production backend (the public IPs of your NAT gateways or load balancers, not individual servers that may change). Include **every** IP your traffic can egress from to avoid intermittent `403` rejections.

<Note>
  Notify Push Cash **before** changing your network egress (for example, migrating regions or adding a new gateway) so your allowlist can be updated ahead of the cutover.
</Note>

For more detail, see the [IP Allowlisting](/api#ip-allowlisting) section of the API Concepts guide.

## Step 2: Account identifiers

Account IDs follow the format `account_WsELzpJOvU6fNafvzWbF6K` and are submitted as the `account` parameter to [`POST /authorize`](/apireference/authorization/authorize-payment).

Confirm the production account ID(s) you will transact against, then verify each one by calling `GET /account/{id}` and checking the `name` in the response.

```bash theme={null}
curl --request GET \
  --url https://api.pushcash.com/account/account_7lnfBi4mBOWjNqW5J8Mx9E \
  --header 'Authorization: Bearer '$APIKEY
```

```json theme={null}
{
  "id": "account_7lnfBi4mBOWjNqW5J8Mx9E",
  "type": "settlement",
  "name": "Sportsbook NJ",
  "created_at": "2026-06-05T00:48:56.827669Z"
}
```

<Info>You can retrieve all accounts configured for your organization at any time by calling [`GET /accounts/list`](/apireference/accounts/list-accounts).</Info>

## Step 3: Apple Pay domain verification

<Info>This step applies only to integrations using Apple Pay. If your integration does not use Apple Pay, you can skip it. For full details, see the [Apple Pay](/apple-pay) guide.</Info>

Apple Pay on the web requires your production cashier to be served over HTTPS on a domain that **Apple has verified**. Verification is a manual, one-time step completed together on the call:

1. **Supply your production domain.** Give your Push Cash representative the exact domain your cashier will be served from (for example, `cashier.your-domain.com`).

2. **Receive the domain association file.** Over Slack or email, you will receive the `apple-developer-merchantid-domain-association.txt` file generated for that domain.

3. **Host the file.** Place it at:

   ```text theme={null}
   https://your-domain.com/.well-known/apple-developer-merchantid-domain-association.txt
   ```

4. **Push verifies the domain.** Once the file is reachable over HTTPS, your Push Cash counterpart verifies the domain in the Apple developer console. This must be done manually by Push — it is not self-serve.

## Go-live checklist

* Production hostname (`api.pushcash.com`) is configured and all connections use HTTPS
* API key is in the production format (`pcsk_production_...`) and `POST /keys/verify` returns the correct organization
* Stable egress IPs supplied to Push Cash and the allowlist is configured
* A write request from an allowlisted IP succeeds (and, optionally, one from an unrecognized IP is rejected with a `403`)
* Production account ID(s) confirmed and verified via `GET /account/{id}`
* **\[Apple Pay only]** Production cashier domain supplied to Push Cash
* **\[Apple Pay only]** Domain association file hosted at `/.well-known/apple-developer-merchantid-domain-association.txt` and reachable over HTTPS
* **\[Apple Pay only]** Push Cash has verified the domain in the Apple developer console

## Next steps

If you have not already, set up webhooks to receive asynchronous updates about payment status. Refer to the [enabling webhooks](/enabling-webhooks) guide for details.

Questions or issues going live? Reach out to your Push Cash representative or [hello@pushcash.com](mailto:hello@pushcash.com).