Glossary
The first half is the official DaxPay external vocabulary (menus, ops UI, and integration docs should follow it).
The second half is industry-general terminology. On conflict, prefer the DaxPay vocabulary.
DaxPay External Vocabulary
Provider vs Channel
| Term | Side | One-liner |
|---|---|---|
| Pay Provider (支付渠道) | Payer (C-end) | Which wallet the money comes from (WeChat, Alipay, …) |
| Payment Channel (支付通道) | Integration (B-end) | Which institution you integrate with (WeChat Pay, Lakala, UMS, …) |
Do not mix the two: 渠道 = C-end brand; 通道 = B-end integration.
Core Entities
| Term | Code / Field | Description |
|---|---|---|
| Merchant | Merchant / mchNo | Tenant that accepts payments via DaxPay. |
| Merchant App | MchApp / appId | App under a merchant; channel routing, aggregate pay, and cashier hang on the app. |
| Pay Provider | PayProvider / provider | C-end wallet/brand: WeChat, Alipay, UnionPay, Douyin, … |
| Pay Method | PayMethod / method | How the user pays: QR, JSAPI, mini-program, H5, barcode, … Each method belongs to one provider. |
| Payment Channel | Channel / channel | B-end institution you integrate with. |
| Payment Product | Product / product | Integration flavor under a channel (e.g. WeChat direct vs ISV). One channel may have many products. |
| Pay Capability | Capability / capability | Concrete launch shape a product supports; often aligned with method but defined by product strategy. Prefer auto-infer on config UI when possible. |
| Channel Merchant | ChannelMerchant / channelMchNo | Onboarding entity under a product; uniquely binds one product; the anchor of the pay path. |
| Channel-side App Config | Channel app (WeChat/Alipay AppId, …) | Channel-side app credentials — not merchant appId. |
Pay Path (Channel Routing)
| Term | Code / Field | Description |
|---|---|---|
| Channel Routing / Channel Binding (通道路由) | PayRoute | Per merchant app, map provider/method to a channel merchant (then product + capability). Deterministic binding, not cost/success-rate multi-candidate routing. |
| By Brand Default | mode = basic | One default channel merchant per pay provider; capability from product strategy. Legacy name: basic mode. |
| By Method | mode = scene | Channel merchant + capability per pay method. Legacy name: scene mode — not scan/cashier environment. |
| Specify Directly (直接指定) | channelMchNo + capability on request | Skip app routing; use the given channel merchant and capability. Full phrasing: “directly specify channel merchant”. Legacy: direct / precise / explicit channel merchant. |
| Follow Channel Routing | Aggregate AUTO, etc. | Resolve via the app’s channel routing. |
Merchant → App (appId)
├─ Channel routing: provider/method → channel merchant (→ product) → capability
├─ Aggregate / cashier (follow routing or specify directly)
└─ Async notify, …
Pay request method (or specify channelMchNo directly)
→ product + channelMchNo + capability
→ channel implementationGateway & UI
| Term | Description |
|---|---|
| Aggregate Pay | One QR / entry for multiple wallets; derive or configure method, then resolve channel merchant. |
| QR Terminal (码牌) | Physical/digital collection QR asset; scan rules often tied to aggregate config. |
| Cashier | End-user cashier page and payment items. |
| Open Environment | WeChat / Alipay / browser context when the user opens the page. |
Credentials & Notify
| Term | Description |
|---|---|
| API Credentials (对接配置) | Merchant open-API keys, sign verify, crypto. |
| Async Notify Config | Business webhook URL and event subscriptions (not system announcements). |
| Store | Merchant offline store. |
vs Industry “Channel Routing”
Industry “channel routing” often means picking the best of several channels by success rate, cost, amount, etc.
DaxPay “channel routing” is 1:1 path binding per app (by brand default or by method). It does not include weighted failover.
Transactions
| Term | Description |
|---|---|
| Payment | The user transfers funds to the payee via an online payment system |
| Refund | The payment system returns money to the user (full or partial) |
| Cancel/Void | Cancelling a transaction on the same day (before cutoff), usually with fee refund |
| Force Reversal | Similar to cancel, originating from POS-era cancellation of timeout transactions |
| Escrow Payment | The buyer pays to the platform first and the merchant receives funds after delivery confirmation |
| Instant Settlement | Funds are transferred directly to the payee without secondary confirmation |
Funds
| Term | Description |
|---|---|
| Topup | Adding funds to a payment system account |
| Transfer | Moving funds from one account to another |
| Withdraw | Withdrawing account balance to a bank card |
| Payroll Disbursement | A company transfers funds directly to individual accounts via the payment system |
| T Day | The actual date a transaction occurs |
| T+N | The N-th business day after the transaction date |
| Accounting Day | The date identifying a transaction in accounting terms — may differ from calendar date |
| Day Cut | Accounting day switches to the next, triggering batch processing |
| Settlement | The acquirer transfers transaction funds to the merchant |
| Clearing | Transfer of transaction funds between institutions |
| Netting | Offsetting daily receivables and payables, transferring only the net amount |
| Fee Recording | Recording and summarizing transaction fees |
| Service Fee | Fees charged for transaction processing or services |
| Capital Loss | Financial loss caused by errors |
Payment Forms (Industry)
| Term | Description |
|---|---|
| Quick Payment | Pre-binding bank card information for fast subsequent payments |
| Direct Debit | Individual authorization for merchants to deduct funds directly |
| Card Payment | Payment using credit or debit cards |
| Online Banking | Redirecting to a bank payment page |
| QR Code Payment | Initiating payment via QR codes |
| Merchant Scan | Merchant generates a QR code for the user to scan |
| Consumer Scan | User generates a QR code for the merchant to scan |
| Aggregated QR | One QR code supporting multiple wallets |
Merchants & Accounts
| Term | Description |
|---|---|
| Merchant Onboarding | Entering the payment system by submitting documents and signing agreements |
| Member | An individual who joins a payment financial institution |
| Limit | Maximum amount allowed within a time period |
| Freeze/Unfreeze | Suspending/restoring account transactions or balance |
| KYC | Know Your Customer — verifying customer identity |
| Binding / Unbinding | Bind or unbind bank cards or third-party wallets |
Accounting
| Term | Description |
|---|---|
| Bookkeeping | Recording transactions in accounting ledgers |
| Double-Entry Bookkeeping | At least two account movements with equal debit and credit |
| Account | A ledger for specific types of financial transactions |
| Account Subject | Classified items in accounting books |
| Journal Entry | Recording method specifying debit and credit |
| Internal Account | Not customer-facing; internal fund management |
| Intermediate Account | Temporary bookkeeping account |
| Position | Balance situation |
Risk & Compliance
| Term | Description |
|---|---|
| Risk Control | Fraud detection, credit assessment, compliance checks, etc. |
| AML | Anti-Money Laundering |
| Anti-Fraud | Preventing and detecting fraud |
| Regulation & Compliance | Complying with laws and industry standards |
Interaction & Systems
| Term | Description |
|---|---|
| Information Flow | Non-fund-related data during transactions |
| Fund Flow | Movement of funds (virtual or actual) |
| API Interface | Real-time protocols between systems |
| File Interface | Data exchange via files |
Subsystem Categories (Industry Reference)
| Term | Description |
|---|---|
| Open Gateway | Merchant-facing entry (orders/payments) |
| Acquiring & Settlement | Collect orders and settle |
| Cashier Core | Renders available payment methods |
| Payment Engine | Actual deduction or transfer |
| Channel Gateway | Industry term; map to DaxPay channel / channel routing |
| Member / Merchant / Risk / Ops platforms | Supporting platforms |