CX-01 — P2P Channel Experience and Web SDK¶

Channel Experience · Working Draft · Revised v3 · Updated August 21, 2026

1. Objective¶

Provide the reusable customer-facing channel layer for PP-01 P2P using two deliberate delivery models: a DragonPay JavaScript/Web SDK mounted directly inside the authenticated credit-union digital-banking page for the Sender, and a DragonPay-hosted, CU-white-labeled web experience for the external Recipient.

The Sender integration follows the same general pattern used by modern payment-capture SDKs: the CU loads a versioned DragonPay SDK, initializes it with a short-lived authenticated launch credential, and mounts the P2P experience into a CU-controlled page container. The initial Sender implementation does not use an iframe and does not redirect the member to a separate DragonPay application.

CX-01 owns SDK lifecycle, presentation, channel/session integration, safe browser behavior and the hosted Recipient experience. PP-01 and Payment Hub services remain authoritative for Product workflow, eligibility, Funding, Claim, Payout, Return, notifications, receipts and payment state.

2. Delivery architecture¶

Initial channel model

CU Digital Banking Page │ ├─ loads DragonPay P2P Web SDK ├─ supplies short-lived launch token └─ mounts SDK into CU page container │ ▼ DragonPay Channel API │ ▼ PP-01 / Payment Hub Recipient SMS / Email Invitation │ ▼ DragonPay-hosted CU-white-labeled Claim Experience │ ▼ DragonPay Channel API → PP-01 / Payment Hub

The SDK and hosted Recipient experience share Product-facing APIs, presentation rules and normalized state semantics where appropriate, but they are separate browser applications with different trust contexts.

Sender delivery: DragonPay P2P Web SDK¶

Runs directly in the CU digital-banking page and renders into a CU-selected DOM container.
No iframe is used for the initial Sender implementation.
The CU owns the surrounding page, navigation and authenticated member session; DragonPay owns the P2P controls and interaction rendered inside the mounted SDK region.
The SDK communicates only with approved DragonPay Channel APIs. It never calls the CU core, MuleSoft, Symitar, a Connector, processor or payment network directly.
CU-specific differences are handled through launch context, versioned Tenant experience configuration and small host adapters rather than source-code forks.

Recipient delivery: DragonPay-hosted white-label experience¶

Recipient follows the invitation link to a DragonPay-hosted secure claim experience branded for the Sender CU.
Recipient does not need the Sender CU digital-banking application or a DragonPay consumer account.
DragonPay controls the claim-session security boundary, security-word entry, terms, destination selection and payout-status presentation.
The initial hosted experience supports same-CU destination selection and secure external-FI account enrollment as required by PP-01/CI-01.

Experience	Initial delivery	Owner boundary
Sender	JavaScript/Web SDK mounted directly in CU digital banking	CU owns authenticated host page; DragonPay owns mounted P2P experience and Channel API integration.
Recipient	DragonPay-hosted CU-white-labeled web claim experience	DragonPay hosts the claim application; Tenant configuration controls approved branding/content/support.
CU-built UI	Future optional use of Channel APIs	Not required for initial MVP; same Product/Channel contracts should allow it later.

3. Sender Web SDK contract¶

SDK distribution and lifecycle¶

Distribute the SDK as a versioned JavaScript package and/or approved CDN module. The exact distribution method may evolve without changing the public integration contract.
The CU explicitly initializes the SDK, provides the launch token and target container, then mounts the experience.
The SDK modifies only its owned mounted subtree and approved document-level accessibility/session hooks. It must not inject uncontrolled global styles or modify unrelated CU page content.
Styles and component identifiers are namespaced or otherwise scoped to prevent collisions with CU application CSS and JavaScript.
One active P2P Sender experience per authenticated page is sufficient for the initial release.
The SDK exposes explicit teardown/destroy behavior so listeners, timers and sensitive in-memory state are removed when the CU navigates away.

Reference integration shape¶

import { createP2P } from '@dragonpay/p2p'; const p2p = createP2P({ launchToken, container: '#dragonpay-p2p', onEvent: handleDragonPayEvent }); await p2p.mount(); // later p2p.destroy();

