Skip to content

PH-11 — Operational Exceptions and Case Management

Payment Hub · Working Draft · Revised Working Copy v5 · Updated September 4, 2026

1. Objective

Provide the minimum operational Case capability required when a payment-related condition cannot be resolved safely through normal automated Product processing, execution recovery, policy decisioning, or reconciliation.

PH-11 establishes:

  • one Case for one unresolved operational condition without uncontrolled duplication;
  • current ownership, status, priority, waiting state, next action, and aging information needed to operate an exception queue;
  • durable investigation history containing material notes, evidence references, decisions, and follow-up;
  • secure linkage to authoritative payment, policy, execution, reconciliation, and commercial records rather than copying them;
  • permission-controlled operational decisions and corrective-action requests;
  • support for additional/dual approval when applicable DragonPay, Product, or CU policy requires it;
  • submission of approved corrective requests to the service that owns the affected payment behavior; and
  • downstream visibility of Case status/history for operations and reporting.

PH-11 is outside the normal successful-payment path.

It is not a general CRM, customer-support platform, fraud case-management suite, AML/sanctions platform, dispute platform, enterprise incident-management system, or general workflow engine.

The exact Case database schema, workflow implementation, approval mechanism, API design, task model, event transport, optimistic-locking strategy, and operational UI are Engineering decisions provided the Product requirements in this epic are preserved.

2. Ownership boundaries

Owner Responsibility
PH-01 Identity, permissions, and authorization for Case access and controlled actions.
PH-03 Canonical Payment Request, Action, Leg, Execution Attempt, Provider Transaction, and payment state.
PH-04 Product workflow, retry authorization, workflow resumption, and creation of corrective Payment Actions where applicable.
PH-06 Policy Decisions, review-required outcomes, and policy overrides.
PH-07 Route Decisions.
PH-08 External execution, inquiry, handoff certainty, and execution evidence.
PH-09 Durable payment/commercial history.
PH-10 Automated reconciliation and mismatch/unknown-outcome evaluation before escalation.
PH-11 Operational Case state, investigation history, and controlled requests for corrective action.
PH-13 / Data Platform Queue presentation, consolidated payment + Case views, and analytics/reporting.

PH-11 never directly changes another epic's authoritative payment record.

A human decision may authorize or request a follow-up action, but the owning service independently validates and performs that action.

3. When a Case is created

Normal automated processing should complete or exhaust the safe automated path before a Case is created, unless Product/policy explicitly requires human review.

Cases may be created for conditions such as:

  • unresolved external payment outcome;
  • material reconciliation mismatch;
  • suspected duplicate payment;
  • policy/manual review requirement;
  • execution exception that cannot proceed safely automatically;
  • payment/reference data inconsistency;
  • commercial-record exception requiring operational review; or
  • another supported Product/operations exception.

These are examples, not a requirement for a fixed universal Case taxonomy.

Expected Product behavior that completes normally should not create a Case merely because it involves a decline, expiration, return, or another expected branch.

4. Case identity and deduplication

A Case represents one operationally distinct unresolved condition.

DragonPay must prevent repeated delivery of the same condition/evidence from creating uncontrolled duplicate active Cases.

A Case must retain:

  • Tenant;
  • affected payment and more specific Action/Leg/Attempt/Provider Transaction when applicable;
  • source condition or source record;
  • reason/type of exception;
  • current owner/team;
  • current operational status;
  • priority/severity/customer-impact information when needed for queue management;
  • current next action;
  • waiting/follow-up information when applicable;
  • material due/escalation timing when applicable; and
  • final resolution when the operational determination is complete.

A materially different unresolved condition may require a separate Case even when it concerns the same Payment Request.

If duplicate Cases are discovered later, operations must be able to relate/close the duplicate without losing its prior history.

The exact deduplication key and persistence mechanism are Engineering decisions.

5. Investigation history and evidence

PH-11 must preserve a durable history of material Case activity.

This may include:

  • Case creation;
  • ownership/assignment changes;
  • notes;
  • evidence reviewed;
  • waiting/follow-up changes;
  • operational decisions;
  • corrective-action requests;
  • corrective-action results;
  • resolution/closure; and
  • reopening because of new material evidence.

Recorded Case activity is append-only. A correction or changed interpretation is recorded as new activity; prior activity is not modified or removed.

