Subscribe to Stripe Developers on YouTube.

Follow us at @Stripedev on twitter for updates and answers to your developer questions.

Sign up for the Developer Digest.

Join the Stripe Discord server to chat live with other developers.

Join Stripe Insiders to try the latest features and provide direct feedback to the teams that build them.

Are you confident that your data storage and access strategy supports the growth of your Stripe integration? Choosing the right data storage approach can enhance security, boost performance, and enable scalability. As your application evolves, where you store and manage your data becomes important not only for operational efficiency but also for maintaining user trust. 

This blog post explores various options focusing on product data, from using Stripe’s built-in data management capabilities to maintaining a separate database, and provides best practices for accessing that data and optimizing your integration. 

## Using Stripe for Data Management

Stripe is primarily designed for managing financial transactions online, but it also offers capabilities for managing core product data, including basic product descriptions, images, and pricing. Using Stripe alone for your data management may seem tempting as it simplifies your architecture and maintains a single source of truth, reducing potential discrepancies between the product and payment information. However, this approach may limit your options as your application grows and requires you to think about how to access the data securely via the [Stripe API](https://docs.stripe.com/api).

Stripe has various types of [API keys](https://docs.stripe.com/):

* **The secret API key** must be stored securely on the server side and is used for making authorized API calls to Stripe, as it provides full access to your account, available in test mode, sandboxes, and live environments.  
    
* **The publishable API key** is safe to include in client-side code and is used to securely collect payment information without accessing sensitive operations, and it is available in test mode, sandboxes, and live environments.  
    
* **The restricted API key** limits access to specific operations based on customized permissions, providing an additional layer of security while interacting with Stripe, and it can also be utilized in test mode, sandboxes, and live environments.


If your integration consists of a client-side application running in the browser, you might attempt to use the publishable API key to retrieve product data that is stored within Stripe. However, this returns an 'invalid\_request' error, as publishable API keys can only be used to collect payment information, such as creating tokens or processing payments, not for accessing other API endpoints like retrieving product details.

![](/images/data-access-patterns-for-simple-stripe-Integrations/image4.png )

You might then decide to use the private API key to access Stripe data directly from the client; however, **this is highly inadvisable** because it exposes sensitive credentials to anyone who can inspect the client-side code, significantly increasing the risk of malicious use, data breaches, and the potential for unauthorized actions on your Stripe account:  

![](/images/data-access-patterns-for-simple-stripe-Integrations/image1.png)

Use publishable keys for public operations while keeping sensitive operations securely handled on the server side.

### Using a Web Backend

A web backend is a common solution to securely integrate with Stripe in a client-side application. It acts as a bridge between the client and the Stripe API. When a user requests product information, the client app makes an HTTP request to a public endpoint on the backend, designed specifically for fetching product data.

Upon receiving the request, the backend uses your Stripe private API key, or restricted API key to securely interact with the Stripe API, retrieving the necessary product details without exposing sensitive credentials. After processing the request, the backend formats the data and sends it back to the client application. This structure allows for efficient data transfer while keeping API keys confidential, ensuring a secure environment and providing a seamless user experience.

![](/images/data-access-patterns-for-simple-stripe-Integrations/image6.png)

### Using Serverless Functions (Microservices)

An alternative to a traditional web backend is serverless functions, which integrate seamlessly into a microservices architecture. This approach uses independent, stateless functions for specific tasks, such as retrieving product information. Serverless functions offer significant advantages. They automatically scale to handle increased demand, accommodating common spikes without manual intervention. Additionally, you only pay for the time the functions run, leading to cost savings compared to maintaining dedicated server infrastructure. 

This architecture allows developers to focus on writing individual functions by reducing the complexity of managing a whole server. Ultimately, adopting serverless functions provides a scalable, cost-effective solution for modern applications. In the following example, the client-side application invokes an [AWS Lambda function](https://aws.amazon.com/lambda/) via a public HTTPS endpoint generated by [Amazon API Gateway](https://aws.amazon.com/api-gateway/). API Gateway then proxies the request and the response to and from the Lambda function, which calls out to the Stripe API using the private or restricted API key.

![](/images/data-access-patterns-for-simple-stripe-Integrations/image5.png)

### Adding a Global CDN

Integrating a [content delivery network (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network) like [Amazon CloudFront](https://aws.amazon.com/cloudfront/) can significantly enhance the performance of applications using serverless functions and APIs, particularly when interacting with the Stripe API or API Gateway. 

Rather than constantly "hammering" these APIs for data, using CloudFront allows for direct access to cached data, reducing the number of API calls made and thereby decreasing both costs and response delays associated with Lambda and API Gateway usage. This setup provides a more responsive experience for end users too, ensuring that they receive data quickly without the latency involved in server-side processing. 

However developers must also implement a strategy to update the CloudFront cache at an appropriate cadence to ensure that users are served the most current information, balancing performance with data freshness efficiently.

### Adding User Authentication

Another important consideration is to restrict access to live product information so that only authenticated users can retrieve it. You can achieve this by implementing authentication in your client-side application and changing the API Gateway endpoint from a public endpoint to one that requires authentication. 

This modified setup needs either a JWT or a Cognito user authentication before proxying the request to the Lambda function. By doing so, you would not only reduce traffic and associated costs to your Lambda function but also decrease the rate of calls made to the Stripe API, ensuring that only authenticated users can invoke these operations.

## Maintaining a Separate Database

If your application requires detailed product metadata, inventory tracking, or custom attributes, you may need to build additional functionality. 

Using a separate database (like [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [PostgreSQL](https://www.postgresql.org/), or [MongoDB](https://www.mongodb.com/)) to store your application data can provide you with greater flexibility and scalability. With a database, you can store extensive product details, including variants, inventory levels, and additional metadata unique to your business model. Design your database schema to fit your specific application needs, allowing for complex data structures and relationships. Having a dedicated database can also improve data retrieval speeds and enable more efficient querying for reports and analytics. 

Storing relevant product IDs in DynamoDB, applications can create a more efficient and scalable architecture that allows for quick data retrieval. In the following updated example, once the client-side app requests product information, a Lambda function retrieves the product ID  from the DynamoDB table. It then fetches additional data from the Stripe API as needed, such as payment links, price IDs, or any dynamic attributes related to that product. 

This approach not only enhances performance by reducing the number of direct API calls to Stripe but also enables the application to maintain a robust mapping of products that may include custom metadata or configurations not present in Stripe. By using the combination of a dedicated database and serverless functions, developers can create a versatile and efficient system that provides users with richer product data while optimizing API usage and cost. 

![](/images/data-access-patterns-for-simple-stripe-Integrations/image2.png) 

However, managing a separate database introduces additional overhead, particularly when it comes to ensuring that product data remains synchronized with Stripe. To maintain up-to-date consistency, it's essential to implement synchronization mechanisms that can handle changes. You can achieve this with [Event Destinations](https://stripe.dev/blog/growing-your-stripe-integration-with-event-destinations) or [webhook endpoints](https://docs.stripe.com/api/webhook_endpoints) from Stripe, to notify your backend of relevant events such as product updates or successful payments. 

By setting up a mechanism to listen for these events, your backend can automatically update the database to reflect any modifications made in Stripe. For a detailed use case on how to implement this synchronization using event destinations, refer to the "**Reacting to Stripe events in Real-Time"** blog, which provides insights into creating a robust solution for real-time inventory management.

![](/images/data-access-patterns-for-simple-stripe-Integrations/image3.png)

## Conclusion

Choosing where to store, and access data in your Stripe integration is a pivotal decision that impacts the security, performance, and scalability of your application. While Stripe provides useful capabilities for managing core product data, using a separate database like DynamoDB can offer enhanced flexibility and detailed metadata management. Incorporating serverless functions can further streamline operations and reduce infrastructure overhead, making the application more responsive to user demands.

Integrating a CDN like CloudFront helps optimize API interactions by reducing the need for repetitive calls to Stripe, ensuring a smoother experience for end-users. Ultimately, the combination of these strategies can lead to an efficient ecosystem that not only meets business needs but also delivers a seamless experience to users. Implementing synchronization mechanisms via event destinationsor webhooks is essential for maintaining data consistency across platforms. To learn more about event destinations, check out the videos on our [Stripe developers YouTube channel](https://www.youtube.com/stripedevelopers).

Is your Stripe integration ready to scale with your application? In this blog post, explore smart data strategies to enhance performance and security. Learn how to leverage Stripe/'s features, secure web backends, and serverless functions for efficient data management. Discover when to integrate a global CDN and use a separate database for deeper data control, ensuring a seamless user experience.

Data access patterns for simple Stripe Integrations

Ben Smith