The exact package name and method names are implementation decisions. The requirement is the integration model: initialize, mount into a CU element, receive controlled events, and destroy cleanly.

SDK events and host callbacks¶

SDK event	Purpose
READY	SDK has initialized the Channel Session and rendered the initial P2P experience.
FLOW_COMPLETE	Current member interaction is complete; does not imply financial completion unless the supplied Product status is final.
SESSION_EXPIRED	DragonPay Channel Session expired and the CU may obtain a new launch token if its own member session remains valid.
PAYMENT_STATUS_CHANGED	Optional normalized status signal for host navigation/badging; contains no sensitive account/contact data.
RECEIPT_AVAILABLE	A receipt is now available through the SDK experience.
CLOSE_REQUESTED	Member requests to leave the mounted P2P experience.
SUPPORT_REQUESTED	Member invokes configured support behavior.
ERROR	Safe integration/application error with correlation/support reference.

Events are convenience signals, not authoritative payment data. The SDK continues to retrieve current Product state from DragonPay after timeout, refresh or uncertain writes.

Optional CU host capabilities¶

A versioned contact-picker adapter may allow the CU page to return one member-selected name/email/phone value to the SDK.
CU navigation callbacks may close the SDK or return the member to Transfers/Payments without exposing payment secrets.
Future host capabilities must be explicitly versioned and permissioned; the SDK must not scrape or directly inspect arbitrary CU application state.

4. Authenticated Sender launch and Channel Session¶

The CU authenticates the Sender. The CU server or approved digital-banking integration obtains or creates a short-lived DragonPay launch token. The browser receives only that limited credential; no long-lived DragonPay application secret is exposed to JavaScript.

Launch token must contain or securely reference:

Tenant ID and requested Product.
CU member/customer reference and authorized-user reference where applicable.
CU authentication/session reference, authentication time and assurance information when supplied.
CU channel/application identifier, locale/time zone and correlation ID.
Issuer/audience, nonce, issued time and expiration required for trust and replay protection. The SDK exchanges the token with the Channel API for a short-lived Channel Session. The Channel Session is scoped to the current Tenant, Product and authenticated member context, is revocable, and does not create a DragonPay consumer account.
Session expiration does not cancel or alter an existing Payment Request.
On SDK remount/relaunch, current authoritative payment state is retrieved rather than reconstructed from prior browser state.
Production and non-production use separate deployments/endpoints and credentials; environment is not a mutable payment attribute.

5. Sender P2P experience¶

The SDK implements the PP-01 claim-based Sender flow adopted from the production RCUpay behavior.

Sender launches P2P inside the CU page; SDK establishes Channel Session.

If required, Sender accepts the current P2P Product disclosure.

Sender selects an eligible CU source account.

Sender enters Recipient email or mobile number, amount, optional memo and Sender-provided security word.

PP-01 performs validation and may return a semantic duplicate-payment warning; SDK presents it and requires acknowledgement when continuation is allowed.

Sender reviews material terms and confirms once.

SDK displays Funding progress while PP-01/PH-04 executes the CU-controlled Funding Leg.

After authoritative Funding success, the Recipient invitation is sent and the Sender is instructed to provide the security word separately.

Sender can later view Claim, Payout, Return, cancellation, completion and receipt state.

Sender data-entry rules¶

Source accounts and eligibility come from authoritative Product/Hub APIs; the SDK does not calculate eligibility.
Recipient contact supports configured email/mobile types and optional one-contact CU picker.
Security word is treated as sensitive: masked by default, never written to telemetry/logs/persistent browser storage, and cleared from SDK memory/state after successful submission when practical.
Product minimum/maximum, fees, claim expiration and other constraints are rendered from effective Product configuration/review responses.
No known-recipient/direct-send flow is required for the initial MVP.

Review and confirmation¶

Review shows masked Recipient contact, source account, amount/currency, fee, claim period, security-word responsibility, funding/cancellation/return behavior and expected delivery behavior.
Review explicitly explains that Sender Confirmation authorizes the CU-controlled funding movement before the Recipient chooses a destination.
Confirmation references the current review version and is idempotent.
There is no normal Sender reconfirmation after Recipient claim in the initial Product.
If the confirmation write times out, the SDK retrieves current Product state before offering any repeat action.

