Skip to main content

​
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)
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.

​
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: 
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. 
export APIKEY=pcsk_production_...
curl --request POST \
  --url https://api.pushcash.com/keys/verify \
  --header 'Authorization: Bearer '$APIKEY

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.
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.
For more detail, see the 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. 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. 
curl --request GET \
  --url https://api.pushcash.com/account/account_7lnfBi4mBOWjNqW5J8Mx9E \
  --header 'Authorization: Bearer '$APIKEY

{
  "id": "account_7lnfBi4mBOWjNqW5J8Mx9E",
  "type": "settlement",
  "name": "Sportsbook NJ",
  "created_at": "2026-06-05T00:48:56.827669Z"
}
You can retrieve all accounts configured for your organization at any time by calling GET /accounts/list.

​
Step 3: Apple Pay domain verification

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 Integration guide.
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: 
    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 guide for details. Questions or issues going live? Reach out to your Push Cash representative or hello@pushcash.com.