FPSF-CPD-001 — Payment Definition (CPD-001)

Metadata

Field	Value
Document ID	FPSF-CPD-001
Title	Canonical Payment Definition — Conceptual Baseline (CPD-001)
Version	1.1.0
Status	Draft
Date	2026-06-15
Conformance	Self-contained
Author(s)	Adalton Reis ([email protected])
Reviewers	—
Organization	Fabric Payment Standards Foundation
Contact	[email protected]
License	Apache License 2.0

Abstract

This document defines a minimal, neutral, and implementation-agnostic conceptual model of a Payment and a Digital Payment, including their essential properties, lifecycle, and interaction interfaces.

The purpose of this specification is not to introduce new payment mechanisms, nor to regulate existing systems, but to formalize the shared abstraction already present across global payment practices. By making implicit structures explicit, this specification establishes a common language and reference model that can be adopted by institutions, networks, and systems without altering their internal operations.

This document serves as a foundational layer upon which further specifications, interoperability models, and reference implementations may be developed. Specifically, FPSF-CPD-002 defines the Canonical Payment Request, a payer-agnostic structure from which a Payment conforming to this specification may be derived.

1. Scope

This specification:

Defines the concept of a Payment independent of medium, infrastructure, or jurisdiction
Defines a Digital Payment as a specialization of Payment
Establishes a minimal set of entities, properties, and lifecycle states
Describes interfaces that reflect de facto operational patterns observed in existing systems
Defines the derivation relationship between a Canonical Payment Request (CPD-002) and a Payment

This specification does not:

Define settlement mechanisms
Define regulatory or compliance requirements
Mandate specific technologies or cryptographic methods
Replace existing financial standards or network rules
Define the structure of a Payment Request (see FPSF-CPD-002)

2. Definitions

2.1 Payment

A Payment is:

A structured act by which a payer causes the transfer of value to a payee, resulting in a change of entitlement recognized by one or more systems of record.

Key characteristics:

Involves at least two parties: payer and payee
Expresses value (amount and asset)
Produces a state transition (before → after ownership/entitlement)
Is recognized by a system capable of recording or validating the change

2.2 Digital Payment

A Digital Payment is:

A Payment in which the expression of intent, authorization, transmission, and confirmation are performed through digital representations and processed by computational systems.

Additional characteristics:

Uses digital identifiers for participants
Uses machine-verifiable authorization (e.g., signatures, credentials)
Is processed through electronic communication channels
Produces machine-readable state transitions

2.3 Payment Request

A Payment Request is:

A structured, payer-agnostic expression of a payee's intent to receive value, from which a Payment may be derived by a paying application.

A Payment Request is not a Payment. It carries no payer information, no authorization, and no state. The full definition of the Canonical Payment Request is provided in FPSF-CPD-002.

3. Core Entities

3.1 Participant

An entity capable of initiating or receiving a Payment.

Participant {
    id: Identifier
    roles: Set<Role>  // e.g., payer, payee, intermediary
}

3.2 Value

The economic unit being transferred.

Value {
    amount: Numeric
    asset: AssetType   // e.g., currency, tokenized value
}

3.3 Payment Object

The canonical representation of a Payment.

Payment {
    id: PaymentIdentifier

    payer: Participant
    payee: Participant

    value: Value

    intent: IntentDescriptor
    authorization: AuthorizationProof

    state: PaymentState

    context: ExecutionContext (optional)
    derived_from: PaymentRequestReference (optional)  // See Section 3.7
}

3.4 Intent Descriptor

Describes the purpose and conditions of the Payment.

IntentDescriptor {
    reference: String (optional)
    conditions: Set<Condition> (optional)
}

3.5 Authorization Proof

Evidence that the payer has approved the Payment.

AuthorizationProof {
    method: AuthorizationMethod
    data: Opaque
}

Examples (non-exhaustive):

cryptographic signature
multi-party approval
institutional authorization

3.6 Execution Context (Optional)

Describes the environment in which the Payment is processed.

ExecutionContext {
    network: Identifier (optional)
    rail: Identifier (optional)
    settlementModel: SettlementType (optional)
}

3.7 Payment Request Reference (Optional)

When a Payment is derived from a Canonical Payment Request (CPD-002), this optional field records the origin.

PaymentRequestReference {
    request_id: Identifier      // The request_id from the originating CPR
    cpr_version: String         // The cpr_version from the originating CPR
}

This field is informational. Its presence or absence does not affect the validity of the Payment. It enables auditability and traceability when payments originate from CPD-002 requests.

4. Payment Lifecycle

A Payment progresses through a finite set of states:

enum PaymentState {
    CREATED        // Payment object instantiated
    AUTHORIZED     // Payer approval established
    IN_FLIGHT      // Submitted to processing system
    SETTLED        // Value transfer finalized
    FAILED         // Irrecoverable failure
    CANCELLED      // Explicitly revoked before settlement
}

State Transition Constraints

CREATED → AUTHORIZED
AUTHORIZED → IN_FLIGHT
IN_FLIGHT → SETTLED | FAILED
AUTHORIZED → CANCELLED

Transitions are:

monotonic (no reversal of state)
externally observable (must be queryable)

5. Interfaces (Conceptual)

The following interfaces represent de facto operations common across payment systems.

They are expressed abstractly and do not prescribe transport or protocol.

