Composable Commerce Architecture: [Brand or programme name]

Solution architecture for a composable (MACH) digital commerce platform: packaged business capabilities for the commerce engine, product information management (PIM), content management (CMS), search and merchandising, order management (OMS), payments, promotions and the customer data platform (CDP), a headless frontend with a backend for frontend (BFF), the integration and data ownership model, peak-season performance, PCI DSS scope reduction with hosted payment fields, vendor selection and the migration from a commerce monolith. It follows the MACH principles as described by the MACH Alliance (Microservices, API-first, Cloud-native SaaS, Headless; framed in 2026 as open, composable and connected technology) and PCI DSS v4.0.1 for payment scope. Replace every [bracketed] value and every row marked Example. Payment and privacy sections are a documentation format, not legal or compliance advice.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Business context and peak profile
3. Architecture principles
4. Business capabilities and packaged business capabilities
5. Target architecture
6. Component design
7. Frontend and backend for frontend
8. Integration and orchestration
9. Customer data, identity and personalisation
10. Performance and peak readiness
11. Security and PCI DSS scope reduction
12. Vendor selection
13. Migration from the monolith
14. Operating model, cost and governance
15. Decisions, risks and traceability
16. Glossary and references

1. Introduction and scope

1.1 Purpose

This document defines the target commerce architecture for [programme name]: the business capabilities, the products chosen to deliver them, which product owns which data, how the customer-facing experience is composed from them, how the platform behaves at peak, how card data stays out of scope, and how the current platform is retired. It is the reference for product teams, system integrators and vendors.

1.2 Drivers and outcomes

1.3 Scope

2. Business context and peak profile

2.1 Commerce profile

2.2 Peak calendar

3. Architecture principles

The MACH Alliance now frames its principles as open, composable and connected technology. Treat PRI-001 to PRI-004 as the technical form of those three goals: open contracts, modular capabilities and real-time connection through APIs and events.

4. Business capabilities and packaged business capabilities

4.1 Capability map

Keep the enterprise view in the Business Capability Map (architecture/business-capability-map); this table is the commerce slice.

4.2 PBC register

5. Target architecture

The target architecture has five layers. Channels call only the BFF; the BFF calls capability APIs; capabilities exchange business events through the integration layer; enterprise systems connect through the same layer.

6. Component design

6.1 Commerce engine

• Owns catalogue structure, price lists, promotions and carts; exposes cart, checkout and order placement APIs. It is the only place that computes a cart total. The quote boundary and stock reservation logic are designed in system-design/design-ecommerce-checkout-inventory.
• Decide early whether the engine or a separate pricing service owns prices for B2B contracts.
• Check vendor API rate limits, webhook delivery guarantees and multi-store or multi-market modelling against section 2.

6.2 PIM and DAM

• PIM is the system of record for product attributes and enrichment workflow; it publishes approved products to the commerce engine, search and marketplaces.
• Define a completeness rule per channel (for example images, size chart, translated description) that gates publication.
• DAM stores master assets; the CDN or an image service renders variants at the edge.

6.3 CMS

• Headless CMS owns pages and content entries; product data is referenced by identifier, never copied into content.
• Give merchandisers preview of a page with live product data and scheduled publication for peak events.

6.4 Search and merchandising

• The search index is derived from PIM, commerce engine (prices, availability flags) and inventory events; it is never a system of record.
• Merchandisers control boosting, pinning and synonyms through the search product; record the freshness requirement for prices and availability in the index (for example under 60 seconds).
• Recommendations follow system-design/design-recommendation-system and are composed by the BFF.

6.5 OMS

• The OMS owns the order after placement: sourcing across warehouses and stores, splits, fulfilment status, cancellations and returns. The commerce engine hands over at order placement.
• Available-to-promise data flows from the OMS or inventory service to the commerce engine and search with an agreed latency.

6.6 Payments

• A payment service provider (PSP) hosts the card entry fields or the payment page; the platform receives tokens and authorisation results only (section 11).
• Use the PSP's webhooks for asynchronous results and reconcile daily with settlement reports.

6.7 CDP

• The CDP builds the unified profile and segments from consented events; it is not the system of record for consent, which stays with the consent management platform and identity provider.
• Activation to marketing tools uses segments, not raw event streams.

7. Frontend and backend for frontend

BFF rules:

