Skip to content

PH-02 — Product Configuration

Payment Hub · Working Draft · Revised Working Copy v7 · Updated September 3, 2026

1. Objective

Provide the Tenant-specific Product assignment and configuration required for DragonPay to operate supported payment Products for each credit union.

DragonPay CU onboarding is a managed process performed with the customer over an extended implementation period. PH-02 provides the application capabilities needed to configure, approve, activate, change, suspend, and retain the history of a Tenant's Product configuration. It does not attempt to automate the complete CU onboarding or production-readiness process.

PH-02 establishes:

  • the DragonPay Products supported by the platform;
  • assignment of a supported Product to a Tenant;
  • Tenant-specific Product configuration;
  • separation of work-in-progress configuration from configuration used by payment processing;
  • validation of Product configuration;
  • approval/publication of configuration for runtime use;
  • immutable configuration history;
  • binding of payment activity to the configuration version that governed it; and
  • Product-level activation, suspension, reactivation, and retirement.

2. Ownership boundaries

Owner Responsibility
PH-02 Supported Product identity, Tenant Product assignment, Tenant-specific Product settings, configuration lifecycle/history, and Tenant Product status.
PH-01 Tenant identity and authorization for Product administration.
Payment Product epics Product behavior and the settings/rules that are configurable for that Product.
PH-03 Canonical payment records and the configuration-version reference associated with payment processing.
PH-04 Uses the applicable Product configuration when initiating Product processing and retains the configuration version used by in-flight processing.
PH-07 / PH-08 Routing, configured execution capability, provider connectivity, and runtime execution readiness.
CI / RI epics CU- and provider-specific integration behavior and implementation.
Operations / onboarding process Determines when the overall CU implementation, certification, and operational onboarding are ready for production activation.

PH-02 validates configuration DragonPay can determine programmatically. It does not replace human onboarding, certification, operational approval, or other implementation activities required to launch a CU.

3. Product configuration model

3.1 Product

A Product identifies a payment capability supported by DragonPay, such as P2P.

Each Product defines the Tenant-specific settings that may be configured for it and the rules necessary to determine whether those settings are valid.

The supported Product catalog is controlled by DragonPay. Tenant administrators cannot create arbitrary DragonPay Products.

3.2 Tenant Product

A Tenant Product represents one DragonPay Product assigned to one Tenant.

Its lifecycle indicates whether the Product is:

  • DRAFT — assigned and being prepared/configured;
  • ACTIVE — available for new Product activity;
  • SUSPENDED — temporarily unavailable for new Product activity; or
  • RETIRED — permanently unavailable for new Product activity.

A Tenant may have at most one assignment of a given Product.

Suspension or retirement does not alter prior configuration or payment history.

3.3 Product configuration

A Tenant Product may have Tenant-specific settings defined by the owning Product.

Examples may include:

  • Product limits;
  • expiration periods;
  • supported Product options;
  • Product-specific policy selections; or
  • other settings whose values legitimately vary by CU.

PH-02 must not become a general-purpose arbitrary configuration store. A setting is stored as Product configuration only when the owning Product defines it as configurable.

3.4 Configuration versions

Configuration changes are prepared separately from configuration currently used for payment processing.

A configuration version is either:

  • work in progress; or
  • published for runtime use.

Work-in-progress configuration may be modified without affecting active payment processing.

Once published, a configuration version is immutable.

Publishing a later version does not alter an earlier published version or the historical record of which configuration governed prior payment activity.

The exact persistence representation and configuration-version numbering mechanism are engineering decisions.

4. Configuration validation and onboarding readiness

PH-02 validates configuration rules that DragonPay can determine directly, for the Product configuration it owns.

Examples include:

  • required settings are present;
  • values conform to the Product's supported configuration;
  • unsupported settings or combinations are rejected; and
  • referenced configuration owned by PH-02 exists where required.

Overall Tenant/Product launch readiness — including integration setup, testing, certification, route setup, customer approval, and other onboarding work — is determined by authorized DragonPay operations personnel through the managed onboarding process, not validated or gated by PH-02 itself. PH-02 records the resulting Product activation state once authorized personnel confirm the Tenant Product is ready to activate; it does not automatically validate or require evidence from other Hub capabilities or external integrations.