5.1 Payment Initiation Interface

initiatePayment(input: PaymentDraft) -> Payment

Constructs a Payment object
Assigns identifier
Sets initial state: CREATED

5.2 Authorization Interface

authorizePayment(paymentId, authorizationProof) -> Payment

Attaches authorization proof
Transitions state to AUTHORIZED

5.3 Submission Interface

submitPayment(paymentId, context) -> Payment

Submits Payment to execution environment
Transitions state to IN_FLIGHT

5.4 Settlement Interface

settlePayment(paymentId) -> Payment

Finalizes value transfer
Transitions state to SETTLED

5.5 Status Query Interface

getPaymentStatus(paymentId) -> PaymentState

Returns current state
Must be consistent with system of record

5.6 Cancellation Interface

cancelPayment(paymentId) -> Payment

Valid only before settlement
Transitions to CANCELLED

5.7 Derivation Interface

When a Payment is derived from a Canonical Payment Request (CPD-002), this interface is used to produce the initial Payment object.

derivePayment(request: CanonicalPaymentRequest, context: DerivationContext) -> Payment

Reads the CPR for payee, value, and intent information
Binds payer and authorization from DerivationContext — neither is present in the CPR
Selects the appropriate execution context (rail, network)
Constructs and returns a Payment in state CREATED
The resulting Payment MAY carry a PaymentRequestReference (Section 3.7) for traceability

The complete derivation procedure is defined in FPSF-CPD-002, Section 6.

6. Invariants

All compliant implementations must ensure:

Uniqueness
- Each Payment has a globally or contextually unique identifier
Integrity
- Payment data cannot be altered after authorization without invalidating the Payment
Authorization Binding
- AuthorizationProof must be cryptographically or institutionally bound to:
  - payer
  - value
  - payee
Deterministic State
- At any moment, a Payment has exactly one state
Finality
- SETTLED, FAILED, and CANCELLED are terminal states
Request Separation
- A Payment derived from a CPD-002 request MUST NOT copy payer information from any field of the request; all payer data is supplied exclusively at derivation time by the paying application

7. Non-Goals

This specification intentionally avoids:

Defining identity standards
Defining compliance mechanisms (AML, KYC)
Defining liquidity or credit models
Defining consensus or validation mechanisms
Defining messaging formats (e.g., XML, JSON schemas)
Defining the structure or delivery of Payment Requests (see FPSF-CPD-002)

8. Extensibility

This specification is designed to be extended through:

Additional states (e.g., "reversed", "refunded")
Richer intent descriptors
Advanced authorization schemes (e.g., threshold cryptography)
Interoperability layers between heterogeneous systems
Domain-specific Payment Request sub-interfaces (defined in FPSF-CPD-002)

9. Relationship to FPSF-CPD-002

FPSF-CPD-002 (Canonical Payment Request Definition) is the companion specification to this document. The two relate as follows:

Concept	CPD-001	CPD-002
Defines	Payment	Payment Request
Contains payer information	Yes	Never
Contains authorization	Yes	Never
Has state	Yes	No
Rail-specific	Via ExecutionContext	Via sub-interfaces
Derivation role	Output	Input

A Payment Request (CPD-002) is transformed into a Payment (CPD-001) through the derivation process defined in CPD-002 Section 6 and referenced in Section 5.7 of this document. Implementations supporting CPD-002 SHOULD implement the derivePayment interface.

10. Conformance

An implementation is considered CPD-001-compliant if:

It represents Payments according to the defined model
It enforces lifecycle constraints
It exposes equivalent operational interfaces
It preserves the invariants defined in Section 6

An implementation that additionally supports CPD-002 SHOULD implement the derivePayment interface and SHOULD populate derived_from when a Payment originates from a CPR.

Change Log

Version	Date	Summary
1.0.0	2026-03-25	Initial release. Canonical Payment and Digital Payment definitions, lifecycle, interfaces, invariants.
1.1.0	2026-06-15	Added Section 2.3 (Payment Request definition), Section 3.7 (PaymentRequestReference), Section 5.7 (Derivation Interface), Section 9 (Relationship to CPD-002), updated Scope and Conformance sections. Backward-compatible with v1.0.0.

Closing Note

This specification does not attempt to unify payment systems.

It establishes a shared descriptive foundation — a stable anchor — upon which diverse systems may align without relinquishing their internal models, governance, or regulatory obligations.

Its value lies in clarity, minimality, and universality.

Metadata​

Abstract​

1. Scope​

2. Definitions​

2.1 Payment​

Key characteristics:​

2.2 Digital Payment​

Additional characteristics:​

2.3 Payment Request​

3. Core Entities​

3.1 Participant​

3.2 Value​

3.3 Payment Object​

3.4 Intent Descriptor​

3.5 Authorization Proof​

3.6 Execution Context (Optional)​

3.7 Payment Request Reference (Optional)​

4. Payment Lifecycle​

State Transition Constraints​

5. Interfaces (Conceptual)​

5.1 Payment Initiation Interface​

5.2 Authorization Interface​

5.3 Submission Interface​

5.4 Settlement Interface​

5.5 Status Query Interface​

5.6 Cancellation Interface​

5.7 Derivation Interface​

6. Invariants​

7. Non-Goals​

8. Extensibility​

9. Relationship to FPSF-CPD-002​

10. Conformance​

Change Log​

Closing Note​