POS Layer / Universal Payment Router

This page describes planned architecture. It is not a live payment product.

No live payment processing, escrow, custody, banking, money transmission, crypto, token, or securities functionality is claimed by this page.

Summary

The POS Layer is the planned transaction-routing layer for QTM OS. Its intended role is to help operator surfaces capture payment intent, normalize payment method data, and route payment events into ServiceEvent-linked settlement records — without allowing payment state to replace or override execution truth.

The POS Layer is designed as a processor-agnostic Universal Payment Router. Payment processors and payment rails are adapters into the settlement record model. They are not the source of execution truth.

Payment movement is not proof of work. The ServiceEvent remains the source of truth for executed reality.

Current Status

Status: Planned / Architecture Thesis

No POS Layer has been implemented. The following capabilities are claimed by this page:

• None are live.
• No payment processing exists.
• No escrow functionality exists.
• No custody or banking functionality exists.
• No money transmission functionality exists.
• No crypto, digital asset, or token rail exists.
• No securities functionality of any kind is claimed.

This page exists to define the intended architectural role of the POS Layer within QTM OS so that future implementation can be governed correctly.

Why the POS Layer Exists

Real-world service work involves multiple ways to pay: card, ACH, cash, invoice, wire, wallet, network credits, or future payment methods not yet defined. Without a structured routing layer, payment events become ad hoc and difficult to attach to the correct execution records in a consistent, auditable way.

QTM OS needs a payment routing layer for two reasons:

1. To record payment state accurately. When a payment is made, attempted, authorized, captured, refunded, or disputed, that state should attach to a settlement record that is traceable to the underlying ServiceEvent.

2. To keep payment truth separate from execution truth. A payment being authorized or captured does not mean work was performed. A payment failing does not mean work was not performed. These are independent states. The POS Layer is designed so that this separation is enforced by architecture, not by convention.

What the POS Layer Is

The POS Layer is a planned routing and normalization layer for transaction events inside QTM OS.

Its intended responsibilities:

• Capture transaction intent — receive a payment intent or authorization request from an operator surface or customer flow
• Normalize payment method data — translate diverse payment inputs (card, ACH, invoice, wallet, credit) into a consistent internal event schema
• Route payment events into settlement records — connect normalized payment events to the appropriate ServiceEvent-linked settlement record
• Track payment state — record authorized, pending, captured, failed, refunded, disputed, and settled states without conflating them with execution state
• Support multiple processors as adapters — route payment events through whichever processor or rail is appropriate for the context, without requiring a single payment processor to be the source of system truth
• Preserve the execution record — ensure that payment state attaches to records downstream of ServiceEvent completion, not upstream of it

The POS Layer is processor-agnostic by design. Processors and payment rails are adapters. The settlement record is the normalized output. The ServiceEvent is the source of execution truth that precedes it.

What the POS Layer Is Not

The POS Layer is not any of the following, and must not be described as any of the following unless a specific implementation is built, tested, legally reviewed, and explicitly approved:

• Not a bank. It does not hold deposits, issue credit, or perform any banking function.
• Not a payment processor. It routes payment events; it does not independently process card or ACH transactions.
• Not a money transmitter. It does not transmit money on behalf of others in the regulatory sense.
• Not an escrow service. It does not hold funds on behalf of parties to a transaction.
• Not a crypto exchange. It does not facilitate trading, conversion, or custody of digital assets.
• Not a wallet. It does not store value on behalf of users.
• Not a securities platform. It does not issue, trade, or facilitate investment in any financial instrument.
• Not proof that work occurred. Payment authorization or capture does not constitute evidence of execution.

Relationship to ServiceEvents

The ServiceEvent is the execution record for QTM OS. It captures what work was performed, by whom, under what conditions, with what evidence, and when it was completed.

The POS Layer operates downstream of and alongside the ServiceEvent — it does not replace it.

A payment being authorized does not mean work was performed. A payment failing does not mean work was not performed. A ServiceEvent being completed does not automatically mean payment has been captured.

These states must remain independent. The POS Layer is designed to enforce this independence, not to collapse it.

Relationship to Settlement

Settlement is the layer where payment state attaches to execution records. The POS Layer feeds settlement.

The sequence is:

ServiceEvent (execution truth)
  → Record (durable execution output)
    → Settlement record (payment state attached)
      ← POS Layer feeds payment events here

