Admin Portal — Operator Manualคู่มือปฏิบัติงานสำหรับผู้ดูแลแพลตฟอร์ม
Platform operations, risk and compliance staff. This manual is for the P2P platform operations, risk, and compliance team — the staff who run the admin console at /admin behind mandatory two-factor auth. From here you triage the work queues (slip reviews, bank-account and fulfillment approvals), manage merchants and resellers, watch platform billing and webhooks, and take account-safety actions on users. Every screen is RBAC-gated, so your role decides which of these you actually see; some panels below (SUPER_ADMIN tools, billing) will be hidden if your role lacks the permission. Note that approving a withdrawal is NOT an admin task — approved withdrawals auto-enter the matching engine, and your only withdrawal-adjacent surface is manual platform fulfillment.ทีมปฏิบัติการ ความเสี่ยง และการกำกับดูแลของแพลตฟอร์ม คู่มือนี้สำหรับทีมปฏิบัติการ ความเสี่ยง และการกำกับดูแลของแพลตฟอร์ม P2P — เจ้าหน้าที่ที่ใช้งานคอนโซลผู้ดูแลที่ /admin ซึ่งบังคับยืนยันตัวตนสองชั้น จากที่นี่คุณจัดลำดับงานในคิวต่าง ๆ (การตรวจสอบสลิป การอนุมัติบัญชีธนาคารและการจ่ายเงิน) บริหารร้านค้าและรีเซลเลอร์ ติดตามการเรียกเก็บเงินและเว็บฮุกของแพลตฟอร์ม และดำเนินมาตรการด้านความปลอดภัยกับบัญชีผู้ใช้ ทุกหน้าจอถูกควบคุมด้วยสิทธิ์ตามบทบาท ดังนั้นบทบาทของคุณจะเป็นตัวกำหนดว่าคุณเห็นหน้าจอใดบ้าง บางแผงด้านล่าง (เครื่องมือของผู้ดูแลระดับสูงสุด และการเรียกเก็บเงิน) จะถูกซ่อนหากบทบาทของคุณไม่มีสิทธิ์ ข้อควรทราบ: การอนุมัติคำขอถอนไม่ใช่งานของผู้ดูแล — คำขอถอนที่อนุมัติแล้วจะเข้าสู่ระบบจับคู่โดยอัตโนมัติ หน้าจอเดียวที่เกี่ยวกับการถอนสำหรับคุณคือการจ่ายเงินด้วยมือในนามแพลตฟอร์ม
This Thai text is an unreviewed draft. A native reviewer should read it before it is published outside the team.
The platform at a glanceภาพรวมของแพลตฟอร์ม
Where you start, and how throughput is trending.จุดเริ่มต้นของงาน และแนวโน้มปริมาณธุรกรรม
Step 1ขั้นตอนที่ 1
Operations dashboardแดชบอร์ดปฏิบัติการ
Your landing screen and daily starting point. At the top sits a load-isolated deposit-and-withdrawal flow-analytics panel (ADR-0109) — platform-wide throughput read from a pre-aggregated hourly rollup, with KPI tiles, a deposits-vs-withdrawals bar chart, a 30-minute SLA gauge and a status-mix donut — and below it live queue depths (slips, bank-account verifications, fulfillments awaiting action), a last-24-hours activity summary, and any system alerts plus service-health indicators. Scan the queue KPIs first each shift and jump into whichever queue is backing up; remember withdrawal approval is not here — approved withdrawals flow straight into matching.หน้าจอแรกและจุดเริ่มต้นประจำวันของคุณ ด้านบนคือแผงวิเคราะห์กระแสการฝาก-ถอนที่แยกภาระออกจากระบบหลัก (ADR-0109) — ปริมาณงานทั้งแพลตฟอร์ม อ่านจากข้อมูลสรุปรายชั่วโมงที่คำนวณไว้ล่วงหน้า พร้อมการ์ดตัวชี้วัด กราฟแท่งเปรียบเทียบฝากกับถอน มาตรวัดระดับบริการ 30 นาที และโดนัทสัดส่วนสถานะ — ด้านล่างเป็นความลึกของคิวแบบสด (สลิป การยืนยันบัญชีธนาคาร รายการที่รอจ่าย) สรุปกิจกรรม 24 ชั่วโมงล่าสุด พร้อมการแจ้งเตือนระบบและสถานะความพร้อมของบริการ เริ่มกะงานด้วยการกวาดสายตาดูตัวชี้วัดคิวก่อน แล้วเข้าไปจัดการคิวที่กำลังค้าง อย่าลืมว่าการอนุมัติคำขอถอนไม่ได้อยู่ที่นี่ — คำขอที่อนุมัติแล้วจะไหลเข้าระบบจับคู่โดยตรง
Step 2ขั้นตอนที่ 2
Deposit & withdrawal flow analyticsวิเคราะห์กระแสการฝากและถอน
The load-isolated flow-analytics panel at the top of the dashboard (ADR-0109): platform-wide deposit and withdrawal throughput read from a pre-aggregated hourly rollup, never a live query. A date-range control (Today / 7d / 30d or a custom range) drives four KPI tiles (deposits, withdrawals, stale items, average fulfilment time), a deposits-vs-withdrawals bar chart with a count/volume toggle, a 'settled under 30 min' SLA gauge, a status-mix donut, and a per-bucket table with CSV export. A 'data as of' watermark shows how fresh the rollup is. This step widens the range to 30 days so the charts show a fuller picture.แผงวิเคราะห์กระแสที่แยกภาระออกจากระบบหลัก อยู่บนสุดของแดชบอร์ด (ADR-0109): ปริมาณการฝากและถอนทั้งแพลตฟอร์ม อ่านจากข้อมูลสรุปรายชั่วโมงที่คำนวณไว้ล่วงหน้า ไม่ใช่การสอบถามข้อมูลสด ตัวเลือกช่วงวันที่ (วันนี้ / 7 วัน / 30 วัน หรือกำหนดเอง) ขับเคลื่อนการ์ดตัวชี้วัดสี่ใบ (ยอดฝาก ยอดถอน รายการค้างนาน และเวลาเฉลี่ยในการดำเนินการ) กราฟแท่งฝากเทียบถอนพร้อมปุ่มสลับจำนวนรายการกับมูลค่า มาตรวัด “ดำเนินการเสร็จภายใน 30 นาที” โดนัทสัดส่วนสถานะ และตารางแยกช่วงเวลาที่ส่งออกเป็น CSV ได้ มีข้อความกำกับว่าข้อมูลอัปเดตล่าสุดเมื่อใด ขั้นตอนนี้ขยายช่วงเวลาเป็น 30 วันเพื่อให้เห็นภาพกว้างขึ้น
Merchants and resellersร้านค้าและรีเซลเลอร์
Who is on the platform, and every setting that governs them.ใครอยู่บนแพลตฟอร์มบ้าง และการตั้งค่าทั้งหมดที่ควบคุมพวกเขา
Step 3ขั้นตอนที่ 3
Merchants listรายชื่อร้านค้า
The directory of partner businesses integrated with the platform, with their status and slug. Use it to find a merchant to inspect or configure, or to reach the create-merchant form. Click any row to open that merchant's detail tabs.ทำเนียบธุรกิจพันธมิตรที่เชื่อมต่อกับแพลตฟอร์ม พร้อมสถานะและรหัสย่อ ใช้ค้นหาร้านค้าที่ต้องการตรวจสอบหรือตั้งค่า หรือใช้เข้าสู่แบบฟอร์มสร้างร้านค้าใหม่ คลิกแถวใดก็ได้เพื่อเปิดแท็บรายละเอียดของร้านค้ารายนั้น
Step 4ขั้นตอนที่ 4
Merchant detail (tabs)รายละเอียดร้านค้า (แท็บต่าง ๆ)
The full control surface for one merchant, organised into tabs: Profile, Matching & risk, Billing, Sub-merchants, Bank, Staff & security, Users, and Transactions. From here you edit merchant settings, rotate the API key and HMAC secret, record DPA acceptance, invite staff, tune denominations, reservation-expiry, credit-check and slip-fallback toggles, flip the two sub-merchant gates, manage the merchant's sub-merchants, and view its users and transactions. Most write actions on these tabs require the MANAGE_MERCHANTS permission.แผงควบคุมเต็มรูปแบบของร้านค้าหนึ่งราย จัดเป็นแท็บ: โปรไฟล์ การจับคู่และความเสี่ยง การเรียกเก็บเงิน ร้านค้าย่อย ธนาคาร พนักงานและความปลอดภัย ลูกค้า และรายการธุรกรรม จากที่นี่คุณแก้ไขการตั้งค่าร้านค้า หมุนเปลี่ยนกุญแจ API และรหัสลับ HMAC บันทึกการยอมรับข้อตกลงคุ้มครองข้อมูล เชิญพนักงาน ปรับจำนวนเงินที่รองรับ ช่วงหมดอายุการจอง ตัวควบคุมการตรวจสอบเครดิตและการสำรองการตรวจสลิป เปิดปิดตัวควบคุมร้านค้าย่อยสองรายการ จัดการร้านค้าย่อยของร้านค้ารายนั้น และดูลูกค้ากับรายการธุรกรรมของเขา การกระทำที่เป็นการแก้ไขบนแท็บเหล่านี้ส่วนใหญ่ต้องมีสิทธิ์จัดการร้านค้า
Step 5ขั้นตอนที่ 5
Merchant detail — Sub-merchants tabรายละเอียดร้านค้า — แท็บร้านค้าย่อย
The Sub-merchants tab of a merchant's detail page. It lists the merchant's sub-merchants (external code, display name, status, usage-credit balance) with a create form, and a per-row Manage panel that lets you allocate or deallocate usage credit, grant or claw back the sub-merchant's withdraw-allowance balance (the plane, separate from usage credit, that the withdraw-allowance gate meters against), rename, and suspend / reactivate / deactivate it. This is the admin-side companion to the merchant owner's own sub-merchant management.แท็บร้านค้าย่อยในหน้ารายละเอียดของร้านค้า แสดงรายชื่อร้านค้าย่อยของร้านค้ารายนั้น (รหัสอ้างอิงภายนอก ชื่อที่แสดง สถานะ ยอดเครดิตการใช้งาน) พร้อมแบบฟอร์มสร้างใหม่ และแผงจัดการรายแถวที่ให้คุณจัดสรรหรือดึงคืนเครดิตการใช้งาน เพิ่มหรือเรียกคืนยอดวงเงินถอนของร้านค้าย่อย (ซึ่งเป็นคนละส่วนกับเครดิตการใช้งาน และเป็นยอดที่ตัวควบคุมวงเงินถอนใช้วัด) เปลี่ยนชื่อ รวมถึงระงับ เปิดใช้งานใหม่ หรือปิดใช้งาน นี่คือหน้าจอฝั่งผู้ดูแลที่คู่กับการจัดการร้านค้าย่อยของเจ้าของร้านค้าเอง
Step 6ขั้นตอนที่ 6
Merchant detail — Matching & risk (sub-merchant gates)รายละเอียดร้านค้า — การจับคู่และความเสี่ยง (ตัวควบคุมร้านค้าย่อย)
The Matching & risk tab, home of the two opt-in per-merchant sub-merchant gates (migration 0180, ADR-0104). 'Sub-merchant match isolation' — when ON, a sub-merchant's withdrawals only match deposits from the same sub-merchant (status Isolated vs Shared pool). 'Sub-merchant withdraw allowance limit' — when ON, a sub-merchant can only withdraw up to its separately-funded withdraw-allowance balance (status Allowance enforced vs No limit). Both default OFF. This tab also carries the merchant's other matching and risk toggles.แท็บการจับคู่และความเสี่ยง เป็นที่อยู่ของตัวควบคุมร้านค้าย่อยสองรายการที่เปิดใช้เองต่อร้านค้า (migration 0180, ADR-0104) “การแยกการจับคู่ของร้านค้าย่อย” — เมื่อเปิด คำขอถอนของร้านค้าย่อยจะจับคู่ได้เฉพาะกับรายการฝากของร้านค้าย่อยเดียวกัน (สถานะ: แยกอิสระ หรือใช้กองกลางร่วมกัน) “การจำกัดวงเงินถอนของร้านค้าย่อย” — เมื่อเปิด ร้านค้าย่อยถอนได้ไม่เกินยอดวงเงินถอนที่เติมไว้แยกต่างหาก (สถานะ: บังคับใช้วงเงิน หรือไม่จำกัด) ทั้งสองปิดอยู่โดยค่าเริ่มต้น แท็บนี้ยังรวมตัวควบคุมด้านการจับคู่และความเสี่ยงอื่น ๆ ของร้านค้าไว้ด้วย
Step 7ขั้นตอนที่ 7
Resellers listรายชื่อรีเซลเลอร์
Partner resellers who manage merchant accounts under the platform's white-label programme. Use it to locate a reseller, review its assigned merchants and MDR sharing, or reach the create-reseller form. Click a row to open that reseller's detail page.รีเซลเลอร์พันธมิตรที่ดูแลบัญชีร้านค้าภายใต้โครงการไวท์เลเบลของแพลตฟอร์ม ใช้ค้นหารีเซลเลอร์ ตรวจสอบร้านค้าในสังกัดและการแบ่งส่วนแบ่ง MDR หรือเข้าสู่แบบฟอร์มสร้างรีเซลเลอร์ใหม่ คลิกแถวเพื่อเปิดหน้ารายละเอียดของรีเซลเลอร์รายนั้น
Step 8ขั้นตอนที่ 8
Reseller detailรายละเอียดรีเซลเลอร์
The management page for one reseller: its base rates, assigned merchants, MDR share-of-spread per merchant, and portal users (owner, staff co-owners, MDR sub-users). Reset a reseller user's password here to issue a one-time temp password, clear their TOTP and sign them out everywhere — including the founding owner the reseller portal itself cannot reset.หน้าจัดการรีเซลเลอร์หนึ่งราย: อัตราค่าฐาน ร้านค้าในสังกัด ส่วนแบ่งของส่วนต่างที่มอบให้ MDR แยกรายร้านค้า และผู้ใช้ในพอร์ทัล (เจ้าของ พนักงานเจ้าของร่วม และผู้ใช้ช่วง MDR) รีเซ็ตรหัสผ่านของผู้ใช้รีเซลเลอร์ได้จากที่นี่ ซึ่งจะออกรหัสผ่านชั่วคราวแบบใช้ครั้งเดียว ล้างการตั้งค่า TOTP และบังคับออกจากระบบทุกอุปกรณ์ — รวมถึงบัญชีเจ้าของผู้ก่อตั้งที่พอร์ทัลรีเซลเลอร์เองรีเซ็ตไม่ได้
Slip review — the decisionsการตรวจสอบสลิป — การตัดสินใจ
The queue is the job. Three keyed sources, three decision screens; an over-payment is the one that needs you rather than the merchant.คิวคืองานหลัก มีสามแหล่งที่มา สามหน้าจอตัดสินใจ และการโอนเกินคือกรณีที่ต้องใช้คุณ ไม่ใช่ร้านค้า
Step 9ขั้นตอนที่ 9
Slip-review queue (landing)คิวตรวจสอบสลิป (หน้าหลัก)
The heart of your daily triage: deposits whose slip could not be auto-verified and now await an admin decision. It groups pending items into three keyed sections — match-keyed reviews, reservation-keyed reviews (merchant-API), and deposit-leg reviews. Work items top-down; opening any item takes you to its decision screen.หัวใจของการจัดลำดับงานประจำวัน: รายการฝากที่สลิปไม่ผ่านการตรวจสอบอัตโนมัติและรอการตัดสินจากผู้ดูแล หน้านี้จัดกลุ่มงานที่รออยู่เป็นสามส่วนตามแหล่งที่มา — การตรวจสอบที่ผูกกับการจับคู่ ที่ผูกกับการจองเงิน (จาก API ร้านค้า) และที่ผูกกับรายการฝากแบบแบ่ง ทำงานไล่จากบนลงล่าง การเปิดรายการใดก็ตามจะพาไปยังหน้าจอตัดสินใจของรายการนั้น
Step 10ขั้นตอนที่ 10
Resolve — reservation review (an over-payment)ตัดสิน — การตรวจสอบการจองเงิน (กรณีโอนเกิน)
The decision screen for a merchant-API reservation whose slip failed verification. It shows the destination, receiver and sender account triad and the slip image; there is deliberately no plain Approve for a reservation — a valid slip settles by itself, so your action is normally Reject, which releases the matched seller's reserved amount and returns the reservation to the pool. The row shown here is the commonest exception: the customer transferred MORE than they reserved, which cannot be fixed by re-uploading, so it arrives with an explicit approve-and-credit dialog alongside Cancel. Merchant staff see the same decision on their own queue — you are the escalation path, not the only path.หน้าจอตัดสินสำหรับการจองเงินฝากผ่าน API ร้านค้าที่สลิปไม่ผ่านการตรวจสอบ แสดงบัญชีปลายทาง บัญชีผู้รับ และบัญชีผู้โอน เทียบกันสามส่วน พร้อมภาพสลิป โดยเจตนาแล้วจะไม่มีปุ่มอนุมัติธรรมดาสำหรับการจองเงิน เพราะสลิปที่ถูกต้องจะตัดบัญชีได้เอง การกระทำปกติของคุณคือปฏิเสธ ซึ่งจะปลดยอดที่กันไว้ของผู้ขายที่จับคู่ได้ และคืนการจองกลับสู่กองกลาง แถวที่แสดงในภาพคือข้อยกเว้นที่พบบ่อยที่สุด: ลูกค้าโอนเงินมามากกว่าที่จองไว้ ซึ่งแก้ด้วยการอัปโหลดใหม่ไม่ได้ จึงมาพร้อมกล่องยืนยันอนุมัติและเติมเครดิตคู่กับปุ่มยกเลิก พนักงานร้านค้าเห็นการตัดสินเดียวกันนี้ในคิวของเขาเช่นกัน — คุณคือช่องทางยกระดับปัญหา ไม่ใช่ช่องทางเดียว
Step 11ขั้นตอนที่ 11
Resolve — deposit-leg reviewตัดสิน — การตรวจสอบรายการฝากแบบแบ่ง
The decision screen for a single deposit leg whose slip failed. Approve confirms the slip is valid for the typed amount; Reject discards it, and for source=MATCH legs the counterparty's reserved_satang is released back to matching. Use the receiver/sender comparison to confirm the money actually landed in the right account before you approve.หน้าจอตัดสินสำหรับรายการฝากแบบแบ่งหนึ่งรายการที่สลิปไม่ผ่าน การอนุมัติคือการยืนยันว่าสลิปถูกต้องตามจำนวนที่คุณกรอก การปฏิเสธคือการทิ้งรายการนั้น และสำหรับรายการที่มาจากการจับคู่ ยอดที่กันไว้ของคู่สัญญาจะถูกปลดคืนสู่ระบบจับคู่ ใช้การเทียบข้อมูลผู้รับกับผู้โอนเพื่อยืนยันว่าเงินเข้าบัญชีที่ถูกต้องจริงก่อนกดอนุมัติ
Step 12ขั้นตอนที่ 12
Resolve — match reviewตัดสิน — การตรวจสอบการจับคู่
The decision screen for a match-keyed slip review, showing the full verification-attempt history for that match. Approve credits and progresses the match; Reject sends it back. This is where platform P2P matches (as opposed to merchant reservations/legs) that failed auto-verification are cleared by hand.หน้าจอตัดสินสำหรับการตรวจสอบสลิปที่ผูกกับการจับคู่ แสดงประวัติความพยายามตรวจสอบทั้งหมดของการจับคู่นั้น การอนุมัติจะเติมเครดิตและเดินหน้าการจับคู่ต่อ ส่วนการปฏิเสธจะส่งกลับ นี่คือที่ที่การจับคู่ P2P ของแพลตฟอร์ม (ต่างจากการจองเงินหรือรายการแบ่งของร้านค้า) ซึ่งไม่ผ่านการตรวจสอบอัตโนมัติ จะถูกสะสางด้วยมือ
Bank accounts and gatewaysบัญชีธนาคารและเกตเวย์
Verification, gateway credentials, and deposits the gateway never confirmed.การยืนยันบัญชี ข้อมูลรับรองเกตเวย์ และรายการฝากที่เกตเวย์ไม่เคยยืนยัน
Step 13ขั้นตอนที่ 13
Bank-account verification queueคิวยืนยันบัญชีธนาคาร
User bank accounts awaiting manual verification before their owner can receive withdrawal payouts. Review each submission's details and Verify or Reject it. Clearing this queue keeps withdrawals flowing, since an unverified destination account blocks payout unless the merchant has auto-approve enabled.บัญชีธนาคารของผู้ใช้ที่รอการยืนยันด้วยมือ ก่อนที่เจ้าของบัญชีจะรับเงินถอนได้ ตรวจสอบรายละเอียดของแต่ละคำขอแล้วกดยืนยันหรือปฏิเสธ การเคลียร์คิวนี้ทำให้การถอนเงินไหลลื่น เพราะบัญชีปลายทางที่ยังไม่ยืนยันจะขวางการจ่ายเงิน เว้นแต่ร้านค้าจะเปิดการอนุมัติอัตโนมัติไว้
Step 14ขั้นตอนที่ 14
Payment gatewaysเกตเวย์ชำระเงิน
Manage the PGWay API credentials used for virtual-account (gateway) deposit routing; credentials are AES-256-GCM encrypted at rest. From here you provision a new credential, test the connection, rotate secrets, and activate or deactivate a credential. A gateway credential must be active and coupled to a routing bank-account row for gateway deposits to work.จัดการข้อมูลรับรอง API ของ PGWay ที่ใช้ส่งการฝากเงินผ่านบัญชีเสมือน (เกตเวย์) ข้อมูลรับรองถูกเข้ารหัส AES-256-GCM ขณะจัดเก็บ จากที่นี่คุณเพิ่มข้อมูลรับรองใหม่ ทดสอบการเชื่อมต่อ หมุนเปลี่ยนรหัสลับ และเปิดหรือปิดการใช้งานได้ ข้อมูลรับรองเกตเวย์ต้องอยู่ในสถานะใช้งานและผูกกับแถวบัญชีธนาคารสำหรับส่งเงิน จึงจะรับฝากผ่านเกตเวย์ได้
Step 15ขั้นตอนที่ 15
Gateway reconciliationการกระทบยอดเกตเวย์
Deposits credited on our side via the manual-slip fallback but never confirmed 'success' at the payment gateway — the 'hanging' gateway deposits (migration 0179). Each row shows the claimant (sub-merchant and parent merchant), the gateway account, the credited amount, the gateway status, and copyable gateway-transaction UUID and merchant-order id. Check each against the provider, then Confirm it or Flag it with a reason. This is tracking-only — recording a reconciliation moves no money; the deposit stays credited and settle-able. A 'Pending only' filter hides already-reconciled rows.รายการฝากที่ถูกเครดิตในระบบเราผ่านช่องทางสำรองด้วยสลิป แต่เกตเวย์ไม่เคยยืนยันว่า “สำเร็จ” — คือรายการฝากผ่านเกตเวย์ที่ค้างอยู่ (migration 0179) แต่ละแถวแสดงผู้รับเงิน (ร้านค้าย่อยและร้านค้าแม่) บัญชีเกตเวย์ ยอดที่เครดิตไป สถานะฝั่งเกตเวย์ และรหัสธุรกรรมเกตเวย์กับรหัสคำสั่งของร้านค้าที่คัดลอกได้ ตรวจสอบแต่ละรายการกับผู้ให้บริการ แล้วกดยืนยันหรือทำเครื่องหมายพร้อมระบุเหตุผล หน้านี้เป็นการติดตามเท่านั้น — การบันทึกการกระทบยอดไม่ได้เคลื่อนย้ายเงิน รายการฝากยังคงถูกเครดิตและชำระบัญชีได้ตามปกติ ตัวกรอง “เฉพาะที่รอดำเนินการ” จะซ่อนแถวที่กระทบยอดแล้ว
Step 16ขั้นตอนที่ 16
Gateway reconciliation — inline slipการกระทบยอดเกตเวย์ — ดูสลิปในแถว
Opening a row's evidence inline fetches a fresh signed image URL and renders the transfer slip directly beneath the row (no new tab), so you can eyeball the proof next to the copyable gateway transaction id and the exact amount the gateway quoted before deciding whether to Confirm or Flag. The row shown here is a deposit credited on our side from an uploaded slip while the gateway never reported it 'success' — precisely the case this queue exists for.การกางหลักฐานของแถวจะดึงลิงก์ภาพที่ลงลายเซ็นใหม่และแสดงสลิปการโอนไว้ใต้แถวนั้นเลย (ไม่เปิดแท็บใหม่) คุณจึงเทียบหลักฐานกับรหัสธุรกรรมเกตเวย์ที่คัดลอกได้ และยอดที่เกตเวย์แจ้งไว้ ก่อนตัดสินใจว่าจะยืนยันหรือทำเครื่องหมาย แถวที่แสดงในภาพคือรายการฝากที่ถูกเครดิตฝั่งเราจากสลิปที่อัปโหลดเข้ามา ขณะที่เกตเวย์ไม่เคยรายงานว่าสำเร็จ — ซึ่งคือกรณีที่คิวนี้มีไว้เพื่อจัดการโดยเฉพาะ
Settlement and billingการชำระบัญชีและการเรียกเก็บเงิน
What the platform owes its merchants, and what it earns.ยอดที่แพลตฟอร์มค้างชำระร้านค้า และรายได้ที่แพลตฟอร์มได้รับ
Step 17ขั้นตอนที่ 17
Platform settlement — what you oweการชำระบัญชีของแพลตฟอร์ม — ยอดที่ค้างชำระ
The platform's settlement surface (WS-6), grouped under Manage Bank Account and gated to MANAGE_PLATFORM_SETTLEMENT. The default 'What you owe' tab is an account-grouped drill-down of what the platform owes the merchants whose deposits settled into a platform bank account: expand a custodian account to see each claimant with the gross owed and the 'Net settleable' figure (owed minus the platform's fee slice). 'Sync now' refreshes the materialised accrual cache, and each claimant can be settled proactively — the platform records a bank-transfer payment to push money down before the claimant even asks. Recording here reduces the obligation; the platform still never moves money through its own books.หน้าจอชำระบัญชีของแพลตฟอร์ม (WS-6) อยู่ในกลุ่มจัดการบัญชีธนาคาร และต้องมีสิทธิ์จัดการการชำระบัญชีของแพลตฟอร์ม แท็บเริ่มต้น “ยอดที่ค้างชำระ” คือรายละเอียดแยกตามบัญชีของยอดที่แพลตฟอร์มค้างชำระร้านค้าซึ่งเงินฝากเข้ามาที่บัญชีธนาคารของแพลตฟอร์ม กางบัญชีที่ถือเงินไว้เพื่อดูผู้เรียกร้องแต่ละรายพร้อมยอดค้างขั้นต้นและยอด “สุทธิที่ชำระได้” (ยอดค้างหักส่วนค่าธรรมเนียมของแพลตฟอร์ม) ปุ่ม “ซิงก์เดี๋ยวนี้” จะรีเฟรชข้อมูลสรุปที่เก็บไว้ และผู้เรียกร้องแต่ละรายชำระล่วงหน้าได้ — แพลตฟอร์มบันทึกการโอนเพื่อส่งเงินลงไปก่อนที่เขาจะร้องขอด้วยซ้ำ การบันทึกที่นี่ลดภาระหนี้ลง โดยแพลตฟอร์มยังคงไม่ได้เคลื่อนย้ายเงินผ่านบัญชีของตนเอง
Step 18ขั้นตอนที่ 18
Platform settlement — Settle (record a payment)การชำระบัญชีของแพลตฟอร์ม — บันทึกการชำระเงิน
The Settle tab lists the settlement requests claimants have raised against the platform. Open one and Record a payment: enter the amount and paid-at, the destination bank / last-4 / holder, an optional reference and note, and attach the transfer slip (a slip is required — there is no bypass, and nothing auto-verifies the amount you type). Submitting records the discharge and drops the amount still owed.แท็บชำระเงินแสดงคำขอชำระบัญชีที่ผู้เรียกร้องยื่นมาถึงแพลตฟอร์ม เปิดรายการแล้วเลือกบันทึกการชำระเงิน: กรอกจำนวนเงินและวันที่ชำระ ธนาคารปลายทาง เลขบัญชี 4 ตัวท้าย ชื่อบัญชี เลขอ้างอิงและหมายเหตุ (ไม่บังคับ) และแนบสลิปการโอน (บังคับแนบสลิป — ไม่มีทางข้าม และไม่มีระบบใดตรวจสอบจำนวนเงินที่คุณกรอกโดยอัตโนมัติ) เมื่อส่ง ระบบจะบันทึกการชำระและลดยอดที่ยังค้างอยู่
Step 19ขั้นตอนที่ 19
Platform billingการเรียกเก็บเงินของแพลตฟอร์ม
The revenue overview across all resellers and unassigned merchants: totals by reseller, unassigned-merchant fees, and a per-merchant fee search. Use it as the entry point into the fee consoles for a specific merchant or reseller. This screen is gated to billing-permitted roles.ภาพรวมรายได้จากรีเซลเลอร์ทุกรายและร้านค้าที่ไม่ได้สังกัดรีเซลเลอร์: ยอดรวมแยกตามรีเซลเลอร์ ค่าธรรมเนียมของร้านค้าที่ไม่ได้สังกัด และช่องค้นหาค่าธรรมเนียมรายร้านค้า ใช้เป็นทางเข้าไปยังหน้าจอค่าธรรมเนียมของร้านค้าหรือรีเซลเลอร์รายใดรายหนึ่ง หน้าจอนี้จำกัดเฉพาะบทบาทที่มีสิทธิ์ด้านการเรียกเก็บเงิน
Step 20ขั้นตอนที่ 20
Fee ledger — who still owes the platformบัญชีค่าธรรมเนียม — ใครยังค้างจ่ายแพลตฟอร์ม
The collection side of the platform's own revenue, and the counterpart to the billing overview above: that screen tells you what the platform EARNED, sliced by reseller and merchant; this one tells you who still OWES it and whether they have paid. Ledger state comes first, because nothing is billed to anybody until the fee ledger is opened at a cutoff day — while it is closed the page says so in words rather than showing ฿0.00, and with MANAGE_MERCHANTS it offers the single write that performs go-live: type the GMT+7 cutoff day (deliberately never pre-filled), add a note for the audit trail, and open it. Activity before that day is never back-dated as debt, and the day is correctable only while the ledger is still empty — the first posted accrual freezes it. Below it, Outstanding by payer is the fee receivable one row per party: accrued − paid = outstanding, each row tagged Merchant or Reseller because the platform bills one party per merchant — the reseller when the merchant is assigned to one, otherwise the merchant itself. A negative outstanding is shown in red and means that payer has been credited more than has accrued against it. 'Record receipt' opens the write: the amount received, when the payment was made, and an optional bank reference. No proof is attached and none is asked for — recording a receipt reduces the platform's own claim, so the entry runs against the recorder's interest; the payer's ability to dispute it from their own money screen is the check. Reading this page needs VIEW_BILLING; every write on it needs MANAGE_MERCHANTS.ด้านการเก็บเงินของรายได้แพลตฟอร์มเอง และเป็นคู่ตรงข้ามของหน้าภาพรวมการเรียกเก็บด้านบน หน้านั้นบอกว่าแพลตฟอร์ม “หาได้” เท่าไร แยกตามรีเซลเลอร์และร้านค้า ส่วนหน้านี้บอกว่าใคร “ยังค้าง” และจ่ายแล้วหรือยัง สถานะของบัญชีมาก่อนเสมอ เพราะจะยังไม่มีการเรียกเก็บจากใครทั้งสิ้นจนกว่าบัญชีค่าธรรมเนียมจะถูกเปิดที่วันตัดยอด ระหว่างที่ยังปิดอยู่ หน้านี้จะบอกเป็นข้อความตรง ๆ แทนการแสดง ฿0.00 และหากมีสิทธิ์ MANAGE_MERCHANTS จะมีการเขียนข้อมูลเพียงรายการเดียวที่ทำให้ระบบเริ่มใช้งานจริง คือพิมพ์วันตัดยอดตามเวลา GMT+7 (ตั้งใจไม่เติมค่าเริ่มต้นให้) ใส่หมายเหตุสำหรับร่องรอยการตรวจสอบ แล้วกดเปิด 🔴 กิจกรรมก่อนวันนั้นจะไม่ถูกย้อนหลังมาเป็นหนี้เด็ดขาด และวันที่ตัดยอดแก้ไขได้เฉพาะตอนที่บัญชียังว่างเปล่าเท่านั้น รายการค่าธรรมเนียมแรกที่ลงบัญชีจะตรึงวันนั้นไว้ทันที ถัดลงมา ส่วน “ยอดค้างแยกตามผู้ถูกเรียกเก็บ” คือลูกหนี้ค่าธรรมเนียม หนึ่งแถวต่อคู่สัญญาหนึ่งราย คำนวณจาก ที่เกิดขึ้น − ที่จ่ายแล้ว = ค้างชำระ แต่ละแถวติดป้ายว่าเป็นร้านค้าหรือรีเซลเลอร์ เพราะแพลตฟอร์มเรียกเก็บจากคู่สัญญาเพียงรายเดียวต่อร้านค้าหนึ่งราย คือรีเซลเลอร์เมื่อร้านค้ารายนั้นถูกมอบหมายให้รีเซลเลอร์ มิฉะนั้นก็เป็นตัวร้านค้าเอง ยอดค้างที่ติดลบจะแสดงเป็นสีแดง หมายความว่าผู้ถูกเรียกเก็บรายนั้นได้รับเครดิตมากกว่าค่าธรรมเนียมที่เกิดขึ้นกับเขา ปุ่ม “บันทึกการรับเงิน” เปิดการเขียนข้อมูล ได้แก่ จำนวนเงินที่ได้รับ วันที่จ่ายเงิน และรหัสอ้างอิงธนาคารที่ใส่หรือไม่ก็ได้ ระบบไม่แนบหลักฐานและไม่ร้องขอหลักฐานใด ๆ เพราะการบันทึกการรับเงินคือการลดสิทธิ์เรียกร้องของแพลตฟอร์มเอง รายการนี้จึงขัดกับผลประโยชน์ของผู้บันทึกอยู่แล้ว และกลไกตรวจสอบคือสิทธิ์ของผู้ถูกเรียกเก็บที่จะโต้แย้งรายการนั้นจากหน้าจอเรื่องเงินของตนเอง การอ่านหน้านี้ต้องมีสิทธิ์ VIEW_BILLING ส่วนการเขียนทุกรายการต้องมี MANAGE_MERCHANTS
Users, staff and the audit trailผู้ใช้ พนักงาน และร่องรอยการตรวจสอบ
People, the actions taken against their accounts, and who did what.ผู้คน การกระทำต่อบัญชีของพวกเขา และใครทำอะไรไว้
Step 21ขั้นตอนที่ 21
Users listรายชื่อผู้ใช้
The directory of platform end-user accounts with KYC status and account controls. Search here to find a user before taking an account-safety action or inspecting their wallets. Click a row to open the user detail page.ทำเนียบบัญชีผู้ใช้ปลายทางของแพลตฟอร์ม พร้อมสถานะ KYC และตัวควบคุมบัญชี ใช้ค้นหาผู้ใช้ก่อนดำเนินการด้านความปลอดภัยของบัญชี หรือก่อนตรวจดูกระเป๋าเงินของเขา คลิกที่แถวเพื่อเปิดหน้ารายละเอียดผู้ใช้
Step 22ขั้นตอนที่ 22
User detail (freeze / mark-fraud)รายละเอียดผู้ใช้ (ระงับบัญชี / ทำเครื่องหมายทุจริต)
One user's account: their multi-source wallet balances, recent withdrawals, and the account-actions panel. From here you freeze or unfreeze the account, trigger a Data Subject Request on their behalf (auto-VERIFIED since admin identity is the verification), and — where your role permits — reveal an encrypted bank number. Freezing is the primary lever for a suspected-fraud account.บัญชีของผู้ใช้รายหนึ่ง ประกอบด้วยยอดคงเหลือในกระเป๋าเงินแยกตามแหล่งที่มา รายการถอนล่าสุด และแผงดำเนินการกับบัญชี จากที่นี่คุณระงับหรือปลดระงับบัญชีได้ เริ่มคำขอใช้สิทธิ์ของเจ้าของข้อมูลส่วนบุคคลแทนผู้ใช้ได้ (ระบบตั้งเป็นยืนยันแล้วอัตโนมัติ เพราะตัวตนของผู้ดูแลระบบคือการยืนยันในตัวเอง) และ — หากบทบาทของคุณอนุญาต — เปิดเผยเลขบัญชีธนาคารที่เข้ารหัสไว้ได้ การระงับบัญชีคือเครื่องมือหลักสำหรับบัญชีที่สงสัยว่าทุจริต
Step 23ขั้นตอนที่ 23
Audit eventsบันทึกการตรวจสอบ
The append-only, read-only audit log — every financial mutation on the platform lands here in the same transaction that made it, as required for the BOT e-money licence. Filter by type, actor or time window when investigating an incident or reconciling a disputed transaction. Nothing on this screen can be edited or deleted.บันทึกการตรวจสอบแบบเขียนเพิ่มได้อย่างเดียวและอ่านได้อย่างเดียว การเปลี่ยนแปลงทางการเงินทุกรายการบนแพลตฟอร์มจะถูกบันทึกที่นี่ ภายในทรานแซกชันเดียวกับที่ทำให้เกิดการเปลี่ยนแปลงนั้น ตามข้อกำหนดของใบอนุญาต e-money จากธนาคารแห่งประเทศไทย กรองตามประเภท ผู้กระทำ หรือช่วงเวลา เมื่อต้องสอบสวนเหตุการณ์หรือกระทบยอดรายการที่มีข้อโต้แย้ง 🔴 ไม่มีสิ่งใดบนหน้าจอนี้ที่แก้ไขหรือลบได้
Step 24ขั้นตอนที่ 24
Webhook dead-letter queueคิวเว็บฮุกที่ส่งไม่สำเร็จ
Failed and dead-lettered outbound webhook deliveries to merchants. Retry an entry to re-queue delivery, or permanently dead-letter it to stop further retries. Watch this when a merchant reports missing deposit/withdraw notifications — a backed-up DLQ usually means the merchant's endpoint is down or rejecting our signature.รายการส่งเว็บฮุกออกไปยังร้านค้าที่ล้มเหลวและถูกย้ายเข้าคิวปลายทาง กดลองใหม่เพื่อจัดคิวส่งอีกครั้ง หรือย้ายเข้าคิวปลายทางถาวรเพื่อหยุดการลองใหม่ ควรเฝ้าดูหน้านี้เมื่อร้านค้าแจ้งว่าไม่ได้รับการแจ้งเตือนการฝากหรือถอน โดยทั่วไปคิวที่ค้างสะสมหมายความว่าปลายทางของร้านค้าล่ม หรือปฏิเสธลายเซ็นของเรา
Step 25ขั้นตอนที่ 25
Manage adminsจัดการผู้ดูแลระบบ
Provision and manage peer admin accounts — SUPER_ADMIN only, so most roles will not see this. Create an admin (a temp password is generated and shown once; the new admin sets a permanent password and enrolls their own TOTP on first login), or reset an admin's credentials to force re-onboarding and revoke all their live sessions. Relay any one-time temp password out-of-band; self-reset is not allowed.สร้างและจัดการบัญชีผู้ดูแลระบบรายอื่น — เฉพาะ SUPER_ADMIN เท่านั้น บทบาทส่วนใหญ่จึงจะไม่เห็นหน้านี้ สร้างผู้ดูแลระบบได้ (ระบบจะสร้างรหัสผ่านชั่วคราวและแสดงเพียงครั้งเดียว ผู้ดูแลระบบคนใหม่จะตั้งรหัสผ่านถาวรและลงทะเบียน TOTP ของตนเองเมื่อเข้าสู่ระบบครั้งแรก) หรือรีเซ็ตข้อมูลรับรองของผู้ดูแลระบบเพื่อบังคับให้เริ่มลงทะเบียนใหม่ พร้อมยกเลิกเซสชันที่ยังใช้งานอยู่ทั้งหมด ส่งรหัสผ่านชั่วคราวแบบใช้ครั้งเดียวผ่านช่องทางอื่นเสมอ และระบบไม่อนุญาตให้รีเซ็ตบัญชีของตนเอง
Onboarding a new partnerการเปิดบัญชีพันธมิตรใหม่
Creating a merchant or reseller, and the one-time credential reveal.การสร้างร้านค้าหรือรีเซลเลอร์ และการเปิดเผยข้อมูลรับรองแบบครั้งเดียว
Step 26ขั้นตอนที่ 26
Create merchant (form)สร้างร้านค้า (แบบฟอร์ม)
The provisioning form for a new partner merchant: slug, display name, HTTPS webhook URL, per-minute rate limit, and optional DPA acceptance. Submitting issues an API key and HMAC secret that are shown exactly once on the next screen. Requires MANAGE_MERCHANTS.แบบฟอร์มสร้างร้านค้าพาร์ตเนอร์รายใหม่ ประกอบด้วย slug ชื่อที่แสดง URL เว็บฮุกแบบ HTTPS ขีดจำกัดจำนวนคำขอต่อนาที และการยอมรับข้อตกลงประมวลผลข้อมูล (DPA) ซึ่งใส่หรือไม่ก็ได้ เมื่อกดส่ง ระบบจะออก API key และ HMAC secret ที่แสดงเพียงครั้งเดียวในหน้าจอถัดไป ต้องมีสิทธิ์ MANAGE_MERCHANTS
Step 27ขั้นตอนที่ 27
Create merchant → API key + HMAC revealสร้างร้านค้า → เปิดเผย API key และ HMAC
The one-time credentials-reveal screen shown immediately after a merchant is created, displaying the plaintext API key and HMAC webhook secret in copy fields. These values are never retrievable again — capture or hand them to the merchant now, then rotate later from the merchant's detail tab if needed. (Captured here by submitting the create form with throwaway sim values.)หน้าจอเปิดเผยข้อมูลรับรองแบบครั้งเดียว แสดงทันทีหลังสร้างร้านค้าเสร็จ โดยแสดง API key และ HMAC secret สำหรับเว็บฮุกเป็นข้อความธรรมดาในช่องที่คัดลอกได้ 🔴 ค่าเหล่านี้ไม่สามารถเรียกดูย้อนหลังได้อีกเลย ให้บันทึกไว้หรือส่งมอบให้ร้านค้าตอนนี้ แล้วค่อยหมุนเปลี่ยนภายหลังจากแท็บรายละเอียดของร้านค้าหากจำเป็น (ภาพนี้บันทึกจากการกดส่งแบบฟอร์มด้วยค่าทดสอบที่ทิ้งได้)
Step 28ขั้นตอนที่ 28
Create reseller (form)สร้างรีเซลเลอร์ (แบบฟอร์ม)
The provisioning form for a new reseller: slug, display name, owner email and name, a temp password, optional platform base pay-in/pay-out rates, and a can-create-merchants grant. Submitting creates the reseller and its owner login. Requires the reseller-management permission.แบบฟอร์มสร้างรีเซลเลอร์รายใหม่ ประกอบด้วย slug ชื่อที่แสดง อีเมลและชื่อของเจ้าของ รหัสผ่านชั่วคราว อัตราค่าธรรมเนียมพื้นฐานขาเข้า/ขาออกของแพลตฟอร์ม (ใส่หรือไม่ก็ได้) และสิทธิ์ให้สร้างร้านค้าเองได้ เมื่อกดส่ง ระบบจะสร้างรีเซลเลอร์พร้อมบัญชีเข้าสู่ระบบของเจ้าของ ต้องมีสิทธิ์จัดการรีเซลเลอร์
Step 29ขั้นตอนที่ 29
Create reseller → owner credentials revealสร้างรีเซลเลอร์ → เปิดเผยข้อมูลเข้าสู่ระบบของเจ้าของ
The confirmation screen shown right after a reseller is created, listing the new reseller's id, slug and owner email; the owner signs in with the temp password you set on the form. Relay the login out-of-band and have the owner change the password on first sign-in. (Captured here by submitting the create form with throwaway sim values.)หน้าจอยืนยันที่แสดงทันทีหลังสร้างรีเซลเลอร์เสร็จ โดยระบุ id, slug และอีเมลเจ้าของของรีเซลเลอร์รายใหม่ เจ้าของจะเข้าสู่ระบบด้วยรหัสผ่านชั่วคราวที่คุณตั้งไว้ในแบบฟอร์ม ส่งข้อมูลเข้าสู่ระบบผ่านช่องทางอื่น และให้เจ้าของเปลี่ยนรหัสผ่านทันทีที่เข้าสู่ระบบครั้งแรก (ภาพนี้บันทึกจากการกดส่งแบบฟอร์มด้วยค่าทดสอบที่ทิ้งได้)
Risk and fraudความเสี่ยงและการทุจริต
Scored slip findings, provider configuration, and abuse.ผลการให้คะแนนสลิป การตั้งค่าผู้ให้บริการ และการใช้งานในทางที่ผิด
Step 30ขั้นตอนที่ 30
Slip score findingsผลตรวจคะแนนสลิป
Slip-score mismatch findings raised by the automated scorer — cases where the extracted slip data diverged from what was expected but did not hard-fail. Review each and mark it acknowledged. This is a risk-signal review surface, separate from the settle/reject decisions in the main slip-review queue.รายการที่ระบบให้คะแนนสลิปตรวจพบความไม่สอดคล้อง คือกรณีที่ข้อมูลซึ่งดึงจากสลิปต่างไปจากที่คาดไว้ แต่ยังไม่ถึงขั้นล้มเหลวชัดเจน ให้ตรวจแต่ละรายการแล้วทำเครื่องหมายว่ารับทราบ หน้านี้เป็นพื้นที่ตรวจสัญญาณความเสี่ยง แยกต่างหากจากการตัดสินอนุมัติหรือปฏิเสธในคิวตรวจสอบสลิปหลัก
Step 31ขั้นตอนที่ 31
Slip-verify providersผู้ให้บริการตรวจสอบสลิป
Manage the QR-payload verification adapters (EasySlip / MockBank / HippoPay) and their per-scope credentials. You can view the configured providers, add or edit credentials, and run a test call to confirm a provider responds before relying on it. One provider is active per scope, with manual review as the fallback.จัดการอะแดปเตอร์สำหรับตรวจสอบข้อมูลใน QR (EasySlip / MockBank / HippoPay) และข้อมูลรับรองของแต่ละขอบเขต คุณสามารถดูผู้ให้บริการที่ตั้งค่าไว้ เพิ่มหรือแก้ไขข้อมูลรับรอง และเรียกทดสอบเพื่อยืนยันว่าผู้ให้บริการตอบกลับจริงก่อนจะพึ่งพาเขา แต่ละขอบเขตมีผู้ให้บริการที่ใช้งานอยู่หนึ่งราย โดยมีการตรวจสอบด้วยคนเป็นทางเลือกสำรอง
Step 32ขั้นตอนที่ 32
Abuse reviewตรวจสอบพฤติกรรมผิดปกติ
Users flagged by the deposit-shrinkage detector — a fraud signal for accounts that repeatedly under-fund relative to what they reserve. Review the flagged accounts and act (typically freezing from the user detail page) where warranted. Empty is the healthy state.ผู้ใช้ที่ถูกทำเครื่องหมายโดยตัวตรวจจับการฝากเงินขาด ซึ่งเป็นสัญญาณทุจริตสำหรับบัญชีที่โอนเงินจริงน้อยกว่ายอดที่จองไว้ซ้ำ ๆ ให้ตรวจสอบบัญชีที่ถูกทำเครื่องหมาย แล้วดำเนินการ (โดยทั่วไปคือการระงับบัญชีจากหน้ารายละเอียดผู้ใช้) เมื่อสมควร การที่หน้านี้ว่างเปล่าคือสภาวะปกติที่ดี
Step 33ขั้นตอนที่ 33
Bank-account review (detail)ตรวจสอบบัญชีธนาคาร (รายละเอียด)
The single-account review opened from the verification queue: the submitted bank details for one user account, with Verify and Reject actions. Confirm the account holder and number look legitimate before verifying, since a verified account is what unblocks that user's withdrawal payouts. (Falls back to the queue when no specific account id is available.)หน้าตรวจสอบบัญชีเดี่ยวที่เปิดจากคิวยืนยันบัญชี แสดงข้อมูลบัญชีธนาคารที่ผู้ใช้รายหนึ่งส่งมา พร้อมปุ่มยืนยันและปฏิเสธ ตรวจให้แน่ใจว่าชื่อเจ้าของบัญชีและเลขบัญชีดูถูกต้องก่อนกดยืนยัน เพราะบัญชีที่ผ่านการยืนยันคือสิ่งที่ปลดล็อกการจ่ายเงินถอนของผู้ใช้รายนั้น (หากไม่มี id บัญชีที่ระบุเจาะจง ระบบจะย้อนกลับไปที่หน้าคิว)
Where the money landsปลายทางของเงิน
The platform's own accounts, the deposit destinations, and the fee consoles.บัญชีของแพลตฟอร์มเอง ปลายทางการฝากเงิน และหน้าจอค่าธรรมเนียม
Step 34ขั้นตอนที่ 34
Platform bank poolกลุ่มบัญชีธนาคารของแพลตฟอร์ม
The bank accounts owned by the platform itself — the deposit cascade's final fallback pool when no merchant account is picked. View, add and manage the pooled accounts here. The cascade assigns them round-robin, so keep enough active rows to absorb fallback deposit volume.บัญชีธนาคารที่แพลตฟอร์มเป็นเจ้าของเอง เป็นกลุ่มบัญชีสำรองลำดับสุดท้ายของลำดับการเลือกบัญชีรับฝาก เมื่อไม่มีบัญชีของร้านค้าใดถูกเลือก ดู เพิ่ม และจัดการบัญชีในกลุ่มได้ที่นี่ ระบบจะเลือกใช้แบบวนรอบ จึงควรมีบัญชีที่ใช้งานอยู่มากพอจะรองรับปริมาณเงินฝากที่ตกมาถึงชั้นนี้
Step 35ขั้นตอนที่ 35
Deposit accountsบัญชีรับฝากเงิน
Manage and track deposits into the platform's receiving accounts. Use it to see which platform-side accounts are receiving deposits and their recent activity. A monitoring companion to the platform bank pool.จัดการและติดตามเงินฝากที่เข้ามายังบัญชีรับเงินของแพลตฟอร์ม ใช้ดูว่าบัญชีฝั่งแพลตฟอร์มบัญชีใดกำลังรับเงินฝากอยู่ และมีความเคลื่อนไหวล่าสุดอย่างไร เป็นหน้าคู่กันสำหรับเฝ้าติดตามกลุ่มบัญชีธนาคารของแพลตฟอร์ม
Step 36ขั้นตอนที่ 36
Merchant fee consoleคอนโซลค่าธรรมเนียมร้านค้า
The per-merchant billing console: a billing summary, the active fee schedule, controls to set a new schedule or a single-day override, and a usage-and-fee report (including a by-sub-merchant breakdown). This is where you inspect and adjust exactly what the platform charges one merchant. Gated to billing-permitted roles.คอนโซลการเรียกเก็บเงินรายร้านค้า ประกอบด้วยสรุปการเรียกเก็บ ตารางค่าธรรมเนียมที่ใช้อยู่ ตัวควบคุมสำหรับตั้งตารางใหม่หรือกำหนดค่าเฉพาะวันเดียว และรายงานการใช้งานกับค่าธรรมเนียม (รวมถึงรายละเอียดแยกตามร้านค้าย่อย) นี่คือที่ที่คุณตรวจสอบและปรับสิ่งที่แพลตฟอร์มเรียกเก็บจากร้านค้ารายหนึ่งได้อย่างแม่นยำ จำกัดเฉพาะบทบาทที่มีสิทธิ์ด้านการเรียกเก็บเงิน
Step 37ขั้นตอนที่ 37
Reseller earnings reportรายงานรายได้ของรีเซลเลอร์
The fee-waterfall breakdown for one reseller: totals, a per-merchant table, and a by-sub-merchant view showing how spread is shared. Use it to reconcile what a reseller has earned and what the platform retained.รายละเอียดการไหลของค่าธรรมเนียมของรีเซลเลอร์รายหนึ่ง ประกอบด้วยยอดรวม ตารางแยกรายร้านค้า และมุมมองแยกตามร้านค้าย่อยที่แสดงว่าส่วนต่างถูกแบ่งกันอย่างไร ใช้กระทบยอดว่ารีเซลเลอร์ได้รับเท่าไร และแพลตฟอร์มเก็บไว้เท่าไร
Credit and backlogsเครดิตและงานค้าง
Usage-credit top-ups awaiting a decision, and the queues nobody watches daily.คำขอเติมเครดิตที่รอการอนุมัติ และคิวงานที่ไม่มีใครดูทุกวัน
Step 38ขั้นตอนที่ 38
Usage-credit top-up queueคิวคำขอเติมเครดิตการใช้งาน
Usage-credit top-up requests submitted by merchants, awaiting admin review. Each request represents a merchant asking to add prepaid usage credit that funds their per-deposit billing. Open a request to approve or reject it.คำขอเติมเครดิตการใช้งานที่ร้านค้าส่งเข้ามารอผู้ดูแลระบบตรวจสอบ แต่ละคำขอคือร้านค้าที่ขอเพิ่มเครดิตการใช้งานแบบจ่ายล่วงหน้า ซึ่งใช้เป็นเงินทุนสำหรับการเรียกเก็บรายการฝากของเขา เปิดคำขอเพื่ออนุมัติหรือปฏิเสธ
Step 39ขั้นตอนที่ 39
Usage-credit top-up (detail)คำขอเติมเครดิตการใช้งาน (รายละเอียด)
One merchant top-up request in detail, with Approve and Reject actions. Approving credits the merchant's usage-credit balance; rejecting closes the request. Confirm the amount and the merchant before approving.รายละเอียดคำขอเติมเครดิตของร้านค้ารายหนึ่ง พร้อมปุ่มอนุมัติและปฏิเสธ การอนุมัติจะเพิ่มยอดเครดิตการใช้งานให้ร้านค้า ส่วนการปฏิเสธจะปิดคำขอนั้น ตรวจสอบจำนวนเงินและชื่อร้านค้าให้แน่ใจก่อนกดอนุมัติ
Step 40ขั้นตอนที่ 40
Platform fulfillments queueคิวการจ่ายเงินโดยแพลตฟอร์ม
Withdrawals waiting on platform-admin manual fulfillment on behalf of a merchant. This is your only withdrawal-adjacent surface — it is fulfillment, not approval; ordinary withdrawals auto-enter matching without any admin step. Open an item to submit the transfer slip that completes it.คำขอถอนที่รอให้ผู้ดูแลแพลตฟอร์มจ่ายเงินด้วยมือในนามของร้านค้า นี่คือหน้าจอเดียวที่เกี่ยวกับการถอนสำหรับคุณ — และเป็นการจ่ายเงิน ไม่ใช่การอนุมัติ เพราะคำขอถอนตามปกติจะเข้าสู่ระบบจับคู่เองโดยไม่ต้องผ่านผู้ดูแล เปิดรายการเพื่อส่งสลิปการโอนที่ทำให้รายการนั้นเสร็จสมบูรณ์