Docs

Search and contents

Orders, payments, settlement and disputes

The platform's own accounts are kept apart from third-party marketplace commerce, and the real state of funds follows verified external records. An unclear state is reconciled first; refunds and settlement need authorization, receipts and journal entries, and nothing is booked on a model's answer.

In developmentNot availableVerified

Orders, payments, settlement and disputes diagram (A22) (open full-size figure)
MYRILUM architecture map v2.2 · A22 (public edition). Labels are in Chinese; every element is listed in English below. Select the diagram to open it at full size.

What this map shows

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

The platform's own accounts are kept apart from third-party marketplace commerce; the real state of funds rests on verified external records.

When the state of funds is unknown, reconcile first; refunds and settlement have authorization, receipts and journal entries, and nothing is booked on the strength of a model's answer.

Commercial relationships and authorization

Parties and productBuyer and seller, product version, scope of service and responsibilities
Quote or contractAmount, currency, billing method, validity and after-sales terms
OrderA stable order identifier; a contract snapshot and fulfilment references
Payment authorizationUses an approved channel; a client-side page is not evidence of funds

External payment status enters the platform

Payment service receiptExternal operation identifier, status and actual amount
Callback verification and de-duplicationThe source is verified; events may repeat, arrive late or out of order
Status reconciliationQueries the current external state; unknown is never treated as failed
Formal bookingWritten by rule; entitlements and fulfilment are driven by events

Fulfilment and what follows

Work and deliveryTasks, evidence, results and the service period
Acceptance or disputeAn authorized user accepts, or a defined dispute process begins
SettlementTriggered by the contract and approval decisions; a model never releases funds on its own
Continuous reconciliationPlatform accounts, provider accounts and the actual state of funds are checked against each other

Exceptions and after-sales

Timeout or unknownQuery the original operation; never blindly repeat a payment
Refund request and executionReason, scope, approval, external receipt and a correcting entry
Dispute or chargebackEvidence, deadlines, the accountable party and a handling record
Recovery or compensationCorrects entitlement and fulfilment links; history is kept

Source

This page follows A22 of the MYRILUM architecture map v2.2 (public edition: restricted products and internal open items are left out). Related: “Commerce and the five ledgers”; “STORE and the capability marketplace”; “Metering, budgets, service credit and ledgers”.

Was this page helpful?

MYRILUM platform architecture overviewSee how participants, the unified entry, business platform domains, the shared core, the agent layer, the execution network and infrastructure are layered, and how governance runs through all of them.Commerce and the five ledgersTransactions define commitments, metering records consumption and ledgers record changes in value; fulfilment and acceptance are never replaced by a successful payment.STORE and the capability marketplaceMARKET handles supply-and-demand discovery and STORE carries productized buying and orders, sharing one set of commercial and fulfilment records; products that can be fulfilled come before a marketplace that can be operated.Metering, budgets, service credit and ledgersReserve first, then execute, and keep real consumption apart from what users are billed; cash, service credit, entitlements, resource usage and contribution are five kinds of record, each managed in its own units and rights, and reconciliation finds what does not match.What is available now?What MYRILUM officially operates today: distinguish website browsing, the member store, scoped delivery and component records, and check availability for the region and account.
Sources and maintenance
Region
Global
Version
0.1.0
Publication
Published globally
Document status
Approved · Drafted
Authorization
Public information
Command authority
None
Type
Concept
Audience
Technical leads, Developers, Organization leaders, Integration partners, Agents
Safety class
Informational
Agent tasks
understand_platform_architecture
Owner
Web3Capital Documentation Steward
Last verified
2026-09-23
Review due
2026-10-23
Source commit
6b41cce4496d
Canonical authority
SRC-ARCHITECTURE-ATLAS-V2-2
Content digest
780ae49e58ccc109
Stable citation
MYRILUM-DOC-ARCH-022@0.1.0:en#overview

Machine-readableMarkdownMetadataJSON-LDChunks

This documentation grants no execution, release, or production authority.

Sources and maintenance

Region
Global
Version
0.1.0
Publication
Published globally
Document status
Approved · Drafted
Authorization
Public information
Command authority
None
Type
Concept
Audience
Technical leads, Developers, Organization leaders, Integration partners, Agents
Safety class
Informational
Agent tasks
understand_platform_architecture
Owner
Web3Capital Documentation Steward
Last verified
2026-09-23
Review due
2026-10-23
Source commit
6b41cce4496d
Canonical authority
SRC-ARCHITECTURE-ATLAS-V2-2
Content digest
780ae49e58ccc109
Stable citation
MYRILUM-DOC-ARCH-022@0.1.0:en#overview

This documentation grants no execution, release, or production authority.