Commerce: Orders and Payments

7.1 Introduction

Commerce is MICROBA's commercial transaction capability.

It receives a valid Commercial Request from a source capability, creates the Order, preserves the committed commercial agreement, manages payment, records transactions, and publishes the resulting commercial events to the rest of the MICROBA ecosystem.

Commerce is deliberately product-agnostic.

Product, Launch, Subscription, Marketplace, Clinic, and future MICROBA capabilities may request a commercial transaction without implementing their own independent order and payment systems.

The core principle is:

**Source capabilities describe what is being purchased. Commerce owns

the commercial agreement and payment lifecycle.**

7.2 The Universal Commerce Pipeline

The canonical Commerce architecture is:

INPUT
  |
COMMERCE
  |
OUTPUT

A source capability provides an approved Commercial Request.

Commerce converts that request into a controlled Order and Payment lifecycle.

After the transaction changes state, Commerce publishes authoritative outputs for downstream capabilities.

Example:

Product
   |
Commercial Request
   |
Commerce
   |
Order
   |
Payment
   |
Transaction
   |
Commercial Events
   |
HIVE / SA / Product / Other Capabilities

7.3 Commerce Does Not Own Everything

Commerce owns the commercial agreement.

It does not become the owner of every business concept connected to a transaction.

Commerce owns:

• Order;
• committed commercial snapshot;
• Payment Intent;
• payment-provider interaction;
• payment lifecycle;
• transaction records;
• receipts;
• refunds and commercial reversals;
• commercial status; and
• commercial events.

Commerce does not own:

• member identity;
• Product definition;
• HIVE sponsor relationships;
• SA serial ownership;
• Treasury SA inventory;
• Knowledge progress;
• Launch event identity;
• accounting truth for the entire organization; or
• analytics for every module.

This separation prevents Commerce from becoming a monolithic system.

7.4 Source Capabilities

A source capability is a MICROBA module that needs Commerce to process a commercial agreement.

Examples include:

• Product;
• Launch;
• Marketplace;
• Subscription;
• Clinic; and
• future MICROBA capabilities.

The source capability creates a Commercial Request.

It does not directly create a payment-provider transaction.

7.5 Commercial Request

A Commercial Request describes the transaction that Commerce is being asked to create.

Conceptually, it may contain:

• source capability;
• source reference;
• member/customer identity where required;
• item identity;
• quantity;
• trusted price information;
• currency;
• committed snapshot;
• applicable adjustments;
• SA usage request where allowed;
• commercial metadata; and
• idempotency/reference information.

The exact technical contract belongs in contracts/interfaces.md and the Commerce architecture specification.

7.6 Commerce Creates the Order

Only Commerce creates the canonical Commerce Order.

Canonical flow:

Source Capability
       |
Commercial Request
       |
Commerce::createOrder()
       |
Canonical Order

The source capability should store or reference the Commerce Order ID rather than creating a competing order system.

7.7 Order Identity

Every Commerce Order should have a stable unique identifier.

Example:

Order ID: ORD-100025

The Order ID allows:

• member support;
• payment reconciliation;
• HIVE attribution;
• SA reconciliation;
• refunds;
• receipts;
• audit;
• downstream event correlation; and
• historical lookup.

7.8 Commercial Snapshot

When Commerce creates an Order, it preserves the commercial facts that applied at that moment.

A snapshot may include:

• item identity;
• item description;
• quantity;
• unit price;
• gross value;
• discount;
• SA usage;
• payable amount;
• currency;
• source reference;
• member identity;
• sponsor context where relevant; and
• other required transaction facts.

This protects historical integrity.

A future change to Product price or configuration must not silently rewrite an existing Order.

7.9 Never Trust Browser-Supplied Amounts

The browser is not the source of truth for commercial values.

Commerce must not accept an arbitrary amount simply because the checkout page sends it.

Conceptually:

Browser says:
Rp10

Trusted Server Snapshot says:
Rp1,000,000

Commerce uses:
Rp1,000,000

The same principle applies to:

• quantity;
• currency;
• discounts;
• SA usage;
• eligible sales;
• Product configuration; and
• other protected commercial values.

7.10 Living Cart + Checkout

