The storefront integrates with a REST based Address verification service (AVS) that uses token based security. The sequence of calls in the API…

The core requirements are to use the AVS efficiently (minimize costly authentication calls) and securely (protect the merchantId and secret). This necessitates a server-side token management strategy, as placing the secret on the client-side (browser) is a critical security flaw.

1. (C) Custom Cache: A server-side script can first check a custom platform cache for a valid token. If the token is absent or expired, the script then makes the authentication call, stores the new token in the cache with a specific Time-To-Live (TTL), and proceeds. This is a reactive, on-demand, and efficient server-side pattern.

2. (D) HTTPService Caching: This is a specific implementation of server-side caching using the B2C Commerce platform's native service framework. By configuring caching on the service definition for the authentication call, the platform automatically handles caching the token response, preventing redundant calls until the cache expires.

3. (E) Job and Custom Object: A scheduled job can run periodically (e.g., hourly) on the server to proactively fetch a new token and store it in a Custom Object. Storefront server-side code then reads the token from this object. This decouples token renewal from user traffic and ensures a valid token is always available.

1. HTTPService Caching (Option D): Salesforce B2C Commerce Cloud Documentation describes the service framework's caching capabilities. "For each service

you can configure whether and for how long responses are cached. If a call to a service is repeated within the cache period

the response is served from the cache and the remote service is not called." This directly supports using service caching to avoid repeated authentication calls.

Source: Salesforce B2C Commerce Developer Center

"Service Caching".

2. Jobs for Background Processes (Option E): The B2C Commerce documentation details the use of jobs for recurring

server-side tasks. "Jobs are the tool for creating batch processes... For example

a job can run every night to get a new token from a third-party service." This validates the job-based token renewal strategy.

Source: Salesforce B2C Commerce Developer Center

"Jobs" and "Job Steps".

3. Custom Caches (Option C): The platform provides APIs for creating and managing custom caches for server-side use. "You can create caches for your custom code... Caching data can improve performance by avoiding the need to recalculate data or retrieve it from a remote system on every request." This supports the general server-side caching approach.

Source: Salesforce B2C Commerce API Documentation

dw.system.CacheMgr.

4. Custom Objects for Data Persistence (Option E): Custom Objects are described as a way to store persistent data on the platform that can be accessed by server-side logic

such as jobs and storefront controllers. This is the mechanism for storing the token fetched by the job.

Source: Salesforce B2C Commerce Developer Center

"Custom Objects".

5. Server-Side Credential Management (General Principle): Security best practices mandate that sensitive credentials like API secrets must be stored and used exclusively on the server-side and never exposed to the client (browser). Options A and B violate this principle.

Source: Salesforce B2C Commerce Developer Center

"Security Best Practices".