Staging vs Production Payment Configuration Checklist

Payment environments must differ by more than a hostname. If staging and production share credentials, merchant identifiers, webhooks, databases, or analytics, a developer test can create a live order effect and a staging exposure can become a production incident.

Treat environment as part of every payment identity and record. An order reference without environment context is unsafe during support and reconciliation.

Separate Identities and Secrets

Provision independently:

Configuration	Staging	Production
API key	Test/staging secret	Production-only secret
Webhook secret	Staging signing secret	Production signing secret
Merchant connection	Approved test connection where available	Authorized live merchant account
Webhook URL	Staging HTTPS hostname	Production HTTPS hostname
Database	Non-production data store	Restricted production data store
Analytics	Test property or explicit filter	Production property

The application should fail closed when required configuration is absent. Do not fall back from staging to a production key or from a failed API call to a mock “success” response.

Display an unmistakable environment badge in privileged tools. Production actions should require the production hostname and role; color alone is not enough for accessibility.

Separate Events and Data

Prefix or namespace non-production order references, but do not rely on the prefix as authorization. Keep tenant and environment checks in backend queries and uniqueness constraints.

Use synthetic test customers and products. Do not clone production payer data into staging. Redact production evidence before adding it to a bug report, and never copy secret-bearing request captures.

Webhook delivery history, queue records, reconciliation cases, and support searches must all include environment. A test event should never appear in live merchant metrics or trigger customer communication.

Promote Configuration Safely

Classify settings into:

• Code and versioned non-secret defaults
• Reviewed environment-specific non-secret values
• Secret-store values
• Merchant/provider authorization completed by an approved user
• Runtime feature flags with owner and expiry

Promote application code and non-secret configuration through the deployment process. Create or select secrets in the target environment; do not embed them in build artifacts. Use a release checklist that compares endpoint, provider, callback URL, redirect hostname, database, queue, and analytics property.

The merchant onboarding readiness checklist provides the ownership and go-live evidence model.

Production Verification

After deployment, run checks in this order:

1. Health endpoint and expected application version.
2. Production hostname, merchant, and environment badge.
3. Secret availability without printing its value.
4. Webhook URL validation.
5. Real signed test event returning 2xx.
6. One durable receipt and no fulfilment for a test-only event.
7. Controlled payment where authorized and permitted.
8. Verified amount and order reference comparison.
9. One fulfilment effect or approved test outcome.
10. Support and reconciliation visibility.

Record event and order references, not credentials. If any test reaches the wrong environment, stop the launch and treat it as an isolation defect.

Prevent Environment Drift

Run automated assertions at startup and in deployment checks. Production should reject localhost callback URLs, test database hosts, missing secrets, debug logging, and staging analytics IDs. Staging should refuse known production identifiers.

Review environment differences after secret rotation, provider reconnection, domain migration, database restoration, and major deployment changes. Isolation is not a one-time setup; it is a property that each release must preserve.

Maintain a non-secret environment manifest that the application can expose to authorized operators:

{
  "environment": "production",
  "application_version": "2026.08.26.1",
  "public_base_url": "https://merchant.example",
  "webhook_host": "merchant.example",
  "database_class": "production",
  "analytics_property": "vg-live",
  "signing_key_label": "webhook-2026-08"
}

This provides useful comparison without revealing secret values. Validate it during deployment and show it in the protected support view. When a case crosses teams, attach the manifest version and safe references so an engineer does not investigate staging while support is looking at a production order.

Assign one owner to review this manifest after every release. Configuration drift that has no accountable owner will eventually become a payment, privacy, or support incident.