The current MICROBA architecture combines Cart and Checkout into a single Commerce experience for the expected low-item-volume journey.

Canonical flow:

Committed Source Snapshot
          |
      Commerce
          |
Living Cart + Checkout
          |
Payment Provider
          |
Confirmation

This simplifies the member experience while preserving Commerce ownership.

7.11 Commerce Payment Page

The canonical Commerce Payment Page does not create a new Order.

It receives or securely resolves an existing Commerce Order.

Conceptually:

Order Created
    |
Secure Payment URL / Token
    |
Commerce Payment Page
    |
Load Existing Order
    |
Select Payment Provider
    |
Pay

The payment page reads authoritative amount, currency, snapshot, and status from the server.

It does not trust the URL or browser to provide those values.

7.12 Secure Payment Token

A Payment Page should use a non-guessable token or equivalent secure reference where appropriate.

The token should identify the existing Order without exposing a predictable sequence that allows unauthorized access.

The token is not the commercial amount.

It is only a secure way to locate the authorized payment context.

7.13 Payment Intent

Commerce creates and owns the Payment Intent.

The Payment Intent represents an attempt or requirement to settle the Order using an approved Payment Provider.

Conceptually:

Order
  |
Payment Intent
  |
Provider
  |
Payment Result

An Order may require more than one Payment Intent over its lifetime if a payment fails, expires, is retried, or another approved provider is selected.

7.14 Payment Providers

Commerce abstracts payment methods through a common Payment Provider architecture.

The core Commerce engine should not be rewritten every time MICROBA adds a provider.

Potential providers include:

• Mock;
• Cash on Delivery (COD);
• Wallet;
• Bank Transfer;
• Stripe;
• Xendit;
• HitPay;
• Midtrans;
• PayPal; and
• future providers.

Conceptually:

Commerce
   |
PaymentProviderInterface
   |
   +-- Mock
   +-- COD
   +-- Midtrans
   +-- Stripe
   +-- Xendit
   +-- HitPay
   +-- PayPal
   +-- Future Provider

7.15 Provider Independence

A Product should not need to know whether the purchaser uses Midtrans, Stripe, COD, or another provider.

Likewise, HIVE and SA should not depend directly on provider-specific APIs.

They depend on authoritative Commerce events.

This allows payment infrastructure to evolve without changing the business capabilities.

7.16 Midtrans

Midtrans may be used as a payment-provider adapter in the current or intended implementation.

Where Midtrans Snap is used:

Commerce Order
      |
Create Payment Intent
      |
Midtrans Adapter
      |
Generate Snap Token
      |
Payment Interface
      |
Webhook / Verification
      |
Commerce Updates Payment State

Midtrans remains an adapter.

It does not become the owner of the MICROBA Order.

7.17 Cash on Delivery

COD is a real Payment Provider, not an immediate "paid" shortcut.

The canonical COD lifecycle is:

awaiting_collection
        |
collected
        |
verified
        |
paid

Selecting COD must not immediately mark the Order as paid.

This protects reconciliation.

7.18 Manual Accounting Adjustment

Manual Accounting Adjustment is not the same as COD.

It is a separate controlled process/provider for exceptional authorized adjustments.

It should require:

• restricted capability;
• reason;
• reference;
• audit trail;
• appropriate approval controls; and
• reversal rather than deletion when corrected.

Manual adjustment must not become an unrestricted "mark as paid" button.

7.19 Payment Status

Commerce owns payment status.

A conceptual lifecycle may include:

created
  |
pending
  |
authorized / awaiting action
  |
paid

Other possible states include:

• failed;
• expired;
• cancelled;
• refunded;
• partially refunded;
• awaiting collection;
• collected;
• verification required; and
• reversed.

Provider-specific states should be translated into canonical Commerce states where appropriate.

7.20 Order Status and Payment Status

Order status and Payment status are related but not identical.

Example:

Order: Processing
Payment: Paid

or:

Order: Awaiting Payment
Payment: Pending

Commerce should preserve this distinction rather than forcing every operational state into one field.

7.21 Payment Verification

A browser redirect saying "success" is not sufficient proof of payment.

Commerce should verify payment using the trusted provider mechanism.

Depending on the provider, this may include:

