OX-01 — Operations & Administration Experience¶

Operations Experience · Working Draft · Revised Working Copy v3 · Updated September 5, 2026

1. Objective¶

Provide the shared DragonPay operations and administration experience needed to operate supported Payment Products, investigate exceptions, administer permitted configuration, monitor integrations, and consume operational/reporting information.

OX-01 is an experience and control surface. It does not own payment state, policy decisions, reconciliation, Cases, configuration, execution, commercial records, or reporting data.

OX-01 must:

give authorized DragonPay and CU operations users a clear Tenant-scoped view of supported payments and operational work;
make payment state, movement history, exceptions, and ownership understandable without exposing internal implementation detail unnecessarily;
allow supported operational and administrative actions only through the capability that owns the underlying state;
make uncertain or high-risk payment conditions explicit rather than presenting them as ordinary failures;
expose policy-required approval state for controlled actions;
provide access to supported configuration, integration health, reporting, exports, and audit information;
preserve Tenant isolation, masking, and privileged-access controls; and
remain usable as additional Products, CUs, and execution paths are added.

OX-01 does not require a specific web framework, BFF/API-gateway pattern, application-shell implementation, database, or screen architecture.

2. Experience boundaries¶

Capability	Owner
Authentication, authorization, Tenant access, privileged audit	PH-01
Tenant Product/configuration	PH-02
Canonical payment state and hierarchy	PH-03
Product workflow/current processing state	PH-04
Party/Payment Instrument display data	PH-05
Policy Decisions and overrides	PH-06
Route Decisions	PH-07
Execution, external evidence, Connection state	PH-08
Durable payment/commercial history	PH-09
Reconciliation	PH-10
Operational Cases/corrective requests	PH-11
Transactional communications/documents	PH-12
Operational/search/reporting read capabilities	PH-13
Product-specific behavior	Applicable Payment Product
Human operations/admin experience	OX-01

OX-01 may compose these capabilities into one user experience, but authoritative state remains with the owning domain.

A UI action never bypasses the owning service's current-state validation or authorization rules.

3. Users, Tenant context, and access¶

OX-01 supports authorized DragonPay and participating-CU operational users.

The experience must:

enforce PH-01 Tenant and role/permission scope;
require multi-factor authentication for every workforce user, privileged or not;
prevent CU users from accessing another Tenant's data;
make the current Tenant context clear when a DragonPay user may work across multiple Tenants;
require explicit privileged authorization for cross-Tenant support access;
make privileged access/actions auditable;
keep production and non-production data boundaries distinct; and
treat UI visibility as convenience only — backend authorization remains authoritative.

Sensitive values are masked or omitted unless the user is explicitly authorized to view them.

Credentials, private keys, secrets, full protected payment files, and unrestricted provider payloads are not exposed in ordinary operations views.

4. Core operations experience¶

The initial experience must support the following functional areas. Exact navigation, page structure, and layout are not prescribed.

Operational overview¶

Operations should be able to see the current conditions that require attention for the selected Tenant, including where applicable:

payments currently processing;
OUTCOME_UNKNOWN or other unresolved payment conditions;
reconciliation exceptions;
open/overdue Cases;
required communication failures;
material Connection/integration availability issues; and
freshness/staleness of the displayed operational data.

Overview counts/indicators must lead to the underlying payments or Cases that explain them.

OX-01 does not create a separate attention/task lifecycle. Durable human work remains in PH-11.

Payment search¶

Authorized users must be able to locate supported payments using practical identifiers and filters such as:

DragonPay payment/execution IDs;
approved external transaction references;
Product;
date;
amount/currency;
payment/Product status;
Route Type/Connection;
reconciliation/Case state; and
approved masked participant information where supported.

Search remains read-only and Tenant-scoped.

Payment detail¶

Payment Detail must provide one understandable view of the payment while preserving the distinction between the underlying domains.

Where applicable, it should show:

Payment Request, Actions, Legs, Attempts, and Provider Transactions;
current Product/workflow state;
approved Party/Instrument display information;
policy Decision and relevant reasons/override information;
route and selected Connection;
execution outcome, handoff certainty, external references, and material evidence;
durable payment history;
reconciliation results;
operational Case status/history;
transactional communication/document status;
authorized fee/provider-cost/billing information; and
current operational owner/attention when relevant.

Current authoritative state must remain distinguishable from history, derived read data, and stale/partial information.

5. Initial PP-01 operational behavior¶