Sender status presentation¶

Product condition	Sender presentation
Funding pending	Sending payment / securing funds. Do not resubmit.
Funding outcome unknown	Status is still being confirmed. Do not send again.
Awaiting claim	Payment funded; waiting for Recipient claim until configured expiration.
Claim failed/declined/expired	Payment cannot be claimed; funds are returning or have returned to the Sender.
Payout processing	Recipient claimed; payment is processing to the selected destination.
Completed	Payment completed; receipt available when PH-12 generates it.
Returning to Sender	Funds are being returned to the Sender.
Returned after completion	Payment was subsequently returned.

6. Recipient hosted white-label experience¶

The Recipient experience is a separate DragonPay-hosted application reached from the invitation. It is white-labeled using the Sender CU Tenant experience version and does not run inside the CU digital-banking page.

Claim entry and challenge¶

Claim reference is Tenant/payment/claim scoped, expiring, replay-controlled and rate-limited.
Claim page shows only approved Sender display, amount/currency, claim expiration, branding/support and required claim steps.
Recipient must enter the Sender-provided security word. Possession of the invitation link alone is insufficient.
Incorrect challenge attempts are tracked server-side. When the configured threshold is reached, the claim becomes terminal and PP-01 initiates the CU-controlled Return-to-Sender path when funding occurred.
A failed terminal claim cannot be reopened; Sender must initiate a new payment with a new challenge.

Terms and destination selection¶

Recipient explicitly accepts the current claim disclosure/terms version.
Recipient chooses an eligible same-CU account or external domestic financial-institution account when enabled by PP-01.
Same-CU destination uses the configured CI-01/CU account-resolution contract through DragonPay APIs.
External destination is entered directly by the Recipient — routing number, account number, account-holder name and account type — collected through the hosted Recipient UI. This direct-entry path is the required baseline for the initial Product; a provider-based account-verification or tokenization service may be added later as an additional entry option, not a replacement for it.
Full external account values are submitted over TLS to the secure Channel/API boundary and are never placed in URLs, analytics, application logs or persistent browser storage.
Recipient reviews masked destination information and expected timing before final claim submission.

Claim and payout state¶

Claim submission is idempotent.
CLAIMED means Recipient requirements are complete; it does not mean money has reached the destination.
Same-CU destination leads PP-01 to an ON_US payout requirement; external FI destination leads to ACH for the initial Product.
Hosted Recipient UI displays payout Processing, Outcome Unknown, Completed or Returned using normalized Product state and timing.
Recipient decline and claim expiration terminate that claim and trigger return behavior when funded.

7. Tenant branding and experience configuration¶

Use one versioned Tenant experience configuration for both Sender SDK presentation and Recipient hosted white-label presentation. This keeps branding and content consistent without giving a Tenant arbitrary code execution inside DragonPay.

Object	Purpose / initial fields
ChannelApplicationRegistration	Tenant, application code, approved CU origins, trusted launch issuer/audience references, supported SDK versions, session policy reference, production status and optional host capabilities.
TenantExperienceVersion	Tenant/Product scope, Product display name, logo/theme tokens, content/support references, locale settings, Recipient hosted-domain/branding references, receipt/history presentation flags, accessibility/content version and effective status/time.

The CU may control approved colors, logo, typography tokens, spacing and supported display/content options; arbitrary JavaScript and unrestricted CSS are prohibited.
PP-01/PH-02 remain authoritative for business configuration such as claim period, failed-challenge threshold, payment limits, contact methods, funding behavior and Product disclosures.
SDK may accept limited local appearance/layout options only when explicitly supported by the Tenant experience contract; local options cannot override Product rules or security content.

8. Channel API and state recovery¶

The Channel API provides browser-oriented contracts for the SDK and hosted Recipient experience. It may aggregate calls to PP-01 and Hub modules, but it does not own Product workflow or maintain a second payment database.