• webhook;
• signed notification;
• provider API verification;
• controlled COD verification; or
• another approved method.

Only after authoritative verification should Commerce advance the payment to the appropriate confirmed state.

7.22 Webhooks

Where a Payment Provider supports webhooks, Commerce receives and verifies them.

The process should be idempotent.

Example:

Provider sends webhook
        |
Commerce verifies
        |
Already processed?
   |             |
  YES           NO
   |             |
Ignore safely   Apply state transition

Repeated provider notifications must not duplicate payment, HIVE, SA, or downstream effects.

7.23 Idempotency

Commerce operations that may be retried should be idempotent.

This means the same valid request can be safely retried without accidentally creating duplicate economic effects.

Examples include:

• order creation;
• payment confirmation;
• webhook handling;
• refund processing;
• event publication; and
• downstream command handling.

Idempotency is essential for reliable automated reconciliation.

7.24 Transaction Records

Commerce records commercial transactions.

A transaction record may include:

• transaction ID;
• Order ID;
• Payment Intent ID;
• provider;
• amount;
• currency;
• transaction type;
• provider reference;
• status;
• timestamp; and
• related reversal/reference information.

Transactions should remain auditable.

7.25 Receipts

Commerce may generate or provide the data required for a receipt after the applicable payment state is confirmed.

A receipt should reflect the actual commercial transaction.

It should not invent HIVE or SA ownership information that belongs to other modules.

Where useful, the member-facing receipt may show the SA amount used as part of the commercial settlement.

7.26 SA as Part of Commerce

Commerce coordinates SA usage when SA is used toward a purchase.

Example:

Order Value:     Rp300,000
SA Used:         2 SA
SA Reference:    Rp60,000
Other Payment:   Rp240,000

Commerce records the commercial composition.

The SA system validates the SA and records movement of the actual serial-numbered units.

7.27 Full SA Purchase

The current architecture permits an eligible Order to be settled 100% with SA.

Example:

Order Value: Rp300,000
SA Used:     10
SA Value:    Rp300,000
Cash Due:    Rp0

Commerce still creates an Order.

The transaction is not bypassed merely because no external cash payment is required.

Commerce must still coordinate:

• SA validation;
• SA movement;
• commercial completion;
• downstream events;
• reconciliation; and
• receipt/history.

7.28 SA Is Not a Payment Provider Shortcut

SA should not be treated as an arbitrary browser discount code.

SA has:

• serial identity;
• ownership/holding state;
• Treasury circulation;
• transaction history; and
• programme rules.

Commerce asks the SA capability to validate and apply eligible SA usage.

Commerce does not fabricate SA balances.

7.29 SA Provision From Sales

Eligible Commerce sales may create SA provision.

The current system reference is:

SA Provision = 3% of Eligible Sales

Example:

Eligible Sale: Rp10,000
Provision:     Rp300

The Rp300 is backend provision value.

It does not mean a fractional serial-numbered SA has been issued.

7.30 Whole-SA Entitlement

At the current programme reference:

1 SA = Rp30,000

When accumulated valid provision reaches the required whole-SA threshold, the SA system can fulfill the entitlement.

Example:

Accumulated Provision
Rp30,000
    |
Entitlement
1 SA

The SA system checks Treasury inventory before minting a new SA.

7.31 Recycle Before Mint

The canonical SA fulfillment sequence triggered by eligible Commerce activity is:

SA Entitlement
      |
Check Treasury
      |
Available recycled SA?
   |              |
  YES             NO
   |              |
Release SA      Mint shortage

If Treasury has enough SA, no new SA needs to be generated.

If Treasury has only part of the requirement, recycled SA is used first and only the shortage is newly generated.

7.32 Commerce and Treasury Monitoring

Commerce should provide enough authoritative sales information for SA/Treasury reconciliation.

The system can monitor the relationship between:

• eligible sales;
• backend SA provision;
• SA entitlement;
• recycled SA;
• newly generated SA;
• member-held SA;
• Treasury-held SA; and
• SA used or redeemed.

Commerce does not become the owner of Treasury.

It provides the commercial facts required for reconciliation.

7.33 Current SA Economic Reference

The current system model uses:

1 SA = Rp30,000 programme reference value
SA Provision = 3% of eligible sales

Therefore:

Rp1,000,000 eligible sales
x 3%
= Rp30,000 provision
= 1 whole-SA entitlement

At system level, this creates a consistent relationship between sales and SA provision.

7.34 Commerce and HIVE

Commerce provides authoritative eligible-sales information to HIVE.

HIVE then determines whether a valid Direct Sponsor exists and applies its current rule.

Conceptually:

Commerce
  |
Eligible Sale
  |
HIVE
  |
Valid Direct Sponsor?
  |
9% Direct Sponsorship

Commerce does not create arbitrary sponsor relationships.

HIVE does not alter the Order price.

7.35 Current HIVE Reference

The current HIVE model uses:

Direct Sponsorship = 9% of eligible direct sponsored sales

Example:

Eligible Sponsored Sale: Rp1,000,000
HIVE Rate:                9%
Sponsorship:              Rp90,000

If there is no valid Direct Sponsor:

HIVE Sponsorship = Rp0

The sale remains valid.

7.36 Eligible Sales

Commerce is responsible for producing the authoritative commercial facts from which eligible-sales rules can be evaluated.

Eligible sales should not be guessed independently by every downstream module.

The exact eligible-sales formula may need to consider:

• gross Product value;
• approved discounts;
• SA-funded amount;
• taxes;
• shipping;
• refunds;
• cancellation;
• reversals;
• excluded Product components; and
• other programme rules.

The final formula should be explicitly locked before public financial implementation.

7.37 Important Open Rule: SA-Funded Eligible Sales

A transaction can include SA.

For example:

Product Value: Rp300,000
SA:            Rp60,000
Cash:          Rp240,000

The architecture already permits the transaction.

However, the exact definition of the eligible-sales basis used for new SA provision and HIVE commission must be explicit.

Possible concepts include:

Gross Product Value
vs.
Net External Payment
vs.
Programme-Defined Eligible Value

This chapter does not silently choose between them.

The final rule must be locked in the Commerce/SA/HIVE financial specification to prevent circular value creation or inconsistent calculations.

7.38 Discounts

Commerce should record discounts explicitly.

A commercial snapshot may distinguish:

Gross Value
- Approved Discount
- SA Benefit
= Remaining Amount

This makes the transaction understandable to members and auditable by the system.

Different adjustment types should not be collapsed into one unexplained number.

7.39 Refunds

Commerce owns commercial refunds.

Canonical flow:

Paid Order
   |
Refund Requested / Approved
   |
Commerce Refund
   |
Provider / Settlement Action
   |
Refund Transaction
   |
Downstream Reversal Events

Commerce should notify affected capabilities rather than directly rewriting their records.

7.40 Downstream Refund Effects

A refund may affect:

• HIVE sponsorship;
• SA provision;
• SA entitlement;
• SA used in the purchase;
• Product state;
• receipt status; and
• other downstream processes.

Each owning capability performs its own approved reversal.

Example:

Commerce Refund
      |
      +---- HIVE reversal
      |
      +---- SA adjustment
      |
      +---- Product update

7.41 No Silent Deletion

Commerce must not silently delete historical transactions to correct a balance.

Corrections use:

• reversal;
• refund;
• adjustment;
• cancellation;
• compensating transaction; or
• another explicit audited process.

The original transaction remains traceable.

7.42 Strong and Eventual Consistency

Within a Commerce aggregate, the platform should use strong consistency where required.

Across independent engines, MICROBA uses event-driven eventual consistency.

Conceptually:

Commerce Order
Strong Internal Consistency
        |
Immutable Event
        |
Other Engines
Eventually Consistent

MICROBA should avoid distributed transactions across independent engines.

7.43 Transactional Outbox

When Commerce changes an important state and must publish an event, the system should use a reliable event-publication pattern such as a transactional outbox.

Conceptually:

Commerce Database Transaction
   |
   +-- Update Order
   +-- Write Outbox Event
   |
Commit
   |
Publish Event

This reduces the risk of an Order becoming paid while the corresponding downstream event is permanently lost.

7.44 Deduplicated Inbox

Downstream capabilities should process Commerce events through deduplication or equivalent idempotent handling.