Evidence handling

PH-11 references authoritative evidence rather than copying sensitive source data.

A Case may reference:

  • PH-03 payment objects;
  • PH-06 policy Decisions;
  • PH-07 Route Decisions when relevant;
  • PH-08 execution/provider evidence;
  • PH-09 payment/commercial history;
  • PH-10 reconciliation results;
  • secure external evidence; and
  • approved CU/provider evidence.

Raw provider payloads, files, credentials, account numbers, and other restricted data remain in their authoritative/protected storage.

6. Case lifecycle

The Product requires a simple operational lifecycle sufficient to distinguish:

  • newly opened work;
  • active investigation;
  • waiting for another party/evidence;
  • pending approved corrective work;
  • operationally resolved; and
  • closed/completed.

A Case may be reopened when new material evidence invalidates or materially changes the prior resolution.

Closing or resolving a Case does not itself:

  • change payment state;
  • mark an Execution Attempt successful or failed;
  • create another payment movement;
  • change a reconciliation result;
  • alter a Policy Decision; or
  • modify an external provider/CU record.

Those changes occur only through the domain that owns them.

A Case may not be closed while a corrective-action request it submitted remains unresolved.

The exact status names and transition matrix are Engineering decisions as long as these operational distinctions remain possible.

7. Corrective-action requests

When a human operational decision requires another DragonPay capability to act, PH-11 records and submits a controlled corrective-action request.

Examples may include requesting the owning service to:

  • resume or continue Product workflow;
  • evaluate whether a new Execution Attempt is safe;
  • initiate a Product-defined Return/Reversal/Refund Action;
  • query external execution status;
  • reprocess safe inbound evidence;
  • associate authoritative external transaction evidence;
  • recheck reconciliation;
  • create a commercial adjustment; or
  • perform another supported controlled action.

PH-11 does not implement those payment/commercial actions itself.

The target service:

  • independently validates current authoritative state;
  • validates that the requested action is supported and safe;
  • performs the actual state transition/payment behavior when allowed; and
  • returns the authoritative result/reference to PH-11.

A Case decision or approval never bypasses the safeguards of the target service.

8. Approval policy

Payment-affecting manual actions must be permission-controlled and auditable.

PH-11 must support additional approval, including dual/maker-checker approval, when required by applicable:

  • DragonPay operational policy;
  • Product policy;
  • Tenant/CU policy; or
  • another approved control requirement.

A manual operational action that can initiate, repeat, reverse, or otherwise directly cause external payment movement requires independent approval by a second authorized person before execution. Policy may require independent approval for additional actions but must not remove this minimum control.

The approval requirement is determined from authoritative policy/configuration, not from caller preference.

A requester cannot bypass a required approval by omitting or altering a caller-supplied approval indicator.

When policy requires independent approval:

  • the approval must be performed by an appropriately authorized actor;
  • the approval actor must be independent/distinct when the applicable policy requires separation of duties;
  • the approval decision/reason is retained; and
  • the corrective request cannot be submitted until required approval is satisfied.

An approval applies only to the request content that was approved; a material change to the request after approval invalidates it and requires re-approval.

When policy does not require dual approval, PH-11 may submit an otherwise authorized corrective request without manufacturing an additional approval step.

Approval policy may vary by action type, Product, Tenant, risk context, payment state, or other supported conditions.

The exact policy storage/rule mechanism is Engineering/Product configuration detail.

9. Operational queue

PH-11 must provide enough current information for operations to identify and manage exception work without relying on the analytical warehouse for each screen.

The queue must support, at minimum, practical visibility into:

  • Case identity;
  • Tenant/payment;
  • reason/type;
  • current status;
  • owner;
  • priority/impact when applicable;
  • waiting condition;
  • next action;
  • age;
  • due/overdue state when applicable;
  • unresolved corrective action/approval state; and
  • related payment/execution/reconciliation context.

PH-13 may combine this Case information with authoritative payment and execution summaries for a consolidated operator view.

Material Case outcomes and lifecycle changes must be available to PH-09 for durable payment/commercial history and to PH-13/Data Platform for operational and analytical consumption. PH-09 receives only those Case outcomes and decisions material to payment or commercial history; PH-13/Data Platform may consume the broader operational stream. The publication/transport mechanism is an Engineering/shared-standard concern.