API group	Initial capabilities
SDK launch/session	Exchange launch token; retrieve Channel Context; refresh/end permitted session; validate SDK version/origin.
Configuration	Retrieve effective Tenant experience version, Product display settings, content/support references.
Sender	Retrieve landing/accounts; create draft; retrieve review; acknowledge duplicate warning; confirm; retrieve status/detail/history; request cancellation; retrieve receipt.
Claim	Validate claim; retrieve summary; submit security-word challenge; accept terms; establish/select destination; submit/decline claim; retrieve claim/payout status.
Testing	Deterministic mock member/payment/claim/execution scenarios in non-production only.

Write safety and recovery¶

Every material write uses a server-enforced idempotency key/context.
SDK disables duplicate UI activation for usability, but backend idempotency is authoritative.
After network/browser timeout on a write, the SDK or hosted claim app retrieves current authoritative state before offering another action.
Refresh/remount never automatically replays a prior write.
Only actions currently permitted by PP-01 are rendered.
Normalized user errors contain a safe message plus correlation/support reference; raw CU/provider/internal details remain hidden.

9. Security and browser boundary¶

The no-iframe Sender model intentionally treats the CU digital-banking origin as a trusted application boundary. Because DragonPay JavaScript executes in the same page, the SDK cannot use iframe isolation as a security boundary; instead the integration relies on approved CU origins, short-lived credentials, scoped rendering and supply-chain controls.

No long-lived DragonPay secret or service credential is delivered to the browser.
Approved CU origins are registered and enforced by Channel API CORS/session controls.
SDK does not use eval/dynamic code generation or load unapproved runtime scripts.
SDK release artifacts are versioned, reproducible and subject to dependency scanning, SBOM/release controls and integrity controls appropriate to the distribution method.
If CDN distribution is supported, provide an approved integrity/version-pinning mechanism where practical.
SDK avoids global namespaces/styles except its documented public entry point and scoped style resources.
Launch/session tokens use secure short-lived mechanisms and are not stored in localStorage; full account/contact/security-word values are never written to logs/analytics.
Sender security word is visible only within the trusted CU page/SDK interaction and is cleared from application state after use when practical.
Recipient hosted application applies CSP, CSRF, XSS, clickjacking, open-redirect, sensitive-cache and token protections appropriate to an internet-facing claim site.
STD-01 idempotency, timeout, correlation, observability and resilience standards apply to Channel API dependencies.

10. Accessibility, responsive behavior and localization¶

SDK must fit responsive CU page containers on supported desktop and mobile web layouts without an iframe resize protocol.
The mounted SDK must not break CU page keyboard order, focus behavior or accessibility landmarks.
Initial experience targets the approved WCAG AA baseline, including labels, keyboard use, focus, errors, status announcements, contrast, resizing, dialogs and timeout messaging.
Recipient hosted experience meets the same accessibility baseline.
Funding/Claim/Payout/Return state cannot rely on color alone.
Locale/time-zone presentation comes from Channel/Tenant configuration; initial Product may support one production locale while contracts remain localization-ready.

11. Telemetry and operational support¶

CX telemetry measures channel health and funnel behavior, not payment truth. PH-13/reporting remains authoritative for Product/payment reporting.

Privacy-safe events may include SDK load/init/mount, launch outcome, screen/step, action category, API outcome category, duplicate-warning acknowledgement, confirmation submitted, claim step, destination type, normalized status category, session expiration and performance timing.
Do not record full Recipient contact, security word, account/routing values, authentication/claim tokens, memo or restricted risk reasons.
Include SDK version, Tenant/application code, correlation ID and safe error category for supportability.
Telemetry failure never blocks payment activity.
Fatal integration or customer-support states display the configured CU/DragonPay support behavior and safe correlation reference.

12. Mock environment and first-CU integration kit¶

CX-01 must be buildable and testable before final CU infrastructure is available. Provide a deterministic developer kit that mimics both the SDK host and Recipient hosted journey.