Temporary runtime conditions such as a momentary provider outage do not by themselves invalidate an otherwise approved Tenant Product configuration.

5. Runtime configuration behavior

When new Product activity begins, DragonPay determines the currently published configuration for that Tenant Product and associates that configuration version with the payment.

That association is retained for the life of the payment unless the Product explicitly defines different behavior.

Publishing a later configuration version affects subsequent new Product activity. It does not silently change the configuration governing an already-started payment.

Historical published versions remain retrievable so DragonPay can determine which configuration governed prior or in-flight activity.

For the initial implementation, configuration changes become effective when authorized personnel publish/activate them. Scheduled future-effective configuration is not required.

6. Product administration and lifecycle

Authorized DragonPay personnel must be able to:

  • assign a supported Product to a Tenant;
  • create and modify work-in-progress Tenant Product configuration;
  • validate configuration;
  • publish approved configuration;
  • activate the Tenant Product;
  • view current and historical configuration;
  • create a new configuration version when changes are required;
  • suspend new Product initiation;
  • reactivate the Product when appropriate; and
  • retire the Tenant Product when it will no longer be offered.

CU administrators may be given appropriate visibility or administration rights when permitted by the operating model, but all access remains Tenant-scoped through PH-01.

Material Product assignment, configuration publication, and lifecycle changes must be auditable.

Exact administration APIs, UI design, approval workflow, implementation sequencing, and event-delivery mechanism are engineering decisions.

7. Product stories

PH02-01 — Assign and Manage a Tenant Product

Objective

Associate a supported DragonPay Product with a Tenant and maintain its Product-level lifecycle.

Required behavior

  • Assign a supported Product to an active Tenant.
  • Prevent duplicate assignment of the same Product to the same Tenant.
  • Begin the Tenant Product in DRAFT while onboarding/configuration is underway.
  • Support transition to ACTIVE after required Product configuration and onboarding approval are complete.
  • Allow an ACTIVE Tenant Product to be SUSPENDED and later reactivated.
  • Allow a Tenant Product to be RETIRED.
  • Prevent SUSPENDED or RETIRED Tenant Products from initiating new Product activity.
  • Preserve prior configuration, payment, and audit history when lifecycle state changes.

Acceptance

  • DragonPay can determine which Products are assigned to each Tenant.
  • One Tenant cannot access or administer another Tenant's Product assignment.
  • A newly assigned Product cannot initiate payment activity until activated.
  • Suspension blocks new Product activity without deleting configuration or payment history.
  • Retirement prevents future Product initiation and preserves historical records.

PH02-02 — Configure a Tenant Product

Objective

Maintain the Tenant-specific settings required to operate a DragonPay Product for a CU.

Required behavior

  • Allow authorized personnel to create and modify work-in-progress Product configuration.
  • Restrict configuration to settings defined by the owning Product.
  • Validate required values and supported combinations using Product-defined rules.
  • Reject invalid configuration rather than silently accepting unsupported settings.
  • Allow configuration to be changed throughout onboarding without affecting configuration already in runtime use.
  • Retain configuration history as new versions are created and published.

Acceptance

  • P2P or another supported Product can define the settings it requires without PH-02 adding Product-specific fields to its core model.
  • Invalid Product configuration cannot be published for runtime use.
  • Editing work-in-progress configuration does not change active payment behavior.
  • Tenant configuration remains isolated from other Tenants.

PH02-03 — Publish and Bind Product Configuration

Objective

Make an approved Tenant Product configuration available for payment processing while preserving the configuration used by existing payments.

Required behavior

  • Publish only configuration that satisfies the Product's validation requirements.
  • Require authorized personnel to confirm onboarding readiness before initial Product activation.
  • Treat a published configuration version as immutable.
  • Make the currently published version applicable to new Product activity.
  • Associate new payment activity with the configuration version governing it.
  • Preserve that configuration-version association for in-flight and historical payment processing.
  • Allow a later configuration version to be published without changing the configuration already associated with existing payments.
  • Keep previous published versions available for retrieval and investigation.

