Global FinTech Cards Platform

AEM's language copy framework organises content under a language root structure — /content/[site]/en, /content/[site]/de, /content/[site]/fr and so on — where each locale inherits from or extends a master language tree rather than duplicating it. Components are defined once in the component library and referenced across all language trees; only the authored content (text, images, localised strings) differs per locale. Language copies can be created from a master and then translated or locally overridden without touching component code. For a 16-language platform, this means a bug fix or component enhancement deploys once and is reflected in all 16 language variants immediately — there is no per-locale component codebase to maintain. The architecture also enables rollout policies: changes to the master can be automatically rolled out to all language copies, or selectively approved per market if regional teams require local sign-off.

PDF generation in AEM is typically handled one of two ways: server-side rendering using AEM's built-in document services (part of AEM Forms), or an integration hook that delegates to an external service. When the PDF logic requires business rules, dynamic data assembly, or branding that sits outside the AEM Forms capability set — or when an existing Spring Boot microservice already owns that logic — the integration hook pattern is the right approach. The AEM component captures user form submission data, serialises it into a structured request payload, and makes a server-side HTTP POST to the Spring Boot microservice endpoint. The microservice assembles the PDF using its own template engine (typically iText, Apache PDFBox, or similar), applies the appropriate card product branding and user-specific data, and returns the binary PDF in the response. AEM streams this directly to the browser as a download or inline preview — the user never sees the microservice, and no user data is exposed in the browser. Authentication between AEM and the microservice is handled via a shared secret or OAuth token managed in OSGi configuration, keeping credentials out of the JCR.

AEM Core Components ship with default Coral UI dialog fields for each component type — text fields, image pickers, path browsers, and so on. Customising these means extending or replacing the default dialog structure to add validation, constrain inputs to locale-appropriate values, remove fields that are not relevant to the platform's authoring model, or inject custom widgets that enforce design system constraints. For a global cards platform with authors in 16 markets, unconstrained dialogs create divergence: authors in different regions make different layout choices, enter inconsistent data, or leave fields empty that break rendering. Standardised, customised dialogs enforce the content model at the authoring layer — if a field should only accept values from an approved list (card product codes, regulatory disclaimer codes), the dialog can enforce that. The result is consistent page output across all 16 language variants regardless of which regional author publishes the content.

Component isolation in AEM means each component encapsulates its own markup, styles, JavaScript, and dialog — changes to one component cannot unintentionally break another. On a multi-language platform rolling out in sprints, the risk is that a change to a shared component (for example, a card product tile used on enrollment pages in all 16 languages) introduced in sprint 4 breaks layout or functionality for language variants already live in sprint 2. Maintaining isolation requires: strict use of AEM's clientlib category system so a component's styles and scripts are namespaced and never global; Git branching and pull request gates before any shared component change merges to the trunk; component-level regression testing as a sprint acceptance criterion; and Jira tracking of which components are shared versus locale-specific so sprint planning accounts for cross-market blast radius before any shared component enters a sprint.