Architecture at a Glance¶

DragonPay Architecture at a Glance provides a high-level logical view of the platform so engineers can quickly understand the major responsibility boundaries and where to find the authoritative Product documentation behind them. This page is intentionally a navigation and orientation artifact, not a detailed architecture specification.

Logical architecture only

Components represent DragonPay responsibility boundaries defined by Product documentation. They do not establish deployable services, processes, repositories, workers, containers, databases, or infrastructure boundaries. Physical architecture is determined separately through Engineering decisions.

Arrows show the primary relationships needed to understand the platform and are not intended to represent every interface or data dependency.

Where this page and an epic disagree, the epic is authoritative — this page is derived and may lag behind an approved Product change.

For the current status of DragonPay's tracked engineering technology decisions, see Technology Stack.

High-level logical architecture¶

flowchart LR
    subgraph EXT["External Systems / Actors"]
        DB["Digital Banking Platform<br/>DragonPay SDK / Experience"]
        CORE["Financial Institution<br/>Core & Supporting Systems"]
        FEDNOW["FedNow"]
        ACH["ACH"]
        FUTURE["Future Rails / Providers<br/>RTP · Cross-Border · Stablecoin · Others"]
    end

    subgraph DP["DragonPay — Logical Architecture"]
        API["Customer Channel Boundary<br/>Sender SDK / Recipient Claim"]
        ID["Tenant, Identity, and Access<br/>PH-01"]
        PARTY["Party and Payment Instrument Foundation<br/>PH-05"]
        PAYMENT["Canonical Payment Hub Domain Model<br/>PH-03<br/><br/>Payment Request · Payment Action<br/>Payment Leg · Execution Attempt<br/>Provider Transaction"]
        EXEC["Durable Product Orchestration<br/>PH-04"]
        ROUTE["Payment Route Resolution and Selection<br/>PH-07"]
        CONNECT["Payment Execution and Connector Framework<br/>PH-08"]
        HISTORY["Payment History and Commercial Records<br/>PH-09"]
        RECON["Payment Reconciliation<br/>PH-10"]
        CASES["Operational Exceptions and Case Management<br/>PH-11"]
        NOTIFY["Transactional Communications and Documents<br/>PH-12"]
        DATA["Payment Operations and Reporting<br/>PH-13"]
    end

    DB --> API
    API --> PAYMENT
    PARTY --> PAYMENT

    PAYMENT --> EXEC
    EXEC --> ROUTE
    EXEC --> CONNECT
    ROUTE -. route decision .-> CONNECT
    CONNECT --> FEDNOW
    CONNECT --> ACH
    CONNECT --> FUTURE

    CONNECT <--> CORE

    API -. context .-> ID
    ID -. authorization context .-> PAYMENT
    ID -. authorization context .-> EXEC
    ID -. authorization context .-> ROUTE
    ID -. authorization context .-> CONNECT

    PAYMENT -. records .-> HISTORY
    EXEC -. records .-> HISTORY
    CONNECT -. external state .-> HISTORY

    HISTORY -. chronology .-> RECON
    PAYMENT -. records .-> RECON
    CONNECT --> RECON

    RECON --> CASES
    EXEC -. exceptions .-> CASES

    PAYMENT -. events / outcomes .-> NOTIFY
    EXEC -. events / outcomes .-> NOTIFY

    HISTORY -. operational data .-> DATA
    RECON -. reconciliation data .-> DATA
    CASES -. exception data .-> DATA

Two boxes carry a label that intentionally differs from a literal reading of the diagram most engineers would sketch first: Durable Product Orchestration (PH-04) decides when execution may happen but does not execute — PH-04 itself states that PH-08 "owns CU/provider execution and normalized execution evidence." Payment Execution and Connector Framework (PH-08) owns both the execution mechanics and the connector integrations that PH-04 doesn't — the two are one authoritative capability in the current Product corpus, not two.

Component-to-authoritative-documentation map¶

Logical Component	Authoritative Documentation
Customer Channel Boundary	CX-01 — P2P Channel Experience and Web SDK — the Sender Web SDK mounted in digital banking and the DragonPay-hosted Recipient claim experience. Not a platform-wide API gateway; CX-01 itself says its Channel API "does not own Product workflow or maintain a second payment database."
Operations Experience	OX-01 — Operations & Administration Experience — the separate DragonPay/CU-staff experience over Hub capabilities for operations and administration. It is a staff-facing control surface rather than a step in the member payment path, so it is not drawn as its own box.
Tenant, Identity, and Access	PH-01
Canonical Payment Hub Domain Model	PH-03
Durable Product Orchestration	PH-04
Payment Policy and Risk Decisioning	PH-06 — gates PH-04 progression before execution is authorized, and supplies the route constraints PH-07 consumes. Not drawn as its own box; see the note below the table.
Party and Payment Instrument Foundation	PH-05
Payment Route Resolution and Selection	PH-07
Payment Execution and Connector Framework	PH-08 (first concrete CU implementation: CI-01)
Payment History and Commercial Records	PH-09
Payment Reconciliation	PH-10
Operational Exceptions and Case Management	PH-11
Transactional Communications and Documents	PH-12
Payment Operations and Reporting	PH-13
P2P Product Behavior	PP-01 — Person-to-Person Payments

Three rows above have no matching diagram box, each for a different reason: PH-06 is a decisioning gate consumed by PH-04 and PH-07 rather than a distinct step in the payment path; OX-01 is a control surface over the Hub components rather than something a payment flows through; and PP-01 is the Payment Product layered on top of these Hub boundaries — as CX-01's own delivery-architecture diagram shows, DragonPay Channel API → PP-01 / Payment Hub — rather than one of the Hub's own logical components.

PH-02 (Product Configuration) and STD-01 (Platform Engineering and Resilience Standards) are intentionally not represented at all above: PH-02 is a setup-time/administrative concern rather than a box on the payment path, the same treatment the Product Overview diagram gives PH-01; STD-01 is a cross-cutting engineering standard, not a domain-boundary document, and is already reachable from Engineering Governance & Delivery. Neither materially changes this page's logical architecture.

This diagram shows domain/responsibility boundaries, not deployment topology — for the channel/deployment view (which apps talk to which layer, and where the Connector/Integration sit relative to the CU's core systems), see the diagram in Product Overview.