Going Live

Use this checklist before sending live traffic through Payflow client APIs.

Production readiness

Confirm that:

• Your Payflow application has production access enabled.
• Production provider credentials are configured in Payflow.
• Routing behavior is confirmed for card payments and ACH, if applicable.
• Production browser origins use HTTPS and are registered for publishable-key calls.
• Secret keys are stored in a secret manager, not in source code.
• Provider callbacks are configured for the production API origin.
• Your application stores payflowReference for every payment attempt.
• Your support team can search by request ID, Payflow reference, provider, and order ID.

Environment swap

Move from sandbox to production by changing credentials and API origin:

export PAYFLOW_CLIENT_API_URL="https://api.ftosllc.co/client/v1"
export PAYFLOW_SECRET_KEY="sk_live_your_key_id_your_secret"

Do not reuse sandbox keys, origins, provider credentials, or callback settings for production.

Safe retry behavior

For hosted checkout and component preparation:

• Retry network failures with care.
• Store any returned payflowReference.
• Check your own order state before creating a new payment.

For ACH transfers:

• Always send an idempotencyKey.
• Reuse the same idempotency key for retries of the same business action.
• Use a new idempotency key only for a genuinely new transfer attempt.

Customer-facing errors

Map Payflow errors into user-safe copy. For example:

We could not start this payment. Please try again or use another payment method.

Keep the original Payflow message, X-Request-Id, payflowReference, and provider reference in internal logs.

Launch test

Run one low-value production payment and confirm:

• The client API returns the expected envelope.
• The selected provider matches routing expectations.
• The customer experience works end to end.
• Provider callbacks update status.
• Your system stores the Payflow reference.
• Retry behavior does not create duplicate business actions.