For the initial claim-based P2P Product, OX-01 must make the major Product stages and money movements independently understandable.

Operations must be able to determine, where applicable:

Sender confirmation/disclosure status;
Funding Leg outcome and whether funding is authoritative;
recipient invitation and claim-window state;
claim outcome without exposing the Sender-provided security word;
recipient destination classification;
Payout Leg route/execution outcome;
a pre-payout Return-to-Sender Action/Leg when a funded payment terminates before payout;
a post-payout return or correction, distinct from pre-payout Return-to-Sender, when present;
reconciliation result;
related Case; and
material communication outcome.

Funding, Payout, pre-payout Return-to-Sender, and post-payout return/correction must remain distinct movements.

OUTCOME_UNKNOWN on Funding, Payout, or Return must not be collapsed into a generic payment failure.

OX-01 must not tell an operator that funding, payout, or return succeeded before the applicable authoritative execution evidence exists.

CU-specific integration or provider implementation detail is shown only when it is needed for authorized technical/support investigation.

6. Cases and controlled operational actions¶

Cases¶

OX-01 provides the human interface to PH-11 Cases.

Authorized users must be able to:

find and review active/completed Cases;
understand the payment/source condition that created the Case;
see current owner, status, next action, waiting/due information, and material history;
add permitted notes/evidence/decisions;
update supported Case state/ownership; and
review related corrective-action requests and results.

OX-01 does not create its own Case workflow or Case history.

Closing a Case does not change payment state.

Corrective actions¶

Payment-affecting actions must be invoked through the capability that owns the behavior.

Examples may include:

external status inquiry;
workflow continuation/cancellation/corrective action;
reconciliation investigation/escalation;
corrective-action request;
communication resend/regeneration;
configuration publication/suspension;
policy override; or
supported Connection control.

OX-01 must show only actions that are currently permitted by the applicable Product/domain contract.

An unresolved/uncertain Attempt must not be presented with an ordinary "Retry" action when another submission could create duplicate money movement.

Approval¶

OX-01 must support and display the approval requirements determined by the owning capability, including both any Product-mandated minimum approval floor and applicable additional DragonPay/Product/Tenant policy.

OX-01 may submit a request into the applicable approval process, but must prevent execution until the owning capability reports the approval requirement as satisfied.

OX-01 does not maintain a separate approval policy, weaken a mandated approval floor, or allow the caller/UI to decide that approval is unnecessary.

7. Reconciliation¶

OX-01 must allow an authorized operator to understand reconciliation in payment context.

Where applicable, the experience should show:

current reconciliation outcome;
prior reconciliation results;
material reason/evidence summary;
pending/delayed-evidence condition;
unresolved mismatch;
related Case; and
supported investigation/escalation action.

Reconciliation status remains distinct from payment status.

OX-01 does not perform transaction matching or rewrite reconciliation/payment records.

8. Configuration administration¶

OX-01 must provide an administration experience for the configuration actually supported by implemented Products and Payment Hub capabilities.

For the initial P2P Product, authorized administrators should be able to view/manage applicable settings such as:

active Tenant Product/configuration version;
recipient contact methods;
claim expiration;
challenge/failure settings;
reminder behavior;
fee presentation;
Product disclosures;
supported Product policy/limit settings; and
Product-required Route Types/capabilities.

Configuration changes are performed through the owning capability and retain its validation, versioning, publication, authorization, and audit behavior.

OX-01 does not build a generalized rules engine, workflow designer, or arbitrary configuration platform.

9. Connection and integration operations¶

Authorized users must be able to understand the operational condition of supported execution integrations.

The experience may include:

Connection/Connector identity;
Tenant association;
operational availability;
material health/telemetry supplied by PH-08/observability;
recent failures linked to affected payments;
last relevant successful/external activity;
configuration/version information needed for support; and
supported validation, suspend/reactivate, or other operational controls.

PH-08 remains authoritative for execution/Connection behavior. PH-07 remains authoritative for route eligibility.

OX-01 does not create its own Connection-health or routing model.

Secrets and credentials are never displayed in ordinary views.

10. Communications and documents¶

OX-01 must allow authorized operations users to review material PH-12 communication/document outcomes associated with a payment.

Where supported, users may request permitted resend or regeneration through PH-12.

OX-01 does not render/send customer communications independently and does not maintain a separate communication history.

Communication failure remains separate from payment failure.

11. Reporting and exports¶

OX-01 provides the human experience for the operational/reporting capabilities exposed by PH-13.

