Business Processes

MUWE transactions are initiated from the terminal dimension. A terminal is a customer-owned physical device, POS application, cashier workstation, or logical integration endpoint that has developer capability and is activated into MUWE before it can send transaction requests.

Customer terminal

1Activate own terminal

Use the onboarding activation code to register the customer's terminal with MUWE.

2Check in

Rotate the terminal key before transaction processing.

Merchant operation

3Create transaction

Start a pay, QR, or MIS-to-POS order from a terminal identity.

4Consumer pays

Complete payment through the configured provider or POS flow.

Recovery and reconciliation

5Resolve result

Use notification and query to reach a final state.

6Reverse if needed

Cancel, refund, or revoke according to order state and provider capability.

Terminal Activation

Terminal activation is not activation of a MUWE-owned terminal. It is the process where a developer-capable customer activates its own terminal into the MUWE system. The activated terminal receives a MUWE terminal identity, and later transactions are initiated from that terminal dimension.

1. The partner or customer receives vendor_sn, vendor_key, app_id, and activation codes through onboarding.
2. The customer's terminal calls POST /terminal/activate, signed with vendor_sn and vendor_key.
3. MUWE validates the activation code, store scope, application, and terminal metadata.
4. MUWE returns terminal_sn and terminal_key.
5. The customer terminal stores both values securely and uses them for check-in and transaction requests.

Activation codes belong to stores, have usage limits, and can expire. A multi-use activation code creates a new MUWE terminal identity for every successful customer terminal activation.

Terminal Check-in

Check-in rotates the terminal key and limits the useful lifetime of a leaked key.

1. The customer terminal signs POST /terminal/checkin with the current terminal_sn and terminal_key.
2. MUWE returns a fresh terminal_key.
3. The client replaces the stored key only after a successful response.
4. After check-in, only the current and previous keys are valid.

Check in at least once per day and before the first transaction of the day.

Transactions

Transaction APIs are signed with terminal_sn and terminal_key. The merchant system can be a POS device, cashier application, MIS, or another customer terminal that was activated into MUWE.

Merchant-initiated paymentPOST /upay/v2/pay

The merchant starts a payment request from an activated terminal, and the consumer completes payment through the configured provider flow.

QR paymentPOST /upay/v2/precreate

The merchant creates an order and displays a QR code or payment URL. The final payment result arrives later by notification or query.

MIS-to-POS order pushPartner integration

Merchant MIS creates an order and pushes it to a bound POS terminal, where the consumer-facing payment flow is completed.

QueryPOST /upay/v2/query

Resolve uncertain results and fetch the latest order state before delivery or replacement actions.

RefundPOST /upay/v2/refund

Refund a paid order, including multiple partial refunds identified by `refund_request_no`.

Cancel / Revoke/cancel and /revoke

Cancel unpaid or uncertain orders; revoke same-day paid orders only when the provider supports it.

MUWE supports MIS-to-POS order push scenarios in the same transaction lifecycle. A merchant MIS or cashier system can create an order, send it to a bound POS terminal, complete the consumer-facing payment flow on the POS, and then use notification or query to reconcile the final result.

The client must treat network timeouts and *_IN_PROGRESS business results as uncertain. Query before showing final success or creating a replacement order.