Skip to content

PP-01 — Person-to-Person Payments

Payment Product · Working Draft · Revised v5 · Updated September 5, 2026

1. Objective

Provide DragonPay's initial person-to-person payment Product.

An authenticated credit-union member can authorize a domestic payment to another person identified by an approved contact method. The participating CU secures the payment amount using its own account/core infrastructure, the recipient later claims the payment, and the recipient selects an eligible receiving account.

The initial Product preserves the core business behavior demonstrated by the acquired RCUpay Sender and Receiver workflows:

  • CU-authenticated Sender with no separate DragonPay Sender login;
  • recipient identified by approved email/phone contact;
  • one Sender confirmation before funding;
  • CU-controlled funding before recipient invitation;
  • a separate recipient claim challenge;
  • configurable claim expiration and failed-challenge threshold;
  • recipient destination selection during claim;
  • same-CU payout through an ON_US route;
  • external domestic payout through ACH for the initial Product;
  • return of CU-controlled funds to the Sender when a funded payment terminates before successful payout; and
  • duplicate-safe handling of uncertain funding, payout, and corrective return outcomes.

DragonPay never holds, prefunds, reserves, or intermediates customer funds.

PP-01 owns P2P business behavior. Payment Hub capabilities own the shared payment, orchestration, policy, routing, execution, history, reconciliation, Case, communication, and reporting behavior used to deliver it.

2. Product boundaries and ownership

Capability Owner
Sender authentication and CU member context CU / CX-01 / PH-01
P2P business behavior PP-01
Canonical Payment Request / Action / Leg / Attempt / Provider Transaction PH-03
Durable workflow and waits PH-04
Party and Payment Instrument data PH-05
Policy/eligibility/limit decisioning PH-06
Route resolution PH-07
Payment execution and external evidence PH-08
CU-specific member/account/entitlement facts and execution mechanics CI-01
Durable payment/commercial history PH-09
Reconciliation PH-10
Human operational exception handling PH-11
Transactional communications/documents PH-12
Operational and reporting views PH-13
Sender/recipient channel experiences CX-01

PP-01 does not define CU-specific Symitar, PowerOn, GL, ACH-file, provider, API, or settlement mechanics.

3. Initial P2P Product behavior

Sender

The Sender:

  • enters P2P through the CU-authenticated digital-banking experience;
  • accepts the current required P2P Product disclosure;
  • selects an eligible CU source account;
  • identifies a recipient using an approved email or phone contact;
  • enters the payment amount and any permitted memo;
  • creates the Sender-provided shared-secret/security-word challenge;
  • sees any applicable fee, claim window, cancellation/return terms, and delivery expectations;
  • receives an explicit warning when Product logic identifies a likely recent duplicate; and
  • confirms the payment once before funding begins.

The semantic duplicate warning is a customer-safety feature. It is separate from technical command/idempotency protection and does not automatically prohibit a legitimate second payment.

Funding

After Sender confirmation:

  • applicable Product/account/policy checks must pass;
  • a distinct Funding Leg is executed using the CU's authorized infrastructure;
  • the CU remains responsible for the account and funds;
  • DragonPay records/orchestrates the movement but does not custody the funds; and
  • the recipient invitation is not sent until funding success is authoritative.

If funding is rejected or definitively fails before movement, the recipient is not invited.

If funding may have occurred but the outcome is uncertain, the payment remains unresolved and invitation is blocked until authoritative evidence establishes what happened.

Recipient claim

Once funding is authoritative:

  • the recipient receives an expiring claim invitation;
  • the invitation does not contain the Sender-provided security word;
  • the Sender provides the security word separately/out of band;
  • possession of the claim link alone is insufficient;
  • the recipient must satisfy the configured claim challenge;
  • the recipient accepts required recipient terms/disclosures; and
  • the recipient selects or establishes an eligible destination account.

The claim window and failed-challenge threshold are configurable by Product/Tenant configuration. The acquired CU behavior uses a 10-day claim window, but that value is not universal.

Recipient destination

The initial Product supports:

  • same-CU destination — eligible participating-CU account; Product requires an ON_US payout route;
  • external domestic FI destination — eligible domestic bank account; Product requires an ACH payout route.

Contact/challenge success is not sufficient evidence of destination-account eligibility or ownership. Destination validation is a separate gate.