Example:

commerce.order.paid
       |
HIVE receives twice
       |
Event ID already processed?
       |
YES
       |
Do not create second commission

The same applies to SA and other engines.

7.45 Process Managers and Sagas

Complex multi-capability commercial workflows may use process managers or sagas.

For example:

Commerce Order
     |
SA Reservation
     |
External Payment
     |
Confirmation
     |
SA Commit
     |
Order Paid

If a step fails, the process coordinates the appropriate compensating action.

The goal is reliable orchestration without distributed database transactions.

7.46 Reconciliation

Commerce must support automatic reconciliation.

The system should be able to compare:

• Orders;
• Payment Intents;
• provider transactions;
• confirmed payments;
• refunds;
• HIVE outputs;
• SA outputs;
• Treasury interactions; and
• downstream processing status.

A mismatch should be detectable rather than silently ignored.

7.47 Human-Readable Monitoring

Although the backend may contain detailed accounting and technical records, the operational dashboard should present understandable numbers.

For example:

COMMERCE TODAY

Sales
Rp30,000,000

Paid Orders
312

Pending Payments
18

Refunds
Rp250,000

SA Provision
Rp900,000

HIVE Sponsorship Generated
Rp1,620,000

The exact metrics depend on the final reporting model.

The principle is:

**Complex reconciliation in the backend; simple meaning in the

dashboard.**

7.48 Commerce Is Not the Accounting Ledger

Commerce records commercial truth.

It does not necessarily replace the organization's formal accounting system.

For example, Commerce can say:

Order Paid: Rp1,000,000
Provider Fee: ...
Refund: ...
SA Used: ...

A Finance or Accounting capability may later interpret these records according to formal accounting rules.

This separation prevents accounting terminology from being incorrectly embedded into business modules.

7.49 Commerce Events

Commerce should publish immutable events representing meaningful commercial facts.

Examples may include:

commerce.order.created
commerce.payment.pending
commerce.payment.paid
commerce.order.paid
commerce.order.cancelled
commerce.refund.completed
commerce.order.refunded

Exact event names and payloads belong in contracts/events.md.

Events describe what happened.

They should not become hidden remote procedure calls.

7.50 Commerce Commands

Commerce may accept explicit commands such as:

CreateOrder
CreatePaymentIntent
ConfirmPayment
CancelOrder
RequestRefund
ApplySA

Exact command names and contracts belong in contracts/commands.md.

Commands request an action.

Events record that an action or state change occurred.

7.51 NEXUS Communication

Cross-module Commerce communication should use the MICROBA communication backbone rather than tightly coupling engines directly.

Conceptually:

Product
   |
Command / Request
   |
NEXUS
   |
Commerce
   |
Event
   |
NEXUS
   |
HIVE / SA / Product / Other Engines

This keeps modules loosely coupled and replaceable.

7.52 Commerce and MICX

Within the broader MICROBA architecture, Commerce capabilities execute through approved platform mechanisms.

Commerce should not bypass the platform's constitutional, identity, authorization, and communication boundaries.

The exact runtime implementation belongs to the technical architecture documents.

7.53 Authorization

Commercial actions require appropriate authorization.

Examples include:

• viewing an Order;
• paying an Order;
• cancelling an Order;
• requesting a refund;
• applying SA;
• performing COD verification;
• performing manual adjustment; and
• issuing administrative refunds.

Knowing an Order ID must not automatically grant access to the Order.

7.54 Order Ownership

A member-owned Order should be associated with the canonical MID.

Example:

Order ORD-100025
Owner MID-000850

Commerce verifies ownership or another valid capability before exposing protected Order information.

7.55 Administrative Commerce Access

Authorized Admins may require access to Commerce operations.

Administrative capabilities should be explicit.

Examples may include:

• view all Orders;
• inspect Payment Intents;
• verify COD;
• process approved refund;
• perform controlled adjustment;
• view reconciliation issues; and
• investigate failed transactions.

Admin access is separate from ordinary member access.

7.56 Audit Trail

Important Commerce actions should be auditable.

Examples include:

• Order created;
• amount committed;
• Payment Intent created;
• provider selected;
• payment confirmed;
• payment manually verified;
• COD collected;
• COD verified;
• refund initiated;
• refund completed;
• manual adjustment;
• Order cancelled; and
• reconciliation correction.

