Refreshing a sandbox from production is a routine task for Salesforce administrators and developers. However, amid the excitement of testing new features or troubleshooting issues, there’s an important risk to consider: live payment credentials may still be active after the refresh. If someone unknowingly runs a real transaction in the sandbox, it could result in unexpected customer billing errors and compliance complications. To eliminate this risk, we’ve introduced a separate encryption key specifically for live payment credentials in sandbox environments.

Why This Change Matters

By default, a sandbox refresh copies nearly all data from your production org, including encrypted information. That means any live payment processor credentials remain functional in the sandbox until they’re explicitly removed or updated. Although this might seem convenient, it also creates the potential for accidental real-world transactions during development and testing. Isolating live credentials in the sandbox with a distinct encryption key ensures that test activities cannot trigger live charges, protecting both your organization and your customers.

New Behavior After a Sandbox Refresh

• Live Credentials Are Disabled

  • After a sandbox refresh, live payment credentials will no longer work until they are re-entered. To continue using live credentials in the sandbox, customers must recreate or update their processor credentials within the environment.

• Automatic Encryption with a Sandbox Key

  • If you add or update live credentials directly within the sandbox, the system automatically encrypts them using the “Sandbox Encryption Key.” This key differs from the one used in production.

• Test Credentials Continue to Function

  •  Any test credentials you have in place will operate as usual. Your developers and QA engineers can continue simulating payment workflows, validating error handling, and conducting end-to-end testing without interruption. The only change is that live payment requests are blocked.

The New “Sandbox Encryption Key”

To keep live payment credentials isolated in sandbox environments, we’ve introduced a distinct encryption key at the metadata level for each payment processor. Here’s how it works:

4030. Key Generation: A new Sandbox Encryption Key will be generated and securely stored in the processor’s metadata.

4031. Conditional Encryption/Decryption:

      • Encryption: Whenever you save processor settings in a sandbox and select “Live,” the system encrypts those credentials using the new sandbox-specific key.

      • Decryption: If you attempt to use the live credentials in the sandbox, Salesforce will look for the “Sandbox Encryption Key” to decrypt them. 

      • In a production or Developer Edition environment, the standard encryption key used for live transactions remains unchanged.

This design ensures that sandbox credentials are never accidentally reused in production, and vice versa.

Conclusion

By separating encryption keys for live payment credentials in sandbox environments, we’ve built an additional layer of safety into your Salesforce testing workflows. This change prevents inadvertent real-world transactions, protecting both your company and your customers from surprise billing errors and compliance issues.