A recipient contact being reused across payments does not by itself authorize reusing a destination Payment Instrument established during a prior claim; a destination may be reused only if the current claim independently establishes the recipient's authorization and eligibility for that destination.

Future Product versions may add other payout Route Types without changing the fundamental claim-based P2P behavior.

4. Payout and Product completion

After successful claim and destination validation:

  • applicable payout policy/eligibility checks must pass;
  • PP-01 supplies the required payout Route Type to PH-07;
  • PH-07 selects an eligible configured Route Capability/Connection;
  • PH-08 executes a distinct Recipient Payout Leg; and
  • PP-01 does not choose the Connector, provider, API, file, or CU-specific execution method.

Completion rule

P2P reaches COMPLETED only when the selected payout integration provides the authoritative successful outcome defined for that payout method.

For example:

  • an ON_US payout completes when the CU provides authoritative successful posting evidence;
  • an ACH payout completes when the CU/ACH execution integration provides the authoritative successful payout outcome defined for that integration.

Submission, technical acceptance, file delivery, or an intermediate processing acknowledgement alone is never sufficient to mean the Product is complete.

A later ACH/provider return is a subsequent return/correction lifecycle. It does not retroactively mean the original payout was never completed.

When an authoritative post-payout return or correction is received, PP-01 requires the payment to reflect the returned outcome, the Sender and recipient to be notified as applicable, and the CU-authorized disposition of the returned funds to be coordinated through PH-04/PH-08. DragonPay does not originate or custody the returned funds, and a duplicate return is not processed twice.

If payout may have occurred but the result is uncertain, PP-01 does not complete the payment, return the Sender's funding, or submit another payout until authoritative evidence makes the next action safe.

5. Claim failure, expiration, cancellation, and corrective return

A funded payment may terminate before successful recipient payout because of conditions such as:

  • recipient decline;
  • the recipient contact's configured opt-out/block state prevents invitation delivery;
  • claim expiration;
  • configured failed-challenge threshold;
  • eligible Sender cancellation;
  • destination cannot be established within the permitted claim flow;
  • payout policy/eligibility rejection; or
  • another supported terminal pre-payout Product condition.

When this occurs after funding has succeeded:

  • the payment is not simply closed;
  • PH-04 coordinates a separate corrective Return-to-Sender Action/Leg;
  • the return uses the CU's authorized execution path;
  • DragonPay does not originate or custody the returned funds; and
  • customer-facing closure is not represented as complete until the required return outcome is authoritative.

The original Product reason remains distinct from the corrective movement. For example, EXPIRED remains the customer/business reason even though a separate Return-to-Sender movement is required to resolve the funded amount.

If corrective return outcome becomes uncertain, the same unknown-outcome protections apply as for funding or payout.

A terminated claim does not simply reopen. A new recipient attempt requires a newly initiated P2P with a new challenge once the earlier payment is safely resolved.

6. Unknown outcomes and duplicate-movement safety

Funding, payout, and corrective return are separate money movements and each must be protected independently.

If any movement may have been externally handed off but its outcome cannot be established:

  • that movement remains unresolved;
  • timeout alone is not proof of failure;
  • PP-01 does not authorize a conflicting second movement;
  • PH-08 may perform safe inquiry;
  • PH-10 may reconcile later authoritative evidence; and
  • PH-11 may be used when human investigation is required.

In particular:

  • an unknown Funding Leg blocks recipient invitation;
  • an unknown Payout Leg blocks both duplicate payout and a conflicting Return-to-Sender;
  • an unknown corrective Return blocks another return based only on timeout.

PP-01 does not define technical retry algorithms. It defines the Product constraint that ambiguous movement cannot be treated as known failure.

7. Product configuration

The initial P2P Product must support Tenant/Product configuration sufficient to vary the business behavior that may legitimately differ by participating CU.

This includes, where applicable:

  • eligible Sender/member/account classifications;
  • supported recipient contact types;
  • recipient contact opt-out/block behavior for invitation and reminder communications;
  • claim duration;
  • challenge method and failed-attempt threshold;
  • amount/velocity/eligibility policy inputs;
  • funding timing/strategy;
  • permitted cancellation behavior;
  • semantic duplicate-warning behavior;
  • reminder behavior, including configured reminder cadence while an eligible claim remains active;
  • fee presentation;
  • same-CU and external payout Route Types;
  • required communication purposes;
  • disclosure versions; and
  • other actual CU/Product settings required for launch.