Authorized users should be able to:

view supported operational metrics/dashboards;
run approved Tenant/DragonPay reports;
apply supported report filters;
see relevant freshness/data-as-of information;
request controlled exports; and
retrieve completed export artifacts when authorized.

Tenant/role restrictions, masking, report definitions, export controls, and data freshness remain governed by PH-01/PH-13.

OX-01 does not own a reporting database or require a particular warehouse/BI implementation.

12. Administration and audit¶

Authorized administrators must be able to perform the user/role administration required for the supported operating model through PH-01.

The experience should also make material privileged activity auditable, including where applicable:

Tenant access;
user/role changes;
configuration changes;
policy overrides;
Connection controls;
corrective-action decisions/approvals;
restricted evidence access;
reconciliation investigation/escalation actions;
communication resend/regeneration; and
report/export access.

Payment history and privileged administrative audit are related but distinct records and should not be presented as though they are the same source of truth.

13. Product stories¶

OX01-01 — Access the Operations Experience¶

Objective

Allow an authorized DragonPay or CU operations user to work within the correct Tenant/deployment context.

Required behavior

Authenticate through the approved workforce identity capability.
Require multi-factor authentication for every workforce user, privileged or not.
Apply PH-01 Tenant/role/permission scope.
Clearly identify current Tenant/deployment context.
Require explicit authorization for privileged cross-Tenant access.
Audit privileged access/actions.

Acceptance

CU users cannot access another Tenant.
Workforce authentication without multi-factor is rejected.
Unauthorized functions/data are rejected by backend authorization.
Cross-Tenant DragonPay support activity is explicitly authorized/auditable.
Sensitive values remain masked unless permitted.

OX01-02 — Find and Understand a Payment¶

Objective

Allow operations to locate a payment and understand its current state and material history.

Required behavior

Provide the operational overview described in §4.
Provide Tenant-scoped payment search using supported operational criteria.
Provide consolidated Payment Detail using authoritative/derived PH capabilities.
Preserve Payment Request/Action/Leg/Attempt/Provider Transaction distinctions.
Distinguish current state, historical events, and stale/partial read information.
Expose only authorized evidence/data.

Acceptance

An operator can find a payment by supported DragonPay or external reference.
Multi-leg/multi-attempt payments are not collapsed misleadingly.
Current state is distinguishable from payment history.
Missing/stale data is identified rather than fabricated.
Viewing a payment performs no payment mutation.

OX01-03 — Operate Initial P2P Exceptions¶

Objective

Make PP-01 Funding, claim, Payout, Return, and uncertain outcomes understandable and supportable.

Required behavior

Show Funding, claim, Payout, pre-payout Return-to-Sender, and post-payout return/correction independently.
Show claim expiration/outcome without exposing the security word.
Show same-CU versus external payout classification and material route/execution evidence.
Preserve OUTCOME_UNKNOWN on the affected movement.
Surface the related reconciliation/Case/communication context.

Acceptance

Operators can distinguish which P2P movement is unresolved.
Pre-payout Return-to-Sender and post-payout return/correction remain independently visible rather than presented as one generic Return.
OUTCOME_UNKNOWN is not presented as ordinary failure.
Payout/return success is not shown before authoritative evidence.
CU-specific implementation detail is not required to understand the Product lifecycle.

OX01-04 — Manage Cases and Controlled Actions¶

Objective

Allow authorized operations users to investigate exceptions and request supported corrective action safely.

Required behavior

Provide PH-11 Case queue/detail/history interactions required by implemented operations.
Allow supported ownership/status/note/evidence/decision actions.
Present permitted corrective actions from the owning capability.
Present/enforce approval state required by the owning capability, including any mandated approval floor.
Prevent unsafe retry/resubmission actions while external outcome is unresolved.
Leave final validation/execution to the owning service.

Acceptance

OX-01 does not create a duplicate Case or approval domain.
Case closure does not change payment state.
A caller cannot bypass approval required by the owning capability, including any mandated approval floor, through the UI.
An unresolved potentially handed-off movement does not expose a normal blind-retry action.
The target service independently validates every payment-affecting action.

OX01-05 — Administer Supported Product and Integration Configuration¶

Objective

Allow authorized administrators to manage supported Product/policy/integration settings without creating a generic configuration platform.

Required behavior