The audit record should identify the relevant actor or system process where appropriate.

7.57 Failure Handling

Commerce should expect failure.

Possible failures include:

• provider unavailable;
• payment timeout;
• duplicate webhook;
• expired payment;
• insufficient SA;
• SA state changed before commit;
• network failure;
• source capability unavailable;
• downstream event temporarily unavailable; and
• reconciliation mismatch.

A failure should result in a controlled state rather than corrupted commercial history.

7.58 Retry Behaviour

Retryable operations should use safe retry policies.

Retries must not create:

• duplicate Orders;
• duplicate payment charges;
• duplicate HIVE commissions;
• duplicate SA entitlements; or
• duplicate refunds.

This is why idempotency and transaction references are required.

7.59 Example — Standard Cash/Provider Purchase

Product
  |
Commercial Request Rp1,000,000
  |
Commerce Creates Order
  |
Payment Intent
  |
Payment Provider
  |
Verified Payment
  |
Order Paid
  |
Commerce Event
  |
HIVE + SA + Product

7.60 Example — Purchase Without Sponsor

Order Value: Rp1,000,000
Payment:     Confirmed
Sponsor:     None

Commerce:
Sale valid

HIVE:
Rp0 sponsorship

SA:
Evaluate eligible 3% provision

7.61 Example — Purchase With Sponsor

Order Eligible Sales: Rp1,000,000
Direct Sponsor:       MID-A

Commerce confirms sale
        |
HIVE receives authoritative event
        |
9% = Rp90,000

SA evaluates its own 3% provision separately.

7.62 Example — Mixed SA Purchase

Order Value: Rp300,000

Settlement:
2 SA          = Rp60,000
Other Payment = Rp240,000

Commerce records both components.
SA records the serial movement.
Payment Provider handles Rp240,000.

The final eligible-sales basis for downstream generation must follow the locked financial rule.

7.63 Example — 100% SA Purchase

Order Value: Rp300,000
10 SA:       Rp300,000
Cash:        Rp0

Commerce still:

• creates the Order;
• validates the commercial snapshot;
• coordinates SA;
• completes the Order;
• publishes events; and
• preserves transaction history.

7.64 Example — COD

Order Created
    |
COD Selected
    |
awaiting_collection
    |
Goods / Service Delivered
    |
collected
    |
Authorized Verification
    |
verified
    |
paid

COD selection alone does not equal payment.

7.65 Example — Refund

Order Paid
Rp1,000,000
    |
Refund Approved
    |
Commerce Refund
-Rp1,000,000
    |
commerce.order.refunded
    |
HIVE / SA / Product perform
their own applicable reversals

7.66 Frequently Asked Questions

What is Commerce?

Commerce is the MICROBA capability that owns Orders, payment lifecycle, commercial transactions, receipts, refunds, and authoritative commercial events.

Does Product own my Order?

No. Commerce owns the Order.

Can Launch create its own payment system?

No. A Launch commercial requirement should use Commerce.

Can future MICROBA modules use Commerce?

Yes. Commerce is designed to be product-agnostic.

What is a Commercial Request?

It is the trusted request from a source capability asking Commerce to create a commercial agreement.

Who creates the canonical Order?

Commerce.

Does the Payment Page create an Order?

No. It securely loads an existing Commerce Order.

Can I change the price in my browser?

Changing browser data must not change the authoritative server-side commercial amount.

What is a Payment Intent?

It represents an attempt or requirement to settle an Order through an approved Payment Provider.

Is Midtrans part of Commerce?

Midtrans can be a Payment Provider adapter. It does not own the Commerce Order.

Can MICROBA add Stripe or another provider later?

Yes. Providers are adapters behind a common Commerce interface.

Is COD considered paid immediately when selected?

No.

What is the COD lifecycle?

The canonical model is awaiting_collection → collected → verified → paid.

Is Manual Accounting Adjustment the same as COD?

No.

Can an Admin simply mark anything as paid?

Manual adjustments should be restricted, justified, approved where required, and audited.

Can I use SA in Commerce?

Yes, for eligible transactions.