The initial Product uses:

  • claim-required recipient behavior;
  • Sender shared-secret challenge;
  • funding at send;
  • ON_US payout for eligible same-CU destination; and
  • ACH payout for eligible external domestic FI destination.

Future configuration must be introduced only for real supported Product/CU variation, not as a generalized workflow/rules platform.

In-flight payments remain governed by the Product configuration under which they were accepted unless a later Product requirement explicitly defines safe migration.

8. Product-specific information

PP-01 may retain P2P-specific information that is not naturally owned by the shared Payment Hub domains.

Examples include:

  • recipient contact reference/type used for this payment;
  • claim identity and current claim condition;
  • protected reference/verifier for the Sender-provided challenge;
  • failed challenge attempts needed to enforce Product behavior;
  • recipient disclosure acceptance;
  • selected recipient destination reference;
  • Sender confirmation evidence;
  • P2P disclosure acceptance;
  • claim expiration;
  • Product-specific termination/reason information; and
  • other P2P-specific facts required to operate the claim flow.

PP-01 does not duplicate PH-03 payment/execution state, PH-05 Party/Instrument master data, PH-06 policy Decisions, PH-07 Route Decisions, PH-08 external execution evidence, PH-09 history, or CU account balances as authoritative.

Plaintext security words must not be exposed in ordinary records/logging.

The exact physical data model and entity split are Engineering decisions.

9. Sender confirmation and disclosures

Product disclosure

The CU-authenticated Sender must accept the currently required P2P Product disclosure before using the Product.

A new required disclosure version requires new acceptance.

Prior acceptance remains historically attributable.

Payment confirmation

Before funding, the Sender must receive a clear review of the material payment terms, including:

  • recipient contact/display;
  • source account display;
  • amount/currency;
  • applicable fee;
  • claim window;
  • shared-secret responsibility;
  • expected delivery behavior;
  • cancellation limitations; and
  • return behavior when the recipient cannot complete claim.

The Sender provides one explicit confirmation authorizing the payment before funding begins.

Because the recipient chooses the destination later, Sender confirmation does not need to bind the final recipient account, Route Decision, Connector, or provider.

Material payment terms cannot be silently changed after confirmation and then treated as though the Sender authorized them.

10. Communications

PP-01 defines when P2P communications are required and what business outcome they may represent.

Initial communication purposes include, as applicable:

  • recipient invitation after confirmed funding;
  • Sender confirmation/status;
  • recipient claim outcome;
  • payout processing/delay where needed;
  • completion;
  • claim failure/decline/expiration;
  • corrective return outcome; and
  • completed-payment receipt if required.

PP-01 must not communicate a money-movement result before that result is authoritative.

PP-01 invitation and reminder communications must respect configured recipient opt-out/block state for the recipient contact; opt-out/block does not suppress a required funding, payout, completion, or return status communication.

A configured reminder may be sent to the recipient while an eligible claim remains active.

Examples:

  • recipient invitation cannot precede authoritative funding;
  • payout completion cannot be communicated merely because an ACH file/API request was submitted;
  • Sender cannot be told that funds were returned merely because the claim expired; the corrective return must be authoritative;
  • the Sender-provided security word is never included in the DragonPay recipient invitation.

PH-12 owns delivery/template mechanics.

11. Reconciliation, exceptions, and reporting

Reconciliation

PH-10 reconciles the money movements that actually occurred for the implemented CU execution paths:

  • Funding;
  • Recipient Payout; and
  • corrective or post-payout Return when present.

PP-01 does not define a separate reconciliation platform.

Exceptions

PH-11 is used only when a P2P condition requires human operational investigation after normal automated handling cannot resolve it safely.

Potential examples include:

  • unresolved funding/payout/return outcome;
  • suspected duplicate movement;
  • reconciliation mismatch;
  • payment/reference integrity issue; or
  • corrective movement that cannot be safely established.

Normal claim decline, expiration, or challenge failure does not require a Case when the automated Product/return path completes correctly.

Reporting