Sample CU digital-banking page that loads the SDK, supplies a mock launch token and mounts/unmounts P2P.
Mock members plus eligible/ineligible source accounts and disclosure states.
Semantic duplicate warning and explicit continuation.
Funding success, definitive pre-handoff failure and OUTCOME_UNKNOWN.
Invitation delivery, correct/incorrect security word, terminal challenge threshold, decline and expiration.
Same-CU destination and external ACH destination enrollment/validation.
Payout success, processing, rejection, OUTCOME_UNKNOWN and Return-to-Sender.
Session expiration, network timeout, duplicate click, stale review and API error scenarios. Mock capabilities are unavailable in production.

CX-01A first-CU inputs¶

Digital-banking platform and supported method for loading a third-party/versioned DragonPay JavaScript SDK.
CU server-side launch-token/authentication integration and member-context mapping.
Approved digital-banking origins, CSP/CORS/package-loading constraints and production SDK distribution approach.
SDK mount location, surrounding navigation behavior, close/support callbacks and optional contact-picker integration.
Tenant theme, logo, content, legal/support assets and analytics adapter requirements.
Recipient white-label domain/branding/content and invitation-link behavior.
Same-CU destination enrollment/resolution experience and external-FI account-enrollment contract.
Test members/accounts/contacts, security review, accessibility acceptance, end-to-end certification, rollback and support procedures.

13. Data ownership and interfaces¶

Persistent CX-owned configuration is limited to ChannelApplicationRegistration and TenantExperienceVersion. Channel/Claim Sessions are runtime security constructs. Browser state is disposable and non-authoritative.

CX-01 does not persist copies of Payment Requests, Recipient Claims, Payment Instruments, Notifications, Documents, workflow state or reporting facts.

Owner	CX uses it for
PH-01	Trusted Sender/application authorization and access/audit requirements.
PP-01 / PH-04	P2P review, Funding/Claim/Payout/Return workflow, state and action eligibility.
PH-05	Party/Payment Instrument references and approved masked display/validation facts.
PH-06	Eligibility/risk outcomes presented only through normalized Product messages.
PH-12	Invitation/notification status and receipt/document retrieval.
PH-13	Authorized Sender history/read views where Product exposes them; reporting data is not rebuilt in CX.
CX-01	SDK integration contract, runtime channel/claim sessions, presentation configuration and customer interaction behavior.

14. Implementation stories¶

CX01-01 — Build DragonPay P2P Web SDK¶

Objective: Provide a reusable Sender SDK that a CU can mount directly inside its authenticated digital-banking page.

Build: Create the versioned JavaScript package/module, public initialization/mount/destroy contract, scoped component shell and Channel API client.

Acceptance:

No iframe or Sender redirect is required.
SDK renders only inside its assigned container and does not pollute unrelated CU UI.
SDK version is observable and compatibility-tested.
Direct CU core/middleware/Connector calls are impossible from the SDK.

CX01-02 — Launch authenticated Sender session¶

Objective: Allow a CU-authenticated member to initialize the SDK without a DragonPay consumer login.

Build: Implement short-lived launch token exchange, issuer/audience/nonce/replay checks and Channel Session establishment.

Acceptance:

No long-lived credential reaches the browser.
Tenant/member/Product scope is enforced.
Invalid or replayed launch fails safely.
Session expiration does not alter existing payments.

CX01-03 — Integrate SDK with CU host page¶

Objective: Give the CU a small, stable integration contract around the mounted P2P experience.

Build: Implement SDK events/callbacks, close/support/navigation hooks and optional one-contact picker adapter.

Acceptance:

Events are versioned and exclude sensitive data.
Optional host adapters cannot change payment rules.
Destroy/unmount cleans listeners and sensitive runtime state.
CU-specific behavior does not require a CX source-code fork.

CX01-04 — Apply Tenant experience version¶

Objective: Present CU branding/content consistently in both Sender SDK and Recipient hosted experience.

Build: Implement ChannelApplicationRegistration/TenantExperienceVersion retrieval, validated theme tokens, content/support references and locale behavior.

Acceptance:

Active version is observable.
Missing required configuration blocks safely.
Arbitrary Tenant JavaScript/unrestricted CSS is rejected.
Business configuration remains PP-01/PH-02 owned.

CX01-05 — Collect Sender payment details¶

Objective: Allow the Sender to enter the initial claim-based P2P payment inside the SDK.

