Securing Live Pricing on BigCommerce PDPs: Best Practices for External API Integration

Securing Live Pricing on BigCommerce PDPs: Best Practices for External API Integration

Integrating external systems like ERPs (Enterprise Resource Planning) to display real-time data, such as live pricing, on a BigCommerce Product Detail Page (PDP) is a common requirement for many merchants. However, doing so securely and efficiently requires careful architectural planning. This community discussion from the BigCommerce forum provides invaluable insights into the recommended best practices for achieving this, particularly focusing on secure API communication and authentication.

The Challenge: Displaying Live ERP Pricing on PDPs

The original poster, Rajesh Kumar, sought guidance on how to communicate with an external ERP API from the BigCommerce storefront to fetch live pricing data based on a customer ID and display it on the PDP. The core concern was identifying the best practices and secure authentication approaches for such a frontend-initiated API call.

Why Direct Frontend API Calls are Risky

The first crucial insight shared by Solomon Lite was a strong recommendation against calling an external ERP API directly from the storefront (PDP). Exposing authentication credentials (API keys, tokens) and potentially sensitive customer identifiers directly in the browser poses significant security risks. This approach makes it easy for malicious actors to intercept credentials or spoof customer data.

The Recommended Architecture: Storefront → Middleware → ERP API

The consensus solution involves an intermediary layer: a secure middleware or custom application. The architectural pattern is:

• Storefront (PDP) sends a request to a secure middleware endpoint.
• Middleware/App authenticates with the ERP API.
• ERP API returns the requested pricing data to the middleware.
• Middleware processes the data and returns only the necessary pricing information to the storefront.

This server-side middleware acts as a secure proxy, ensuring that sensitive ERP API keys and tokens remain safely on the server and are never exposed to the client-side browser. For performance, it's also suggested to briefly cache pricing responses and load prices asynchronously on the PDP after the initial page render.

Authenticating Between Storefront and Middleware

Rajesh's follow-up question regarding authentication between the storefront and the middleware was critical. Sajid Jameel and Solomon Lite provided detailed solutions:

For Logged-In Customers: Signed JWTs

When a customer is logged in, their customer ID can be accessed via the Stencil context ({{customer.id}}). The recommended approach is to:

1. Generate a short-lived, signed JSON Web Token (JWT) on the storefront (or via a secure backend process initiated by the storefront) containing the customer ID. This JWT is signed with a secret known only to your middleware.
2. The frontend sends this JWT along with the request to the middleware.
3. The middleware verifies the JWT's signature and payload to confirm the request's authenticity and the customer's identity before calling the ERP API. This prevents customer ID spoofing.

For Non-Logged-In (Guest) Customers:

Several options exist when a customer ID isn't available:

• Default/Retail Pricing: Display standard pricing from BigCommerce's native catalog. ERP-specific pricing is fetched only upon login.
• Prompt to Log In: A common B2B strategy, where a message like "Log in to see your pricing" is displayed.
• Session-Based Anonymous Token: The middleware can issue a short-lived anonymous session token to the storefront. The ERP then returns default or guest pricing based on this token, maintaining server-side security.

Securing the Middleware Endpoint Itself:

Beyond customer-specific authentication, the middleware endpoint should be secured:

• CORS Configuration: Only accept requests from your storefront domain.
• Rate Limiting: Implement rate limiting to prevent abuse.
• Lightweight API Key/HMAC Signature: A shared key between your storefront JavaScript and middleware (distinct from ERP credentials) can be included with each request for an additional layer of verification.

Passing Additional Parameters with JWT

Rajesh also inquired about passing other parameters like SKU along with the JWT. Solomon confirmed this is the correct approach. The JWT serves purely for authentication and session validation. Additional parameters like SKU, Product ID, Quantity, or Currency can be included in the request payload:

POST /pricing-endpoint
{
  "token": "JWT_TOKEN",
  "sku": "ABC-123",
  "customer_id": 456,
  "quantity": 1
}

The middleware's role is then to:

1. Verify the JWT signature using the BigCommerce client secret.
2. Validate the customer/session data from the token.
3. Read the additional parameters from the payload.
4. Call the ERP API server-to-server using secure credentials (OAuth 2.0, API keys from environment variables, signed server requests).
5. Return only the relevant pricing response to the storefront.

This architecture ensures that ERP credentials remain fully server-side, while the storefront can securely request and display dynamic pricing based on various parameters. Implementing short-lived caching and rate limiting at the middleware layer can further optimize performance and prevent excessive ERP calls.