The exact search fields, indexes, SLA metrics, dashboards, and assignment algorithms are Engineering/Operations decisions.

10. Example behaviors

Unknown payout outcome

A Payout Attempt remains OUTCOME_UNKNOWN after available automated inquiry/reconciliation cannot resolve whether external handoff resulted in a payment.

PH-11 opens or updates one Case for that unresolved condition.

Operations reviews the authoritative evidence.

If later evidence establishes that no external payment was accepted, an operator may request the Product/execution owner to evaluate another Payout Attempt.

If policy requires dual approval for that request, PH-11 obtains it before submission.

PH-04/PH-08 still independently determine whether another payment submission is safe.

Reconciliation mismatch

PH-10 identifies a material amount or reference mismatch requiring investigation.

PH-11 tracks the investigation, evidence, responsible owner, and resulting operational decision.

If a correction is required, PH-11 requests it from the owning payment/CU/commercial capability.

Closing the Case does not rewrite the prior reconciliation result.

Manual policy review

PH-06 returns a review-required outcome.

PH-11 provides the work queue and investigation history needed for an authorized operator to decide the supported disposition.

Any resulting policy/workflow change occurs through PH-06/PH-04 rather than by changing payment state directly in PH-11.

11. Product stories

PH11-01 — Open and Manage an Operational Case

Objective

Maintain one operational Case for one unresolved payment-related condition.

Required behavior

  • Open or return the active Case for the same logical unresolved condition.
  • Retain affected payment/source references.
  • Maintain current owner, status, priority/impact, next action, and waiting/due information needed for operations.
  • Prevent repeated delivery of the same condition from creating uncontrolled duplicate active Cases.
  • Allow materially different conditions on the same Payment Request to remain separate.
  • Support resolving, closing, and reopening when justified by new evidence.

Acceptance

  • Repeated equivalent triggers do not create multiple uncontrolled active Cases.
  • Operations can determine who owns the Case and what should happen next.
  • Waiting/overdue conditions can be identified.
  • Resolving/closing the Case does not change authoritative payment state.

PH11-02 — Preserve Investigation and Decision History

Objective

Maintain an auditable Case history without duplicating authoritative payment/provider records.

Required behavior

  • Preserve material notes, evidence references, decisions, ownership/waiting changes, corrective requests/results, and lifecycle events.
  • Keep prior material Case activity available when later evidence changes the interpretation.
  • Reference sensitive evidence in its authoritative secure location.
  • Record actor and reason for material operational decisions.
  • Avoid using the Case as a second payment journal.

Acceptance

  • Operations can understand what evidence was reviewed and why a decision was made.
  • Prior material Case history is not silently overwritten.
  • Sensitive provider/payment evidence is referenced rather than copied unnecessarily.
  • Case history does not replace PH-03/08/09/10 authoritative records.

PH11-03 — Request Corrective Action from the Owning Service

Objective

Allow operations to request a supported corrective action without PH-11 directly changing payment behavior.

Required behavior

  • Create a controlled request identifying the Case, target owner, target payment/source object, requested action, and reason.
  • Permit only actions supported by the target service/Product.
  • Prevent duplicate submission of the same logical corrective request.
  • Submit the request only when the required authorization/approval policy is satisfied.
  • Record the owning service's authoritative result/reference.
  • Do not fabricate successful payment/commercial state when the owning service rejects or cannot complete the request.

Acceptance

  • PH-11 never directly creates another payment movement or changes PH-03/06/08/09/10 authoritative state.
  • The target service independently revalidates the request.
  • Duplicate delivery does not create uncontrolled duplicate corrective actions.
  • Target-service failure/rejection remains visible as such.

PH11-04 — Enforce Policy-Based Approval

Objective

Apply the additional approval controls required for a manual corrective action.

Required behavior

  • Determine required approval from authoritative Product/Tenant/DragonPay policy.
  • Do not trust a caller-supplied value to determine whether approval is required.
  • Support independent second approval when policy requires maker-checker control.
  • Require appropriately authorized actors for request and approval.
  • Preserve approval decision, actor, and reason.
  • Allow actions not requiring dual approval to proceed without an unnecessary approval step.