Build: Build Product disclosure gate, source account selector, Recipient email/mobile input, amount/memo and sensitive security-word control.

Acceptance:

Only eligible server-returned accounts are selectable.
Contact/account values are masked appropriately.
Security word is absent from logs/analytics/persistent storage.
Known-recipient direct-send is not required initially.

CX01-06 — Review duplicate warning and confirm once¶

Objective: Present mature pre-send controls before CU funding begins.

Build: Render server review including fee, claim period, funding/cancellation/return language and semantic duplicate warning; submit Sender Confirmation.

Acceptance:

Review version is current.
Duplicate warning acknowledgement is explicit when required.
Confirmation is idempotent.
No normal Sender reconfirmation occurs after claim.
Timeout retrieves current state instead of resubmitting.

CX01-07 — Display Funding and invitation lifecycle¶

Objective: Make Sender Confirmation, Funding and Recipient invitation visibly distinct.

Build: Implement Funding pending/success/unknown/failure states and post-funding invitation/claim-expiration detail.

Acceptance:

Invitation is never shown as sent before authoritative Funding success.
OUTCOME_UNKNOWN warns against sending again.
Sender is instructed to communicate the security word separately.
Return state is shown if the funded payment cannot proceed.

CX01-08 — Build hosted white-label Recipient claim¶

Objective: Provide the secure external Recipient experience independently of the CU digital-banking application.

Build: Build DragonPay-hosted Tenant-branded claim site, claim-session controls, permitted summary and security-word challenge.

Acceptance:

Recipient claim is not embedded in the CU page.
Claim link alone is insufficient.
Expired/cancelled/consumed claims fail safely.
Terminal challenge failure makes claim unusable and supports Return-to-Sender.

CX01-09 — Capture Recipient terms and destination¶

Objective: Allow Recipient to choose and validate an eligible payout destination.

Build: Implement claim terms, same-CU account resolution and secure external routing/account/name/account-type enrollment with masked review.

Acceptance:

Sensitive external account values are excluded from URLs/logs/telemetry/persistent browser storage.
Destination is server validated.
Same-CU and external-FI paths share the PP-01 claim contract.
External linking provider can replace direct entry later without Product redesign.

CX01-10 — Complete claim and display payout/return¶

Objective: Show claim completion separately from actual movement to the Recipient.

Build: Submit idempotent claim and render normalized ON_US/ACH payout processing, completion, unknown and return states.

Acceptance:

CLAIMED never means COMPLETED.
Payout timing comes from Product state.
Unsafe retry is never offered.
Decline/expiration/terminal challenge state is terminal for that claim.

CX01-11 — Provide Sender history, cancellation and receipt¶

Objective: Allow the authenticated Sender to manage/view permitted in-flight and prior P2P activity in the SDK.

Build: Build scoped history/detail, current cancellation eligibility and PH-12 receipt retrieval.

Acceptance:

Only authenticated member activity is returned.
Funding/Claim/Payout/Return are distinguishable.
Operational-only evidence is excluded.
Receipt is not reconstructed client-side.

CX01-12 — Recover safely from browser interruption¶

Objective: Prevent SDK or hosted-claim browser failures from duplicating financial actions.

Build: Implement normalized errors, authoritative state refresh after writes/timeouts, idempotency context and stale-action suppression.

Acceptance:

No write is replayed automatically after timeout/remount.
Only currently eligible actions are shown.
Correlation/support reference is available.
Raw internal errors remain hidden.

CX01-13 — Secure SDK distribution and browser execution¶

Objective: Ship third-party JavaScript suitable for use inside a regulated CU digital-banking page.

Build: Implement approved origin/CORS controls, short-lived session handling, scoped CSS/DOM behavior, dependency/release scanning, SBOM and package/CDN integrity/version controls.

Acceptance:

No long-lived secret is exposed.
No iframe security model is assumed.
SDK does not load unapproved runtime code.
Sensitive values are absent from persistent browser storage/logs/telemetry.
Cross-Tenant/origin tests fail.

CX01-14 — Meet accessibility, responsive and telemetry baseline¶

Objective: Make both Sender SDK and Recipient hosted flow production-usable across supported web experiences.