PH-13 should allow operations/reporting to distinguish the material P2P stages and movements, including:

  • initiation/confirmation;
  • Funding Leg;
  • claim outcome/duration;
  • destination class;
  • Recipient Payout Leg;
  • corrective Return when present;
  • final Product outcome;
  • policy Decision/override outcome;
  • route/execution outcome;
  • reconciliation; and
  • operational exception/Case when present.

The exact reporting schema and metrics are owned by PH-13.

12. Product stories

PP01-01 — Initiate and Confirm a P2P Payment

Objective

Allow an authenticated CU member to create and authorize a claim-based P2P payment.

Required behavior

  • Use CU-authenticated Sender context without requiring a separate DragonPay Sender account.
  • Require current Product disclosure acceptance.
  • Present only eligible CU source accounts supplied by the CU integration.
  • Accept recipient email/phone contact, amount, permitted memo, and Sender-provided claim challenge.
  • Warn on a configured likely recent duplicate and require deliberate continuation when applicable.
  • Present material payment/claim/fee/cancellation/return terms.
  • Capture one Sender confirmation before funding.
  • Support eligible Sender cancellation before payout.

Acceptance

  • Another Sender/Tenant cannot use the member's account context.
  • A likely duplicate produces a warning rather than silently creating another payment or prohibiting a legitimate second send.
  • The Sender knows the recipient contact, amount, source account, fee, claim window, and challenge responsibility before confirming.
  • Material terms are not changed after confirmation without requiring appropriate new authorization.
  • Recipient destination is not required before Sender confirmation.

PP01-02 — Fund the Payment Before Invitation

Objective

Secure the Sender's payment through CU-controlled infrastructure before the recipient is invited.

Required behavior

  • Apply required Product/account/policy checks.
  • Execute a distinct Funding Leg through the CU-authorized route/integration.
  • Keep the funds under CU control; DragonPay records/orchestrates but does not custody them.
  • Block invitation until authoritative funding success.
  • End the send before claim when funding is definitively rejected/unsuccessful.
  • Preserve an unresolved state when funding may have occurred but the outcome is unknown.

Acceptance

  • Recipient invitation is never sent before authoritative funding.
  • DragonPay creates no customer-funds/prefunding/settlement balance.
  • Unknown funding does not trigger invitation or duplicate funding.
  • Funding and later payout remain separate logical movements.

PP01-03 — Invite and Authenticate the Recipient

Objective

Allow the intended recipient to claim an already-funded payment using the Product-defined challenge.

Required behavior

  • Send an expiring recipient invitation only after funding succeeds.
  • Do not include the Sender-provided security word in the invitation.
  • Require the recipient to provide the configured challenge.
  • Require applicable recipient disclosure acceptance.
  • Enforce the configured failed-challenge threshold.
  • Support recipient decline of the claim.
  • Make a terminated claim unusable.
  • Require a new P2P/new challenge for another attempt after claim termination.

Acceptance

  • Possession of the invitation alone is insufficient to claim.
  • Successful challenge permits destination setup.
  • Reaching the configured failed-attempt threshold terminates the claim.
  • Claim expiration follows Tenant/Product configuration rather than a universal hard-coded duration.
  • The plaintext challenge is not exposed in ordinary DragonPay records/logs.

PP01-04 — Select and Validate the Recipient Destination

Objective

Allow the authenticated recipient to choose an eligible receiving account.

Required behavior

  • Support an eligible account at the participating CU.
  • Support an eligible external domestic bank account.
  • Validate the destination through the applicable CU/integration/payment-instrument capabilities.
  • Keep destination eligibility/ownership separate from contact/challenge verification.
  • Permit correction of invalid destination information within the active claim flow when safe.

Acceptance

  • Invalid/unsupported destination cannot be paid.
  • Same-CU and external-FI destinations remain distinguishable.
  • Sensitive account information is protected.
  • Challenge success alone does not establish destination-account eligibility.

PP01-05 — Execute Recipient Payout and Complete P2P

Objective

Pay the claimed recipient through the Product-required payout route and complete P2P only from authoritative execution evidence.