Acceptance

  • A caller cannot bypass policy-required approval.
  • A policy requiring independent approval cannot be satisfied by the same actor when separation of duties is required.
  • A policy not requiring dual approval does not automatically create one.
  • Approval does not bypass safety checks performed by the target service.

PH11-05 — Provide Operational Case Visibility

Objective

Provide the current exception queue and Case context needed by DragonPay operations.

Required behavior

  • Surface open/active/waiting/pending-action Cases and current ownership.
  • Surface aging, due/overdue state, priority/impact, and next action when applicable.
  • Expose material Case history and related authoritative payment/execution/reconciliation references.
  • Support PH-13/Data Platform consumption for operational views and analytics.
  • Keep reporting/warehouse availability independent from Case correctness.

Acceptance

  • Operations can identify unresolved/overdue work without reconstructing history from unrelated systems.
  • PH-13 can display Case context alongside the affected payment.
  • Analytical reporting can consume Case data without becoming the authoritative Case store.
  • Reporting outages do not prevent Case creation or updates.

12. Engineering-owned / intentionally non-prescribed detail

PH-11 intentionally does not prescribe:

  • physical Case/activity/corrective-action-request table schemas;
  • a fixed Case-type taxonomy;
  • exact Case status names or transition matrix;
  • source-condition key format;
  • exact priority/severity/customer-impact enums;
  • optimistic-concurrency fields/strategy;
  • Case-local sequence allocation;
  • exact API/endpoint names;
  • exact command/event envelopes already governed by shared standards;
  • request-fingerprint or idempotency-record implementation;
  • transactional-outbox/event mechanics;
  • exact approval-policy storage/rule engine;
  • a universal list of actions requiring second approval;
  • separate Task/Assignment/Evidence/Note/Decision/SLA subsystems;
  • exact queue/search fields;
  • metrics catalogs;
  • assignment algorithms;
  • operations UI implementation; or
  • implementation/build sequence.

Engineering should use established Case-management, authorization, audit-history, approval, idempotency, and secure-evidence patterns appropriate to the actual operational scope.

Useful technical approaches explored in earlier PH-11 versions may be retained as non-authoritative Engineering reference material where they remain helpful.

13. Scope boundaries

Out of scope

  • Normal payment orchestration or execution.
  • Direct modification of PH-03/PH-06/PH-08/PH-09/PH-10 records.
  • General BPM/workflow design platform.
  • Customer-support CRM/ticketing.
  • Enterprise incident/problem management.
  • Full fraud investigation/model-management platform.
  • AML/sanctions/regulatory case management.
  • Disputes/chargebacks unless later Product requirements add them.
  • CU/provider collaboration portal.
  • Advanced task-routing/skills-based assignment.
  • Bulk Case processing for the initial Product.
  • Payment movement.
  • Settlement balances.
  • Prefunding.
  • Reserves.
  • Liquidity.
  • Custody of customer funds.

14. PH-11 completion criteria

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

  • unresolved conditions from implemented payment, policy, execution, and reconciliation flows can create/update one operational Case without uncontrolled duplication;
  • operations can identify current Case owner, status, next action, waiting/due state, and material priority/impact;
  • material investigation history and decisions remain available without copying sensitive authoritative evidence into the Case;
  • Cases can be resolved, closed, and reopened without losing prior history, and a Case cannot be closed while a corrective-action request it submitted remains unresolved;
  • resolving/closing a Case does not itself change payment/execution/reconciliation/commercial state;
  • corrective actions are requested from and independently validated by the service that owns the target behavior;
  • duplicate corrective requests cannot create uncontrolled duplicate payment/commercial actions;
  • approval requirements are derived from Product/Tenant/DragonPay policy rather than caller input;
  • independent dual approval is supported and enforced when the applicable policy requires it, and is always enforced for a manual action that can directly cause external payment movement, regardless of policy configuration;
  • actions not requiring dual approval are not forced through a universal second-approval workflow;
  • material Case outcomes and lifecycle changes are available to PH-09 and PH-13/Data Platform for durable history and reporting, with the publication mechanism left to Engineering/shared standards;
  • PH-13/Data Platform can consume Case status/history without becoming authoritative for Case state; and
  • PH-11 remains a lightweight payment-exception capability rather than growing into a general operational workflow platform.