Settlement does not override ServiceEvent truth. A settled payment record points to a ServiceEvent; it does not replace it. A missing or failed payment does not invalidate a completed ServiceEvent.

The POS Layer’s role ends at the settlement record boundary. It does not reach back into execution, assignment, or evidence layers.

Future Payment Methods and Currencies

The following are possible future integration categories for the POS Layer. None are currently supported. None are live. These are planning references only.

Multi-currency and digital asset support are the furthest from implementation. Any payment rail that involves regulated activity — money transmission, custody, digital asset exchange — requires explicit legal and regulatory review before it can be built or described as live.

Processor Optionality

The POS Layer is designed to be processor-agnostic. No single processor or rail is built into the system architecture. Processors are adapters.

Future processor adapter categories may include:

• Platform-managed merchant account
• Operator-owned merchant account
• Card processor integration
• ACH provider integration
• Invoice or payment-link provider
• Wire or manual settlement record
• Wallet or digital asset rail, if legally and technically approved

No provider is named as integrated here because none are integrated. When a processor is implemented, it will be documented explicitly in the relevant implementation page with accurate status, not on this architectural overview page.

Processor choice must not change execution truth. Whether payment comes through a platform merchant account, an operator-owned merchant account, ACH, card, invoice, wire, wallet, or manual record — the ServiceEvent remains the source of truth for work performed.

Governance Rules

The following rules apply to any future POS Layer implementation. These are not aspirational — they are architectural invariants that must be preserved.

1. No payment event becomes completion by itself. A payment being captured does not close a ServiceEvent or create a Record.

2. No settlement event bypasses assignment. Payment state cannot create, approve, or substitute for an assigned job.

3. No payout should occur without a linked ServiceEvent. Settlement payouts must trace back to a completed ServiceEvent and Record.

4. No payment claim should be treated as evidence of execution. Payment authorization, capture, or settlement is not a substitute for execution evidence.

5. No financial rail should be described as live unless it is implemented, tested, and approved. Architectural intent does not equal working infrastructure.

6. No regulated capability should be activated without compliance review. Any payment rail that involves money transmission, custody, escrow, or digital assets requires explicit legal review before activation.

7. Processor choice must not change execution truth. The ServiceEvent remains the source of truth for work performed, regardless of how or through what payment method value was exchanged.

8. POS Layer must not reach upstream of the execution spine. The POS Layer connects to settlement records. It does not touch intake, task, job, or ServiceEvent state directly.

Example Future Flow

This is an illustrative architectural sketch. None of this flow is live.

1. Customer submits request
2. Operator accepts assignment
3. Job becomes active
4. ServiceEvent is opened — execution begins
5. POS Layer captures payment intent (pre-authorization or invoice created)
6. Settlement record is initialized, linked to the Job and ServiceEvent
7. Operator performs work
8. Evidence is captured (photos, notes, delivery confirmation, etc.)
9. ServiceEvent is completed — execution truth is recorded
10. Record is created from the completed ServiceEvent
11. POS Layer updates payment state (capture, confirmation, or failure)
12. Settlement record is updated with final payment state
13. Record preserves both execution truth and payment state, independently

Execution truth (steps 4–10) and payment truth (steps 5, 11–12) run in parallel and attach at the Record level. Neither overrides the other.

Public Interpretation Notice

This page describes planned architecture for QTM OS. It is not a product announcement, a product release, or a description of live functionality.

Nothing in this page should be interpreted as:

• a live payment product or payment service
• a payment processor or payment rail
• a bank, custodian, or regulated financial institution
• an escrow or trust account service
• a money services business or money transmitter
• a securities offering, investment product, or fund
• an offer to manage capital on behalf of others
• a live cryptocurrency, digital asset, or token system
• evidence that any regulated financial activity is currently occurring

The POS Layer is a planned architectural namespace. It does not exist as a live system. Building any part of it as regulated financial infrastructure will require explicit legal, regulatory, technical, and governance steps beyond what is described here.

Payment movement is not proof of work. The ServiceEvent remains the source of truth for executed reality.

Related Pages

• Execution Spine
• Economic Structure Layer
• Records and Service Events
• Settlement
• oracle.x1
• planck.x1
• System Status
• Glossary