Required behavior

  • Apply required recipient/destination policy/eligibility checks before payout.
  • Require ON_US for eligible same-CU destination.
  • Require ACH for eligible external domestic FI destination.
  • Execute a distinct Recipient Payout Leg through PH-07/PH-08.
  • Keep Connector/provider/file mechanics outside PP-01.
  • Reach Product COMPLETED only when the selected payout integration supplies the authoritative successful outcome defined for that payout method.
  • Consume an authoritative post-payout return/correction, reflect the returned outcome on the payment, and coordinate CU-authorized disposition of the returned funds through PH-04/PH-08, rather than only representing the return historically.

Acceptance

  • Submission, technical acceptance, file delivery, or an intermediate processing acknowledgement alone does not imply Product completion.
  • Authoritative successful ON_US or ACH payout can complete the P2P according to that integration's contract.
  • Duplicate payout is prevented.
  • A later ACH/provider return remains historically separate from the original completed payout, is reflected on the payment, and is not processed twice.
  • PP-01 contains no CU-specific Connector/GL/file implementation.

PP01-06 — Return Funded Amount When Pre-Payout Claim Cannot Complete

Objective

Safely return CU-controlled funding when a funded payment terminates before successful recipient payout.

Required behavior

  • Trigger corrective Return-to-Sender behavior for configured pre-payout termination conditions such as decline, expiration, challenge-threshold failure, eligible cancellation, undeliverable invitation due to recipient opt-out/block, or terminal payout rejection.
  • Preserve the original Product termination reason.
  • Execute the return as a separate corrective movement through CU-authorized infrastructure.
  • Do not represent final closure as complete until required return outcome is authoritative.
  • Apply unknown-outcome protection to the return.

Acceptance

  • A funded expired/declined/failed claim does not simply disappear or close without the required return movement.
  • DragonPay does not hold or independently return the funds.
  • Unknown return does not trigger a second blind return.
  • Original Funding/Payout history remains intact.

PP01-07 — Protect P2P Against Unknown and Conflicting Outcomes

Objective

Prevent ambiguous external execution from creating duplicate or conflicting money movement.

Required behavior

  • Treat possible external handoff as unresolved rather than known failure.
  • Block invitation while Funding is unknown.
  • Block duplicate payout and conflicting Return-to-Sender while Payout is unknown.
  • Block duplicate return while corrective Return is unknown.
  • Consume later authoritative inquiry/reconciliation evidence.
  • Escalate to PH-11 only when automated handling cannot resolve the condition safely.

Acceptance

  • Timeout alone never authorizes another movement.
  • An unresolved Payout cannot be treated as both failed and returned-to-Sender.
  • Later authoritative evidence updates the existing payment/execution history.
  • PH-11 remains exception-only rather than part of normal P2P flow.

PP01-08 — Provide P2P Communications, Operations, and Reporting

Objective

Make the P2P Product understandable to customers and supportable by DragonPay/CU operations.

Required behavior

  • Trigger Product-appropriate invitation, status, completion, failure/expiration, return, and receipt communications.
  • Never communicate completion/return before the corresponding movement outcome is authoritative.
  • Provide PH-10 with the context needed to reconcile actual P2P money movements.
  • Provide PH-11 with the payment/evidence references needed for true exceptions.
  • Provide PH-13 with the P2P-specific operational/reporting context required to distinguish Funding, claim, Payout, Return, and final outcome.
  • Avoid unnecessary PII in reporting/operational views.

Acceptance

  • Sender/recipient communications reflect authoritative Product state.
  • Operations can distinguish Funding, claim, Payout, corrective Return, unknown outcomes, reconciliation, and Case state.
  • Reporting does not collapse multiple P2P movements/Attempts into one misleading execution.
  • Communication/reporting failures cannot re-execute a payment movement.

13. Engineering-owned / intentionally non-prescribed detail

PP-01 intentionally does not prescribe:

  • physical P2PProductExtension, RecipientClaim, P2PSenderConfirmation, or disclosure-acceptance schemas;
  • a fixed PH-04 workflow-state enum (COMPLETED and EXPIRED above are Product outcome names, not this enum);
  • exact API/endpoint names;
  • exact backend call choreography;
  • exact microservice/module boundaries;
  • exact idempotency/request-fingerprint fields already governed by shared standards;
  • exact Party reuse/deduplication mechanics for reused email/phone contacts;
  • exact challenge-verifier storage mechanism;
  • exact rate-limit implementation for challenge attempts;
  • exact PH-06 rule structure or a mandatory numeric Risk Score;
  • exact CU entitlement/account-limit implementation;
  • exact funding/return core/GL mechanics;
  • exact ACH file or provider execution behavior;
  • a fixed ACH settlement/return waiting period before Product completion;
  • Connector/Connection health implementation;
  • PH-02 activation-evidence framework beyond valid Product configuration/readiness;
  • exact communication/template implementation;
  • reporting schemas/metric definitions;
  • the detailed sender/receiver backend sequence diagrams;
  • recurring/direct-recipient architecture; or
  • implementation/build sequence.

