# 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.

> Document ID: MYRILUM-DOC-ARCH-022
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 780ae49e58ccc109eb07437f486eef816cbd2a445cb64a96f2ee8bcebffbba47
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/payments-and-settlement

<a id="overview"></a>

## What this map shows

![Orders, payments, settlement and disputes diagram (A22)](/figures/atlas-v2-2/A22.png)

*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.*

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.

<a id="part-1"></a>

## Commercial relationships and authorization

| Field | Value |
|---|---|
| Parties and product | Buyer and seller, product version, scope of service and responsibilities |
| Quote or contract | Amount, currency, billing method, validity and after-sales terms |
| Order | A stable order identifier; a contract snapshot and fulfilment references |
| Payment authorization | Uses an approved channel; a client-side page is not evidence of funds |

> **Two commercial meanings kept apart** — A user paying the platform a subscription is not the same commercial object as the fees, revenue shares and refunds of a third-party trade.

<a id="part-2"></a>

## External payment status enters the platform

| Field | Value |
|---|---|
| Payment service receipt | External operation identifier, status and actual amount |
| Callback verification and de-duplication | The source is verified; events may repeat, arrive late or out of order |
| Status reconciliation | Queries the current external state; unknown is never treated as failed |
| Formal booking | Written by rule; entitlements and fulfilment are driven by events |

> **Not an authorization to hold funds** — This map fixes neither the receiving entity nor the payment providers, and assumes no qualification for escrow, remittance or financial transactions.

<a id="part-3"></a>

## Fulfilment and what follows

| Field | Value |
|---|---|
| Work and delivery | Tasks, evidence, results and the service period |
| Acceptance or dispute | An authorized user accepts, or a defined dispute process begins |
| Settlement | Triggered by the contract and approval decisions; a model never releases funds on its own |
| Continuous reconciliation | Platform accounts, provider accounts and the actual state of funds are checked against each other |

> **Acceptance and funds** — Governed by the contract and the applicable approvals; a verification result alone can neither replace the buyer's acceptance nor release funds automatically.

<a id="part-4"></a>

## Exceptions and after-sales

| Field | Value |
|---|---|
| Timeout or unknown | Query the original operation; never blindly repeat a payment |
| Refund request and execution | Reason, scope, approval, external receipt and a correcting entry |
| Dispute or chargeback | Evidence, deadlines, the accountable party and a handling record |
| Recovery or compensation | Corrects entitlement and fulfilment links; history is kept |

> **Disputes rest on rules, not a button** — Who rules, how to appeal, the deadlines and how outcomes are carried out all need explicit rules; a “handle” button on screen never replaces them.

<a id="source"></a>

## 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”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.