Environments

Every Payflow application has a sandbox environment and a production environment.

Sandbox

Sandbox is for local development, QA, integration tests, demos, and provider sandbox credentials.

Sandbox characteristics:

• Uses pk_test_ and sk_test_ credentials.
• Allows local loopback HTTP origins for your own sandbox browser app when registered.
• Can use Stripe and Square sandbox setup.
• Can use Dwolla sandbox ACH when provider credentials and funding source are configured.
• Requires the organization sandbox to be ready before client API calls are accepted.

Production

Production is for live customer traffic.

Production characteristics:

• Uses pk_live_ and sk_live_ credentials.
• Requires HTTPS origins for publishable keys.
• Requires Payflow approval for live use.
• Should use production provider credentials and webhook endpoints.
• Should use real operational monitoring and alerting.

Environment is encoded in keys

Payflow reads the environment from the credential prefix:

pk_test_... -> sandbox
sk_test_... -> sandbox
pk_live_... -> production
sk_live_... -> production

Do not send an environment body field to client payment APIs unless the endpoint explicitly documents it. Client API scoping comes from the credential.

Hosted API URL

PAYFLOW_CLIENT_API_URL=https://api.ftosllc.co/client/v1

Use the same hosted API URL for sandbox and production calls. The credential prefix (sk_test_, pk_test_, sk_live_, or pk_live_) determines the application environment.

Operational separation

Treat sandbox and production as separate operational planes:

• Separate keys.
• Separate allowed origins.
• Separate provider credentials.
• Separate routing rules.
• Separate webhook subscriptions when providers support environment-specific endpoints.
• Separate monitoring dashboards or tags.

Promotion checklist

Before moving an integration from sandbox to production:

1. Receive production approval for the application.
2. Configure production provider credentials in Payflow.
3. Confirm production routing behavior.
4. Register production HTTPS origins.
5. Create production secret and publishable keys.
6. Configure production provider callbacks.
7. Run a small production verification payment.
8. Rotate or revoke any keys exposed during testing.