Simplifying & securing online payment through all-in-one app

1. Separate client state from server state

The first decision was not about replacing Redux with another library. It was about understanding what the application was actually asking its state-management layer to do.

"Should state owned by the frontend and state owned by the backend share the same management model?"

Client state represents decisions and interactions that belong to the frontend: UI state, local selections, and other values controlled by the application. Server state has a different lifecycle. It originates from backend APIs, can be consumed by multiple parts of the application, and needs to account for request, loading, error, caching, and refresh behaviour.

Treating both categories as one problem meant that API interactions had to be represented through the same Redux machinery used for client state. I proposed separating the two responsibilities so that each could be handled according to its actual lifecycle.

2. Client state: Zustand

Once client state was its own concern, the next question was how to manage it without recreating Redux ceremony for values the frontend already owned. The criteria were simple: low boilerplate, incremental adoption in an existing codebase, and a clear boundary from API-derived data.

Redux Toolkit was the safest path because the project already used Redux, but it would still keep client state inside the same store model we were trying to shrink. React Context with useReducer avoided a new dependency, but it did not scale cleanly as more features needed shared UI state. Zustand fit the need better: a small store API that components could use directly, without actions, reducers, or selectors for local application state.

The important change was not simply reducing the number of files. It was reducing the abstraction required to represent state that was already local to the application. The trade-off was less formal structure than Redux, which was acceptable for the size of the MVP and the kinds of client state we needed to hold.

3. Server state: React Query

For API-derived data, the requirement was different: request lifecycle, loading and error state, caching, and refresh behaviour had to be handled without rebuilding that machinery for every feature. Staying on Redux Saga was possible, but it would have preserved the same multi-file pattern we were trying to escape.

SWR offered a similar mental model with a lighter surface area. RTK Query would have kept fetching inside the Redux ecosystem, which worked against the separation we had just defined. React Query was chosen because it treated server state as its own concern: built-in request lifecycle, cache ownership, and hooks that components could consume without copying backend responses into a general-purpose store.

In practice, that difference showed up in the file structure. Each API-backed feature needed its own actions, reducer, saga, and selectors just to move service data through Redux. React Query collapsed that into a query hook and an API call.

This changed the responsibility of the frontend state layer. Instead of copying backend responses into a general-purpose application store and maintaining their lifecycle manually, server data could remain associated with the service that owned it while React Query handled fetching, caching, and the request lifecycle around that data.

The resulting separation gave each state type a clearer responsibility: Zustand managed state the frontend owned, while React Query managed data whose source of truth lived behind the backend APIs. The trade-off was a new dependency and a learning curve for the team, in exchange for removing repeated API plumbing from every feature.

4. Payments: Stripe

Payment processing was a product decision as much as a frontend one. Condexo Pay needed secure card handling for an Italian fintech MVP without taking PCI scope into the application UI. Building directly against bank rails or a lower-level processor would have slowed delivery and pushed sensitive payment details into our frontend surface.

Stripe became the payment layer for card and online payment flows in the product. Domain-specific Italian services such as bollettini still depended on their own backends and partners; Stripe was not treated as a single solution for every payment type, only for the card-processing surface the frontend had to integrate safely and quickly.

5. The resulting frontend architecture

The architectural change was therefore less about introducing two new libraries and more about establishing a clear ownership boundary between two different kinds of state.

With that foundation in place, the frontend could continue expanding across the product's payment and service workflows without forcing every feature to reproduce the same API state-management plumbing.