Build: Implement responsive components, accessibility behavior and privacy-safe telemetry/performance measurement.

Acceptance:

Mounted SDK does not break host keyboard/focus flow.
Approved accessibility tests pass.
Sender and Recipient status/errors are accessible.
Telemetry failure does not block payments.

CX01-15 — Provide SDK developer kit and first-CU package¶

Objective: Enable parallel development and repeatable CU integration.

Build: Provide sample CU host page, deterministic mock scenarios, SDK/API contract tests, integration guide and CX-01A checklist.

Acceptance:

Sample demonstrates install/init/mount/events/destroy.
Funding/Claim/Payout/Return scenarios are deterministic.
Mock mode cannot run in production.
First CU can integrate without changing reusable Product behavior.

15. Initial implementation sequence¶

Define SDK public contract, Channel API contract, sample CU host page and mock PP-01 responses.
Implement launch-token exchange, Channel Session and SDK mount/destroy lifecycle.
Implement Tenant experience configuration plus SDK component styling/accessibility foundation.
Build Sender disclosure/account/contact/amount/security-word entry, duplicate warning and single Confirmation.
Add Funding, invitation, status recovery, history and cancellation behavior.
Build hosted Recipient claim application with challenge/terms/destination enrollment.
Add Payout/Return/decline/expiration/receipt status experiences.
Complete SDK supply-chain/browser hardening, telemetry, deterministic scenarios, contract tests and CX-01A production integration package.

16. Scope boundaries and growth path¶

Initial CX-01 deliberately optimizes for a low-friction CU integration: mount the DragonPay Sender SDK inside digital banking and send external Recipients to a secure CU-branded DragonPay claim site.

Not required initially:

Iframe-based Sender experience.
DragonPay-hosted/redirected Sender application.
Known-recipient direct-send or universal Recipient directory.
Recurring/scheduled UI, payment requests, split/group/social payments or chat.
Native iOS/Android SDKs.
Named digital-banking-vendor code inside the reusable SDK core.
A general CMS, customer preference center or arbitrary Tenant design system.
A second Product/workflow implementation in the browser.
Direct CU core/middleware/payment-network access from browser JavaScript. Future Channel APIs may support CU-built interfaces, native wrappers, additional Products, known recipients, recurring payments, richer localization and alternate Recipient account-linking providers without changing PP-01 or the canonical payment model.

17. Completion criteria¶

A versioned DragonPay P2P Web SDK can be loaded and mounted directly inside an authenticated CU digital-banking page with no iframe.
CU can initialize the SDK using a short-lived launch token without exposing long-lived DragonPay credentials.
SDK is scoped to its assigned container, has documented lifecycle/events and cleans up safely on destroy.
Sender can accept Product disclosure, select eligible source account, enter Recipient email/mobile, amount and security word, review semantic duplicate warning and confirm once.
Funding pending/success/unknown/failure is distinct from invitation and final completion.
Recipient invitation is represented only after authoritative Funding success.
External Recipient uses a DragonPay-hosted CU-white-labeled claim experience, not the CU SDK.
Recipient can enter security word, accept terms, choose same-CU or external FI destination, review masked details and submit claim.
Configured terminal challenge failure, decline and expiration make the claim unusable and support Return-to-Sender.
CLAIMED, Payout Processing, OUTCOME_UNKNOWN, Completed and Returned are distinct authoritative states.
Sender can view permitted history/detail, cancellation and PH-12 receipt through the SDK.
Browser timeout/remount/double-click does not duplicate Payment Requests, Funding, Invitations, Claims, Payouts or Returns.
SDK origin/CORS, session, supply-chain, sensitive-data, accessibility and cross-Tenant tests pass production requirements.
Tenant branding/content applies consistently to Sender SDK and Recipient hosted experience without source-code forks.
Deterministic developer kit demonstrates SDK integration and the full Funding → Claim → Payout / Return lifecycle.
CX-01A can integrate the first CU without changing the reusable SDK or PP-01 behavior.
CX-01 remains an experience/integration layer and does not become authoritative for Product workflow, payment state, funds movement, notifications/documents or reporting facts.