14. Scope boundaries

PP-01 owns

  • claim-required initial P2P business behavior;
  • Sender disclosure and pre-funding confirmation;
  • semantic duplicate warning;
  • funding-before-invitation Product requirement;
  • shared-secret claim behavior;
  • claim expiration/failure behavior;
  • recipient destination-selection semantics;
  • ON_US versus ACH payout Route Type requirement for the initial Product;
  • pre-payout corrective return requirement;
  • P2P completion/customer-status semantics; and
  • P2P-specific communication/operational/reporting meaning.

Out of scope for the initial Product

  • DragonPay wallet/stored value.
  • DragonPay custody, prefunding, reserves, settlement balances, or funds-in-transit balances.
  • DragonPay acting as ODFI, FedNow/RTP participant, settlement institution, or direct rail participant.
  • Direct-send trusted-recipient behavior without claim.
  • Universal recipient directory/network.
  • Recurring/scheduled P2P.
  • Request-for-payment/pull payments.
  • Card/cash/crypto funding.
  • Cross-border/multi-currency P2P.
  • Social/group/split-payment features.
  • Guaranteed cancellation/reversal after payout handoff.
  • CU-specific Symitar/PowerOn/GL/API/file behavior.
  • A P2P-owned routing, Connector, notification, reconciliation, Case, or reporting platform.

15. PP-01 completion criteria

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

  • an authenticated participating-CU member can initiate P2P without a separate DragonPay Sender login;
  • the Sender can accept required Product disclosure, select an eligible source account, identify a recipient by supported email/phone, enter amount/challenge, review material terms, and explicitly confirm;
  • configured likely duplicate behavior warns the Sender without replacing technical idempotency or automatically blocking a legitimate second payment;
  • a distinct CU-controlled Funding Leg succeeds authoritatively before any recipient invitation is sent;
  • DragonPay never holds/custodies the funded amount or creates customer-funds, prefunding, reserve, settlement, or funds-in-transit balances;
  • the recipient receives an expiring claim link while the Sender communicates the security word separately;
  • possession of the link alone is insufficient for claim;
  • configured failed-challenge threshold, decline, expiration, or an undeliverable invitation due to recipient opt-out/block can terminate the claim;
  • the recipient can select/establish an eligible same-CU or external domestic receiving account;
  • same-CU payout requires ON_US and external domestic payout requires ACH for the initial Product;
  • Product completion occurs only from the authoritative successful outcome defined for the selected payout integration, never from submission/technical-acceptance/file-delivery/intermediate-acknowledgement alone;
  • a later ACH/provider return is represented as a subsequent return/correction lifecycle, is actually reflected on the payment and communicated as applicable, and does not retroactively invalidate the original completed payout;
  • funded pre-payout termination coordinates a separate CU-controlled Return-to-Sender movement and does not report closure until required return evidence is authoritative;
  • Funding, Payout, and Return independently obey unknown-outcome/duplicate-movement safety;
  • PH-10 can reconcile the executed P2P movements using the authoritative evidence actually available;
  • unresolved material exceptions can create/update PH-11 Cases while normal claim failure/expiration remains automated;
  • PH-12 communications do not claim funding/payout/return outcomes before they are authoritative, and invitation/reminder communications respect configured recipient opt-out/block state without suppressing required transactional communications;
  • PH-13 can distinguish and report Sender confirmation, Funding, claim, destination class, Payout, Return, policy/reconciliation/Case outcome, and final Product result without unnecessary PII; and
  • future Product versions can add alternate claim methods, trusted/direct recipient behavior, other payout Route Types, or recurrence without replacing the shared PH-03 payment hierarchy or core claim-based Product contract.