1. The BFF holds no business rules that belong to a PBC (prices, promotions, eligibility).
2. Every downstream call has a timeout, a fallback (cached response, hidden widget or degraded message) and a circuit breaker.
3. Secrets for SaaS APIs stay in the BFF; the browser receives only scoped, short-lived tokens.

8. Integration and orchestration

8.1 Integration patterns

8.2 Data ownership matrix

8.3 Process orchestration

Order-to-cash spans the commerce engine, PSP, OMS, WMS and ERP. Keep one orchestrator per process:

• Checkout is orchestrated by the commerce engine (or checkout service) up to order placement.
• Fulfilment, cancellation and returns are orchestrated by the OMS.
• Refunds are requested by the OMS and executed by the PSP; finance postings flow from the OMS to ERP through the integration layer.

9. Customer data, identity and personalisation

Record the processing in the Record of Processing Activities (compliance/gdpr-ropa) and assess high-risk profiling in a DPIA (compliance/dpia).

10. Performance and peak readiness

10.1 Peak estimate

Consequences: the commerce engine and search contracts must allow at least the origin rate with headroom (for example 2 times), the cache hit rate is itself a requirement to test, and checkout must stay healthy at 3.3 orders per second even if browse traffic exceeds the forecast. If the contracted limit is lower, enable a checkout queue at the edge as designed in system-design/design-ecommerce-checkout-inventory.

10.2 Peak readiness checklist

10.3 Non-functional requirements

11. Security and PCI DSS scope reduction

11.1 Payment capture options

Example choice: hosted payment fields with wallet buttons (for example Apple Pay and Google Pay through the PSP) and redirect for alternative payment methods.

11.2 Controls

• PCI DSS v4.0.1 is the only active version (published June 2024; v4.0 retired at the end of 2024). Map scope with PCI DSS Scoping and Segmentation (compliance/pci-dss-scoping-segmentation).
• In January 2025 the PCI SSC removed the payment page script requirements (6.4.3 and 11.6.1) and the related targeted risk analysis (12.3.1) from SAQ A, effective 31 March 2025, and added an eligibility criterion: the merchant confirms its site is not susceptible to script attacks that could affect its e-commerce systems. Keep evidence for that confirmation: content security policy, subresource integrity or script inventory, and tamper monitoring on checkout pages.
• Restrict who can change checkout page templates and tag manager containers; review third-party scripts on checkout pages at every release.
• Tokens from the PSP are stored in the commerce engine or PSP vault only; never log full PSP responses.
• Apply bot management, credential-stuffing defences and rate limits at the edge; see security/threat-model for the checkout threat model.

12. Vendor selection

12.1 Criteria and weights

12.2 Worked example: commerce engine

Scores use a 1 to 5 scale. Vendor A: 4 times 0.30 plus 3 times 0.20 plus 5 times 0.20 plus 4 times 0.15 plus 3 times 0.15 equals 3.85. A difference of 0.10 is within scoring noise; break the tie with the proof-of-concept results and exit terms. Use the Vendor Evaluation Scorecard (business/vendor-evaluation-scorecard) and the Build vs Buy Analysis (architecture/build-vs-buy-analysis).

12.3 Suite versus composable check

13. Migration from the monolith

Keep URLs, redirects and structured data stable to protect search rankings; plan data moves with the Data Migration Strategy (architecture/data-migration-strategy) and cutovers with the Cutover Plan (project/cutover-plan).

14. Operating model, cost and governance

14.1 Ownership

14.2 Cost model

14.3 Governance

• Architecture decisions go to the Architecture Decision Log (architecture/architecture-decision-log).
• A new PBC or replacement of a PBC needs an updated data ownership matrix and exit plan.
• Vendor service levels are tracked monthly against the Service Level Agreement template (ops/service-level-agreement).

15. Decisions, risks and traceability

15.1 Decisions

15.2 Risks

15.3 Traceability matrix

16. Glossary and references

16.1 Glossary

16.2 References

Standard and licence note

Structure aligned with the MACH principles as described by the MACH Alliance and with the PCI DSS v4.0.1 scoping approach for e-commerce payment capture. PCI DSS is a PCI Security Standards Council standard; this template cites requirement numbers and self-assessment questionnaire names only and reproduces no requirement text. MACH Alliance material is referenced by name; no text is copied. Product categories are named generically; any vendor or product names you add are trademarks of their owners, and this template is not affiliated with or endorsed by them. This template is original text written for this collection. Check the current official versions before use. This is a documentation format, not legal or compliance advice. Template licence: MIT.