Provide administration for PP-01/Tenant Product settings required for launch/operation.
Provide supported policy/limit administration through PH-06.
Provide Connection/integration status and explicitly permitted controls through PH-08.
Preserve owning-domain validation/versioning/authorization/audit.
Never expose credentials/secrets.

Acceptance

Supported configuration can be viewed/changed only by authorized users.
Published/versioned configuration retains the owning domain's semantics.
Route/Connection controls do not bypass PH-07/PH-08 authority.
No secret values are exposed in ordinary administrative views.

OX01-06 — Review Reconciliation, Communications, and Supporting Evidence¶

Objective

Give operations the contextual supporting information needed to investigate a payment.

Required behavior

Show PH-10 reconciliation outcome/history and allowed actions.
Show material PH-12 communication/document status.
Show protected execution/evidence references according to authorization.
Keep reconciliation, communication, Case, and payment state distinct.
Submit any manual action to the owning capability.

Acceptance

Operators can understand supporting evidence without OX becoming authoritative for it.
Communication failure is not shown as payment failure.
Reconciliation results are not edited in OX.
Restricted evidence remains protected.

OX01-07 — Use Reporting, Exports, and Audit¶

Objective

Provide the operational reporting and administrative audit experience required by DragonPay and participating CUs.

Required behavior

Present supported PH-13 metrics/reports.
Show relevant data freshness.
Request/retrieve authorized controlled exports.
Provide authorized PH-01 privileged audit visibility.
Provide PH-01-backed user/role administration.
Apply Tenant/role/masking restrictions.
Keep payment history and administrative audit distinguishable.

Acceptance

Tenant users cannot report/export another Tenant's data.
Export access is controlled/auditable.
Stale reporting is identified.
OX owns no reporting database.
Administrative audit cannot be modified through OX.

14. Engineering-owned / intentionally non-prescribed detail¶

OX-01 intentionally does not prescribe:

one specific application-shell/navigation implementation;
a BFF/API gateway;
frontend/backend framework;
deployment topology;
a separate OX database;
exact screen/page structure;
exact search fields beyond those required by supported operations;
exact API/endpoint names;
browser-to-service call choreography;
exact role/permission UI;
exact Case UI model;
exact approval UI/state model;
exact health-status taxonomy;
exact operational metrics/dashboard layout;
exact Product schema-driven form framework;
exact report/export job UI;
exact audit-search implementation;
exact accessibility component implementation; or
implementation/build sequence.

Engineering should use established operations-console, secure-administration, read-composition, audit, and role-based-access patterns that satisfy this epic.

15. Scope boundaries¶

Out of scope for initial delivery¶

Customer-facing payment UX.
Payment orchestration/routing/execution logic.
Direct mutation of payment/provider/CU records.
A second authoritative payment, Case, reconciliation, configuration, or reporting database.
Generic workflow/BPM/ServiceNow replacement.
General approval engine independent of Product/operational policy.
Arbitrary rules designer.
Visual Product workflow designer.
Fully dynamic permission designer.
General-purpose BI/report builder or arbitrary SQL.
Secret/credential-management UI exposing secret values.
Every future Product/Connector/admin function before it is actually required.

16. OX-01 completion criteria¶

OX-01 is complete for the initial Product scope when:

authorized DragonPay and CU operations users can work within the correct Tenant/deployment context;
operations can locate supported payments and understand current state, hierarchy, material history, and freshness from the operations experience;
the operational overview required by §4 is available and Tenant-scoped, with counts/indicators leading to the underlying payments or Cases that explain them;
PP-01 Funding, claim, Payout, pre-payout Return-to-Sender, and post-payout return/correction are independently understandable;
OUTCOME_UNKNOWN and other uncertain money-movement states expose only safe actions permitted by the owning capability;
PH-11 Cases can be investigated and supported corrective requests/approvals can be performed without OX duplicating Case/approval ownership;
approval required by the owning capability, including any mandated approval floor, is visible/enforced without OX deciding the policy itself;
reconciliation, communications/documents, and supporting evidence are visible without being conflated with payment state;
supported PP-01/Product/policy configuration can be administered through the owning capabilities;
supported Connection/integration health and controls are available without exposing credentials or duplicating routing/execution authority;
PH-13 reports/metrics/exports and PH-01 audit information can be consumed with Tenant/role/data restrictions;
supported user/role administration required by §12 is available through PH-01;
all payment-affecting writes are authorized/revalidated by the owning capability; and
OX-01 owns no authoritative payment, reconciliation, Case, configuration, reporting, commercial, funds, or settlement state.