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.
- 01OrganizationCommercial environment
- 02Business SystemsApplications and workflows
- 03FDP Integration LayerConnection into FDP
- 04Payment & ProcessingFDP payment records and processing
- 05SettlementApplicable settlement path
- 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.
- 01 · INVCommercial reference
- 02 · PAYPayment
- 03 · PRCProcessing
- 04 · STLSettlement
- 05 · RECReconciliation
Illustrative example. Reference prefixes are working conventions, not final technical identifiers.
A structured layer between commerce and settlement.
- 01
Commercial Layer
Where the organization's business activity creates the need for payment.
- 02
Integration Layer
How eligible payment activity can connect with FDP.
- 03
Payment & Processing Layer
Where payment records and applicable processing activity are managed.
- 04
Settlement Layer
Where eligible processed activity connects to the applicable settlement arrangement.
- 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
- 01 · INVCommercial reference
- 02 · PAYPayment
- 03 · PRCProcessing
- 04 · STLSettlement
- 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.
- 01
Payment initiation
Eligible activity begins a payment record.
- 02
Transaction records
Each record keeps its reference and relationships.
- 03
Applicable processing
Processing follows the applicable path for the activity.
- 04
Required controls
FDP-side controls apply where required.
- 05
Settlement relationship
Processed activity relates to the applicable settlement.
- 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
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.
- 01Commercial activity
- 02Payment infrastructure
- 03Processing
- 04Settlement
- 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.