Payflow Docs

Applications and Keys

Understand the client API applications, publishable keys, secret keys, browser origins, and rotation practices your integration depends on.

Applications group credentials, environments, browser origins, rate limits, and client API request history for an integration.

Application and credential management happens in Payflow. This page documents only what an integration needs to know to call the client API safely.

Application lifecycle

  1. Create or select an application in Payflow.
  2. Use sandbox keys while building and testing.
  3. Add allowed browser origins before using publishable keys in a browser.
  4. Keep secret keys in a server-side secret manager.
  5. Rotate keys when operators change, infrastructure changes, or exposure is suspected.
  6. Create live keys only after Payflow enables production use for the application.

Key types

KeyPrefixWhere to use itTypical client API use
Publishable sandboxpk_test_Browser/mobileBrowser-safe setup calls protected by origin checks.
Secret sandboxsk_test_Backend onlyHosted checkout, component confirmation, ACH tokenization, ACH transfers.
Publishable productionpk_live_Browser/mobileProduction browser-safe calls after live access is enabled.
Secret productionsk_live_Backend onlyProduction server-side payment flows.

Store keys safely

Secret keys are server credentials. Store them in:

  • A cloud secret manager.
  • A deployment secret store.
  • Local .env files for development only.

Do not store secret keys in:

  • Browser bundles.
  • Mobile app binaries.
  • Git history.
  • Screenshots.
  • Client logs.
  • Analytics events.
  • Customer support transcripts.

Rotate secret keys

Use a rotation process like this:

  1. Create a new secret in Payflow.
  2. Deploy the new secret to all backend services.
  3. Confirm new traffic is using the new suffix.
  4. Revoke or retire the old secret after your overlap window.

Use immediate revocation when a key may be compromised.

Configure CORS origins

Publishable keys are protected by application environment origins.

Origins must be origin-only values. Do not include a path:

Valid:   https://checkout.example.com
Invalid: https://checkout.example.com/pay

Production origins must use HTTPS. Sandbox may allow local loopback HTTP origins for development.

Request IDs and logs

Send a stable request ID from your backend when creating or confirming payments:

X-Request-Id: checkout-order-1001-attempt-1

When debugging a client API call, collect the request ID, key suffix, environment, endpoint, HTTP status, and payflowReference when available.

On this page