Can I use 100% SA?

The current architecture permits eligible fully SA-funded purchases.

If cash due is zero, is there still an Order?

Yes.

Does Commerce create SA?

No. The SA system owns entitlement and serial issuance.

Does Commerce calculate HIVE relationships?

No. HIVE owns Direct Sponsor relationships.

What does Commerce provide to HIVE?

Authoritative commercial and eligible-sales information.

What does Commerce provide to SA?

Authoritative sales information and transaction context needed for provision, entitlement, usage, and reconciliation.

What is the current SA provision reference?

3% of eligible sales.

What is the current SA reference value?

Rp30,000 per SA.

What is the current HIVE rate?

9% of eligible direct sponsored sales.

Does a purchase without a sponsor fail?

No.

What happens to HIVE commission if there is no sponsor?

No direct sponsorship commission is created.

Are refunds deleted from history?

No. Refunds and reversals are explicit transactions.

Can the same webhook create two commissions?

It should not. Commerce and downstream engines must use idempotent processing and deduplication.

What happens if an event is delivered twice?

The receiving capability should recognize the event identity and avoid duplicate economic effects.

Does Commerce replace formal accounting?

No. Commerce records commercial truth; formal accounting may be handled by a dedicated financial/accounting capability.

Why does Commerce need reconciliation?

To detect mismatches between Orders, providers, refunds, HIVE, SA, Treasury, and downstream processing.

Can a member view another member's Order by guessing the Order ID?

No. Access requires authorization.

What happens if a payment provider fails?

Commerce preserves a controlled state and supports safe retry or another approved recovery path.

Is the eligible-sales formula for SA-funded purchases final?

The architecture is final enough to support SA-funded transactions, but the exact downstream eligible-sales basis must be explicitly locked in the financial specification before public implementation.

7.67 Chapter Summary

Commerce is the commercial backbone of MICROBA.

The core rules are:

• source capabilities create Commercial Requests;
• Commerce creates and owns canonical Orders;
• Commerce preserves the committed commercial snapshot;
• the browser is never the authority for protected commercial values;
• Cart and Checkout are combined in the current low-item-volume

journey;

• the Payment Page securely loads an existing Order;
• Commerce owns Payment Intents and payment lifecycle;
• Payment Providers are adapters behind a common interface;
• Midtrans, Stripe, Xendit, HitPay, PayPal, COD, Wallet, Bank

Transfer, and future providers can coexist without changing Commerce core;

• COD is not paid immediately on selection;
• Manual Accounting Adjustment is separate from COD;
• SA may fund part or all of an eligible Order;
• a zero-cash fully SA-funded purchase remains a Commerce transaction;
• Commerce provides authoritative sales facts to HIVE and SA;
• the current HIVE reference is 9% of eligible direct sponsored sales;
• the current SA provision reference is 3% of eligible sales;
• the current SA reference value is Rp30,000;
• Treasury recycling occurs before new SA minting;
• refunds and corrections use explicit reversals rather than silent

deletion;

• cross-engine consistency uses immutable events, idempotency,

transactional outbox, deduplicated inbox, process managers, and reconciliation;

• Commerce does not use distributed transactions across independent

engines;

• Commerce records commercial truth but does not replace formal

accounting; and

• the operational interface should turn complex backend reconciliation

into simple understandable numbers.

7.68 Source-of-Truth Note

This chapter is the general source of truth for MICROBA Commerce behaviour.

Commerce owns Orders, committed commercial snapshots, Payment Intents, payment-provider orchestration, commercial transactions, receipts, refunds, commercial status, and commercial events.

Product and other source capabilities own what is being offered. Membership/Profile owns identity. HIVE owns Direct Sponsor relationships and sponsorship rules. SA owns provision, entitlement, serial identity, Treasury circulation, transfers, redemption, and recycling.

One important financial rule remains intentionally marked for explicit finalization: the precise eligible-sales basis used for HIVE and new SA provision when an Order is partly or fully funded with SA or other discounts. That rule must be locked before financial implementation rather than inferred by developers or AI.

Public wording, accounting terminology, provider availability, dashboard labels, and interface presentation may be refined without changing the underlying Commerce architecture unless an approved architecture revision is made.