Using demo data for testing Stripe integrations in AWS-hosted applications

Many Stripe customers use AWS to host their applications and use CI/CD tools to manage and deploy changes to their production and test environments. Stripe has always provided a test mode for testing integrations but for complex applications additional capabilities may be needed.

With the new Stripe sandboxes feature, developers can manage multiple test environments from a single Stripe account. It provides richer functionality than test mode and enables you to map test environments more easily to multiple developers in your AWS accounts. With Sandboxes, you can simulate external events to test payments, accumulating a fake balance instead of real transactions, and use the Test Payouts functionality using API v2 keys, calling API v2. You can use the CLI or SDK to interact with sandboxes by simply changing the API keys used.

This blog post shows how to use demo data in Stripe sandboxes for AWS-hosted applications and how to store the resulting API key securely for use in CI workflows.

Seeding sandboxes with test data locally

Using the Stripe API, you can create test data for customers, products, prices, and other Stripe objects that can help test the accuracy of your Stripe integration.

To import a custom set of data for your sandbox, you can optionally export data from other sandboxes or production accounts, or create test data from a script. This section focuses on Product data but the same process applies to other objects, such as Customers.

To export product data from a production account:

1. Navigate to the Product catalog tab in the Stripe dashboard for the production account.
2. Choose Export products to open the export configuration dialog:

3. Under Date range, choose All to include all products configured in the account, then choose Export. This creates a CSV file containing all your products.

4. To import this data into a Sandbox, you can iterate through the CSV file and use the SDK to create each product.

If you only want to use test data, you can build a test script to run from your local development machine. To build this script:

1. Run stripe login in your terminal and log into your preferred sandbox account. Any subsequent CLI commands will be run against this account.
2. In your text editor, create a new file with the name create-test-data.sh.
3. Ensure you update the file’s permissions in your terminal. In macOS or Linux, run chmod 755 create-test-data.sh.
4. To create products, add the following line per product, replacing the attributes with your product’s value:
   stripe products create \--name "Your product name" \--description “Your description”
5. Run the script from the terminal: ./create-test-data.sh

Creating test data from CI processes and automation tools

You can also use this script in your GitHub Actions or continuous integration tools to populate sandboxes. However, you must update it to ensure the script has a valid API key to run against the appropriate sandbox. Since the interactive mode of stripe login requires input in a terminal, the easier way is to pass the API key into each CLI action:

stripe products create --name "Your product name" --description “Your description” --api-key "sk_test_YOUR_KEY"

Although you can use an API key as a variable, it’s recommended that you store this information securely, and access it via an environment variable. You should not use the following example, or commit this code to source control, to avoid potentially leaking API keys later:

Read more about Best Practices for Key Management..

From AWS-hosted applications, you can store the sandbox API key in AWS Secrets Manager to retrieve the key dynamically at runtime and don’t log the key from code. Secrets Manager allows you to securely store and rotate secrets and use AWS Identity & Access Management to limit access. You can enable read or write access per IAM user or IAM role or principal, and grant access over multiple AWS accounts if you using accounts to manage different environments.

You can use the AWS CLI to access the secret via the script. You can also use the AWS SDK to access the secret directly from code, if you are using services like AWS Lambda or AWS Fargate.

In the CLI, for Linux or macOS, you can use the following command to extract a secret and then use the SECRET_KEY variable in your script:

SECRET_ARN=arn:aws:secretsmanager:us-east-1:abcd123:secret:/example
SECRET_KEY=STRIPE_SANDBOX_API_KEY
aws secretsmanager get-secret-value  --secret-id $SECRET_ARN  --query SecretString --output text | grep -o '"$SECRET_KEY":"[^"]*' |  grep -o '[^"]*$'

Similarly, PowerShell developers can use the following to extract the secret via the Secrets Manager CLI:

$secret_key = aws secretsmanager get-secret-value --region <region> --secret-id <secret-name> | ConvertFrom-Json

Once your test scripts finish running, you may optionally run a script that uses the product delete API to remove these from your sandbox.

While a sandbox will never have access to production and cannot be used to move real money, it’s recommended that you treat API keys for these the same way as you do for production. Specifically:

• Don’t embed API keys in code, or pass keys around in chat, email, or other unsecure means. Use services like AWS Secrets Manager to retrieve the key dynamically at runtime without logging the key in your code.
• Don’t store keys in source repositories like GitHub, even if the repo is private since this can result in key leakage later.
• Rotate your keys periodically in the Stripe dashboard, and then update AWS Secrets Manager. Restrict who has access to create, modify or delete keys in both Stripe and AWS.

Conclusion

Stripe’s new sandbox feature makes it easier to create an isolated testing environment loaded with test data. You can use the built-in templates to automatically populate a sandbox with data. Alternatively, for more control, you can export your production data and import into a sandbox, or create test data using the CLI via scripting.

This post shows how you store your API keys securely using AWS Secrets Manager for your AWS-hosted applications. Your CI scripts can then access those secrets at runtime, store the secret in an environment variable, and pass this into the Stripe CLI with each request. This helps create test scripts that handle secrets securely and you can commit to code repos without leaking API keys.

To learn more about developing applications with Stripe, visit our YouTube Channel.