Acceptance

  • Work-in-progress configuration is never used accidentally as runtime Product configuration.
  • Initial activation cannot occur until valid configuration and required onboarding approval exist.
  • A payment started using configuration V1 remains associated with V1 after V2 is published.
  • New payment activity after publication of V2 uses V2.
  • Published versions cannot be modified in place.
  • DragonPay can retrieve the configuration version associated with a historical or in-flight payment.

PH02-04 — Change, Suspend, and Administer Product Configuration

Objective

Allow DragonPay to operate and maintain a Tenant Product after initial onboarding.

Required behavior

  • Show authorized administrators the Tenant Product's current lifecycle state and currently published configuration.
  • Retain and expose prior published configuration versions needed for support, investigation, and change management.
  • Allow configuration changes to be prepared as a new work-in-progress version and published when approved.
  • Allow an ACTIVE Tenant Product to be suspended without modifying its published configuration.
  • Allow a SUSPENDED Tenant Product to be reactivated after authorized personnel confirm that required configuration and operational prerequisites remain satisfactory.
  • Record material Product lifecycle and configuration-publication activity for audit.

Acceptance

  • An administrator can determine the Product configuration currently governing new activity.
  • Prior published configurations remain available after changes.
  • Configuration changes do not overwrite previously published versions.
  • Suspension affects new Product initiation without rewriting historical configuration.
  • Reactivation does not require a new configuration version unless configuration itself must change.
  • Tenant-scoped administrators cannot access another Tenant's Product configuration.

8. Deferred capabilities

The following are not required for the initial PH-02 implementation:

  • scheduled or future-dated configuration activation;
  • multiple simultaneously scheduled future configuration versions;
  • automated determination of complete CU onboarding readiness;
  • a generalized prerequisite-evidence framework across Payment Hub components;
  • advanced configuration comparison or diff UI;
  • customer-defined Products or arbitrary Product configuration schemas;
  • sophisticated Product-registration/deployment protocols defined as Product behavior; and
  • PH-02-specific event taxonomies or delivery protocols beyond shared DragonPay platform requirements.

These capabilities may be introduced when actual onboarding or operating experience demonstrates the need.

9. Epic relationships and scope boundaries

Owner PH-02 relationship
PH-01 Provides Tenant identity and authorization for Product administration.
PH-03 Retains the Product/configuration reference required by canonical payment processing.
PH-04 Uses the applicable configuration when Product processing begins and continues using the version associated with in-flight processing.
PH-06 Consumes Product-defined settings where policy/risk behavior requires them.
PH-07 Owns routing capability and route eligibility. Product onboarding may require routes to be configured, but PH-02 does not own routing.
PH-08 Owns provider/Connection configuration and runtime execution state.
PP epics Define Product behavior, configurable settings, validation rules, and business prerequisites for that Product.
CI / RI epics Implement CU/provider-specific integration requirements.
Engineering / Operations Own deployment mechanics, implementation architecture, onboarding procedures, certification, technical readiness checks, and operational change procedures.

Out of scope

  • Complete CU onboarding workflow or project management.
  • Payment workflow/orchestration.
  • Transaction routing or rail selection.
  • Connector/Connection configuration and execution.
  • CU/provider-specific integration implementation.
  • Payment-domain persistence.
  • Policy/risk decisions.
  • Reconciliation or notification delivery.

10. PH-02 completion criteria

PH-02 is complete for the initial Product scope when:

  • a supported Product can be assigned to a Tenant;
  • authorized personnel can prepare and change Tenant-specific Product configuration during onboarding;
  • Product configuration can be validated against the owning Product's requirements;
  • approved configuration can be published and used for new Product activity;
  • published configuration versions are immutable and historical versions remain retrievable;
  • each new payment can be associated with the configuration version governing it;
  • later configuration changes do not silently change the configuration associated with existing payments;
  • a Tenant Product can be activated, suspended, reactivated, and retired;
  • material Product/configuration administration is auditable; and
  • PH-02 does not attempt to automate the entire CU onboarding, certification, or production-readiness process.