Enterprise / Payment Infrastructure

Infrastructure that connects payment operations.

First Digital Pay is designed to provide a structured payment layer between an organization's commercial systems, payment workflows and settlement operations.

One operating model connects payment activity, organizational controls, settlement and reconciliation.

Availability varies by product, jurisdiction, configuration and eligibility.

  1. 01OrganizationCommercial environment
  2. 02Business SystemsApplications and workflows
  3. 03FDP Integration LayerConnection into FDP
  4. 04Payment & ProcessingFDP payment records and processing
  5. 05SettlementApplicable settlement path
  6. 06Business RecordsSettlement and reconciliation

Conceptual architecture

Payments should not exist in isolation.

Payment infrastructure should connect the commercial reason for a payment with its processing, settlement and reconciliation records, so each stage can be traced back to the one before it.

  1. 01 · INVCommercial reference
  2. 02 · PAYPayment
  3. 03 · PRCProcessing
  4. 04 · STLSettlement
  5. 05 · RECReconciliation

Illustrative example. Reference prefixes are working conventions, not final technical identifiers.

A structured layer between commerce and settlement.

  1. 01

    Commercial Layer

    Where the organization's business activity creates the need for payment.

  2. 02

    Integration Layer

    How eligible payment activity can connect with FDP.

  3. 03

    Payment & Processing Layer

    Where payment records and applicable processing activity are managed.

  4. 04

    Settlement Layer

    Where eligible processed activity connects to the applicable settlement arrangement.

  5. 05

    Record Layer

    Where payment, processing, settlement and reconciliation relationships remain visible.

Each layer hands activity to the next. Together they form one path from commercial activity to business records.

Organizational controls sit around the payment infrastructure.

An organization's workflow, responsibilities and authorizations are customer decisions. FDP processing and required controls are a separate boundary.

Completing an internal authorization does not approve FDP processing, and FDP processing state is not evidence that an organization's own approvals occurred.

Enterprise control layer

Customer organizational decisions

  • Workflow
  • Responsibilities
  • Actions / Authorization

FDP transaction layer

FDP processing and required controls

  1. 01 · INVCommercial reference
  2. 02 · PAYPayment
  3. 03 · PRCProcessing
  4. 04 · STLSettlement
  5. 05 · RECReconciliation

Conceptual. The control layer surrounds the transaction layer; it does not replace it.

Connect without rebuilding the payment model.

Organizations may ultimately connect through supported integration methods while FDP maintains a consistent underlying transaction architecture. Supported methods are subject to final technical implementation and product availability.

  • Business application
  • Commerce environment
  • Internal payment workflow
  • API / integration

FDP operating model

One transaction architecture, whichever way activity arrives.

Conceptual inputs. Not a list of production-ready integrations.

Keep the payment journey connected.

First Digital Pay's role is to keep each part of the payment journey connected to the others. This describes coordination of records and handoffs, not custody of funds.

  1. 01

    Payment initiation

    Eligible activity begins a payment record.

  2. 02

    Transaction records

    Each record keeps its reference and relationships.

  3. 03

    Applicable processing

    Processing follows the applicable path for the activity.

  4. 04

    Required controls

    FDP-side controls apply where required.

  5. 05

    Settlement relationship

    Processed activity relates to the applicable settlement.

  6. 06

    Reconciliation records

    Settlement is matched back to payments and references.

See the records behind the operation.

Commercial, payment, processing, workflow, settlement and reconciliation information viewed together, with each state kept as its own concept.

Cross-layer record view

Commercial reference
PO-51930
Payment record
PAY-2026-2207
Processing state
Processing
Workflow state
Completed
Settlement relationship
Not yet allocated
Reconciliation state
Pending settlement
Last updated
29 Sep 2026, 11:05

Illustrative example. A completed organizational workflow does not mean FDP processing or settlement is complete.

Designed for operational continuity.

Clear system boundaries
Each layer has a defined responsibility and handoff.
Traceable records
Activity can be followed through consistent references.
Controlled state transitions
Records move between states through defined changes.
Error handling
Failures are surfaced rather than silently absorbed.
Recoverable workflows
Interrupted activity can be identified and resumed or resolved.
Consistent transaction references
The same reference model applies across layers.

These are architecture objectives, not published service guarantees or service-level commitments.

Security across system boundaries.

Principles the architecture is designed around. Specific implementations remain subject to final security review.

Authenticated access
Access begins with verified identity.
Authorization
Actions are permitted server-side, not by hidden interface controls.
Tenant isolation
One organization's records stay separate from another's.
Protected integration
Connections into FDP are designed to be protected.
Transaction integrity
Records and references are designed to remain consistent.
Controlled operational access
Operator access is intended to be limited and governed.
History and traceability
Changes are designed to remain traceable over time.

Infrastructure developers can build against.

The same underlying object model is intended to eventually support:

  • Merchant application
  • Enterprise workflows
  • APIs
  • Event-driven integrations
  • Reporting
Discuss integration

Infrastructure ultimately serves the business outcome.

The purpose is not technology for its own sake. It is a clearer path from commercial activity to business settlement and records.

  1. 01Commercial activity
  2. 02Payment infrastructure
  3. 03Processing
  4. 04Settlement
  5. 05Reconciliation

Design payment infrastructure around your operating environment.

Tell us about your systems, payment workflows, organizational controls and settlement requirements.

Availability varies by product, jurisdiction, configuration and eligibility.