Admin Portal — Operator Manualคู่มือปฏิบัติงานสำหรับผู้ดูแลแพลตฟอร์ม

Who this manual is for

This manual is for the people who run the P2P platform from the admin console:

• Operations: you work the review queues, answer merchants and resellers when something is stuck, and look after the platform's own accounts.
• Risk and compliance: you look at customers' conduct, freeze accounts, and handle data requests.
• Finance: you look after fees, usage credit, and the money the platform holds for merchants in its own accounts.

Merchants, their branches and resellers each have their own manual. When a merchant writes to you, the merchant manual shows what they see and what they can already do themselves. Read the matching entry there before you act: often the fix is theirs, and your job is to tell them which button.

The one rule: P2P never holds the money

Every baht moves bank to bank, between customers, merchants, branches, resellers and payment gateways. P2P keeps the record, checks slips, matches deposits to withdrawals and tells each merchant's system what happened. The admin console has no button that sends money.

What that means for your work:

1. Recording a payment is not making one. On the settlement and fee screens you record a transfer that already happened in a banking app. Make the transfer first, then record it.
2. Approving a slip credits a customer in P2P. It moves nothing at the bank. So an approval is only as good as your check that the money really arrived where the deposit said it should.
3. There is no withdrawal approval. A withdrawal enters the matching queue the moment a merchant's system creates it. Deposits pay it, or the merchant's own staff pay it. You never approve one.
4. Figures about who holds whose money are for information. They move nothing and block nothing. See Who is holding whose money.

The one place P2P does hold money is its own platform bank accounts, and only for a merchant that engineering has switched onto them. See Deposit routes.

Your role in five minutes

There are three roles. Your email and role are shown at the bottom of the menu, and the menu lists only the pages your role can use (with two exceptions, below).

Role	Who usually has it	What you can do	What you cannot do
super-admin Super admin	A few senior staff.	Everything an Admin can do, plus: Admins (create admins, reset an admin's sign-in), and saving a merchant's Priority tier thresholds.	Reset their own sign-in. Change anything through a reseller support session (those are read-only for everyone).
admin Admin	Almost everyone in operations, risk and finance.	Every working page: slip review and slip score alerts, abuse review and shared accounts, merchants (all tabs, staff logins, usage credit, sub-merchants, matching pools), usage-credit top-ups, resellers, billing and the fee ledger, customers (freeze, data requests, reveal a bank number), bank verification, platform bank accounts, platform settlement, webhooks, audit events, slip-verify providers, payment gateways and gateway reconciliation. Act as a merchant or a reseller.	Admins. Saving Priority tier thresholds: the form is shown on a merchant's Matching & risk tab, but saving is refused.
Viewer Viewer	Auditors and management.	The Dashboard: queue depths, the last 24 hours, alerts, and the deposit and withdrawal flow panels.	Everything else.

Three things that trip people up:

• A Viewer sees Webhooks and Audit events in the menu, and both show an error when opened. The menu offers them; the pages behind them need the Admin role. It is not a fault in the page.
• An Admin sees the Priority tier thresholds form and cannot save it. Only a Super admin can. Ask one.
• Platform fulfillments is always empty. Nothing in the product puts a withdrawal there any more. It is not a queue you are missing work from. See Platform fulfillments.

Sign in

super-admin admin Viewer

You need your work email, your password and an authenticator app on your phone (for example Google Authenticator or 1Password).

1. Open the admin console address you were given.
2. Enter your Email and Password, then press Continue.
3. On Two-factor authentication, type the 6-digit code from your app into 6-digit code and press Verify. The code changes every 30 seconds; if it is about to change, wait for the next one.

You land on the Dashboard.

Screenshot to comeThe admin sign-in page, then the 6-digit authenticator code

Your first sign-in

A Super admin creates your account and gives you a temporary password, in person or by another private channel. It expires, so use it soon.

1. Sign in with your email and the temporary password.
2. On Set up your account, choose a New password of at least 12 characters, with a letter and a number, and type it again in Confirm new password.
3. Scan the QR code with your authenticator app. If you cannot scan it, type in the secret shown under Or enter this secret manually:
4. Type the 6-digit code into 6-digit code from your authenticator and press Finish setup.

If you see Your temporary password has expired. Ask a SUPER_ADMIN to reset your credentials., ask a Super admin for a new one.

Screenshot to comeFirst sign-in: choose a password and set up your authenticator

Lost your phone, or forgot your password

There is no "forgot password" link and no way to change your own password from the console. The sign-in page says Forgot password? Contact your platform administrator.

1. Ask a Super admin to open Admins, find you under Admin accounts and reset your sign-in (Admins has the steps).
2. They pass you the new temporary password privately. Your sessions can no longer be renewed, and one already open ends by itself within about an hour.
3. Sign in and set up a new password and authenticator, as on your first sign-in.

A Super admin cannot reset their own sign-in; another Super admin must. If the only Super admin is locked out, engineering has to restore access.

Working inside a merchant's portal

super-admin admin

When a merchant reports something you cannot see from the console, such as a withdrawal's fulfil page or its own settlement screens, you can open their portal as they see it. This is called a support session.

1. Merchants → the merchant → Act as merchant (next to the merchant's name).
2. Write the Reason for access: what the merchant reported, with an ID if you have one. At least 8 characters. It is the only record of why you looked at their customers' data.
3. Choose the Session type:
   • Read-only — see what their staff see, change nothing Use this unless you must change something.
   • Support write — also unstick transactions (fulfil a withdrawal, request a cancel, retry a webhook) This one also asks for Your authenticator code.
4. Press Start session. The merchant portal opens in a new tab; your console stays open in this one.
5. Every page in that tab shows a Support session banner. When you are done, press Exit support session. The session also ends by itself, at the latest after 15 minutes; start a new one if you need longer.

Screenshot to comeThe "Act as this merchant" dialog: reason, session type and authenticator code

What a support-write session can do. Only a short list: record a withdrawal the merchant's staff already paid (with a slip or without one), request cancellation of a stuck deposit, retry webhooks, invite staff, change a staff member's role or reset their password, change some matching and routing settings and a branch's settings, and record money that has left one of the merchant's bank accounts. The merchant manual lists the same from their side.

What it cannot do, even when the button shows: approve or reject slips, register a transfer, cancel or close a withdrawal, close a withdrawal to new deposits, pay from a gateway, add or change bank accounts or gateways, rotate the API key, or record or dispute a settlement payment.

What the merchant sees. They do not see your banner. They may notice a platform-support staff member in their team list, and its name in a "decided by" column. P2P's audit trail records that it was you, and your reason.

Working inside a reseller's portal

super-admin admin

Resellers → the reseller → Act as reseller. Give a reason (Why are you viewing this reseller's data?) and press Start session. The reseller portal opens as its staff see it.

This session is always read-only. You can look at the reseller's merchants, money and settlement pages, but nothing you press there changes anything. Anything that needs changing for a reseller is done from the console (Resellers) or by the reseller.

Only one reseller session can be open at a time. Exit it with Exit support session.

How this manual is organised

1. Start here: this page.
2. How money moves on P2P: read it once; the rest builds on it.
3. Your day: the queues and dashboards, in the order you work them.
4. When something goes wrong: situations, symptom first.
5. Merchants and resellers: setting them up and changing them.
6. Customers and risk: conduct, freezes, shared accounts, data requests.
7. Money and settlement: the platform's settlement page, billing, the fee ledger, usage credit.
8. Platform settings: providers, gateways, platform bank accounts, admins.
9. Glossary.

Something is wrong right now

You are thinking…	Go to
"A merchant says their customer paid, but the deposit expired."	The customer paid after the deposit expired
"Is it safe to approve this slip?"	The QR can't be read, or the check failed
"The merchant wants me to credit a split deposit."	A split deposit only you can credit
"A merchant says they stopped getting notifications."	Webhooks are failing
"A merchant disputed a payment the platform recorded."	Undo a disputed payment
"I need to stop this customer."	Freeze or unfreeze a customer
"A customer wants their data deleted."	A data-erasure request
"Webhooks or Audit events shows an error."	Your role in five minutes

The full list is at the top of When something goes wrong.

How to read the pages

• A word in a box, like Re-scan QR & verify, is a button or label exactly as the console shows it.
• The badges under each heading say which roles can do it: super-admin admin Viewer.
• Don't boxes mark actions that can credit twice, erase data for good, or move real money between merchants. Read them before you press anything.
• A few screens print a raw code, such as CONFIRMED or QR_UNREADABLE, with no translation. This manual quotes those in code style and says what they mean.
• The screenshots were taken in Thai. You can switch the console's language at the bottom of the menu.

Who to contact

For…	Contact
Your own sign-in, your role, a colleague who has left	A Super admin.
Something the console has no button for: a forced release, a deposit whose slip passed but never settled, a platform account that needs verifying, a platform-wide switch	Engineering (the developer on call).
A freeze, a fraud mark or a data request you are unsure about	Compliance, before you press anything.
A merchant's integration: what their system sends or receives	The merchant's own developer, through the merchant.

When you escalate a payment, send the merchant's name, the deposit or withdrawal ID (the copy button next to it), the amount, the time of the bank transfer, and a picture of the slip.

The short version

• Every customer arrives through a merchant. The merchant's system signs them up and starts every deposit and withdrawal. Nobody signs up to P2P directly.
• Money always moves bank to bank. P2P records it, checks it and matches it. The console cannot send money.
• A deposit goes one of three routes, and P2P picks the route, not the customer.
• A withdrawal needs no approval. It waits in the merchant's queue until deposits fill it or the merchant's staff pay it.
• Matching pools decide whose customers may be matched with whose. Enabling a pool makes real money move between merchants.
• Who holds whose money is tracked, not enforced. Those figures move nothing and block nothing. The one exception is a branch's withdraw allowance.

Where customers come from

A merchant's system creates each customer through P2P's partner connection, together with the customer's bank account, which becomes their default account for being paid. So:

• One person at two merchants is two customers in P2P, with two records, two balances and two histories. A freeze or a data request you make applies to the record you opened, not to the person everywhere.
• Every customer has a merchant. When you look at a customer, the first question is always "which merchant", because that merchant's settings decide their limits, their amounts and whose customers they can be matched with.
• A customer's wallet balance is kept per merchant pool. The customer page shows one row per source under Wallets.

A deposit: three routes

When a customer confirms a deposit amount on the merchant's checkout, P2P decides where they should transfer. The dashboard counts settled deposits under the same three names:

Route	Where the customer's money goes	How it is confirmed
P2P match	Straight to the bank account of another customer who is withdrawing.	The customer uploads their slip; P2P checks it.
Bank transfer	A bank account in a pool: the merchant's own, a branch's own, a reseller's, or the platform's.	The customer uploads their slip; P2P checks it.
Payment gateway	A payment gateway, by scanning a QR code.	The gateway reports the payment back. No slip is needed.

P2P tries them in this order:

1. A match, if a withdrawal is waiting that this deposit can fill and the amount is at or below the merchant's P2P cutoff. One transfer then serves two customers.
2. The branch's own accounts, where branch accounts are switched on for the platform. (That is a platform-wide switch set by engineering, not in the console.)
3. The merchant's own accounts and gateways, shared out by the pool's allocation plan.
4. A reseller's accounts or gateway, where that tier is switched on for the platform.
5. The platform's own accounts, only for a merchant that engineering has switched onto platform fallback. There is no control for this in the console.

If nothing is available, the customer is told the deposit cannot be set up right now.

Slips and how they are checked

For the match and bank routes, the customer transfers in their banking app and uploads a photo of the slip. Merchant staff can upload it for them.

1. Automatic check. P2P reads the QR code and asks the slip-checking service configured for that merchant (or the platform's default): the amount, the receiving account, and that the slip has not been used before.
2. It passes. The deposit settles and the customer is credited. On the match route, the withdrawal it was matched to is filled at the same moment.
3. It fails. The customer can try again. After a few failed tries (three, unless engineering has changed it) their uploads lock and the deposit waits for a person in slip review.
4. A person decides. The merchant's own staff decide first; they see the same queue for their own deposits. You are the next step, and the only one for a few cases (below).

Amounts that don't match:

• Paid less than reserved: settles at the amount that arrived. No review.
• Paid up to 5% more: settles on its own.
• Paid more than 5% over: waits in review. Whatever anyone presses, only the reserved amount is credited. See The customer transferred more.

What only a platform admin can do in slip review: credit a split deposit (a deposit paid in parts to more than one account), and decide a merchant's cancellation request. Everything else a merchant's staff can also do on their own deposits.

A withdrawal: no approval, three ways to be paid

A merchant's system asks for a withdrawal and P2P puts it straight into that merchant's queue. No one approves it, and it never expires on its own. It is paid by:

Way	What happens
Matched, no fulfilment	Deposits from other customers are matched to it, and each depositor transfers straight to the withdrawing customer.
Staff fulfilment	The merchant's staff transfer from their own bank, then record it.
Payment gateway payout	The merchant's staff pay it from their gateway balance.

Among the checks made when a withdrawal is created, two involve you:

• The customer's bank account must be verified, unless the merchant has Withdrawal auto-approve (skip bank verification) switched on. New merchants start with it on, so this check mostly applies to older merchants and to any merchant you have switched it off for. Unverified customer accounts wait for you in Bank verify. See Bank verification.
• The merchant's balance check, only for the few merchants an admin has opted in to Credit-check spend gate. It is off for new merchants.

Matching pools: who may be matched with whom

A matching pool is a list of members whose customers may be matched with each other. Members are a merchant's branches (sub-merchants), and a merchant's own untagged customers count as one more member.

• A branch in no pool is shown as Isolated. Its customers match only each other.
• A pool belongs to an owner: a merchant, a reseller or the platform. The owner level decides how far its members reach: merchant, then reseller, then platform, from narrowest to widest.
• Two members can be matched only if both reach far enough to cover the distance between them. A member that bought wider reach does not lose its closer neighbours.
• A new pool is created switched off. You switch it on separately, on Matching pools.
• Some pools ask for a buy-in: real money a branch pays in (off the platform) before it may join. You record it when you admit the branch.

When a withdrawal is filled by another merchant's customer, the branch's withdraw allowance is always checked, whatever the merchant's own setting says, because the shortfall would be settled with another merchant's real money. See Pools and sub-merchants.

Who is holding whose money

A settled deposit credits the customer in P2P at once. The cash, though, sits wherever the customer sent it. Two words describe the result:

• The custodian is whoever's bank account the money landed in.
• The claimant is the merchant or branch whose customer it was.

When they are different, the custodian owes the claimant. For example, a customer of merchant A pays a withdrawer of merchant B through a shared pool: merchant B's customer received A's money, so B owes A. P2P keeps this tally and shows it on each party's Settlement page.

When the platform is the custodian. Only when money landed in one of the platform's own accounts, which happens only for merchants switched onto platform fallback. Then the platform owes that merchant, and you pay it out: see Platform settlement. The platform is never owed money on this tally, because the platform has no customers of its own.

The one balance that does hold things back is a branch's withdraw allowance. It is kept separately from the tally above, and it can stop a branch's withdrawals being filled, or stop a branch leaving a pool while it owes its buy-in. See A branch can't withdraw, never matches, or can't leave its pool.

Fees, usage credit and resellers

Three separate balances follow a settled deposit. Never add them together.

• Usage credit is a merchant's prepaid balance for using P2P. Each settled deposit draws it down by the amount that arrived. The merchant asks for a top-up, and you approve it. It can go below zero. See Usage credit.
• The fee is what a merchant is billed for its activity, at the rate on its fee schedule. Deposits are billed at the pay-in rate and withdrawals at the pay-out rate. Nothing is billed to anyone until the fee ledger is opened. See The fee ledger.
• Resellers manage merchants on the platform's behalf. The platform bills one party per merchant: the reseller, when the merchant is assigned to one, otherwise the merchant itself. The merchant's rate minus the platform base is the reseller's spread; the reseller may pass part of it to its sales agents (MDR users). See Resellers.

Who to ask. Compliance or finance, before you change a rate. Engineering, if a figure on any of these screens looks wrong after a refresh.

A normal shift has one rhythm: read the dashboard, clear slip review, then work down the smaller queues. Most of them are empty on a quiet day, and empty is the healthy state.

Order	Page	What you do there
1	Dashboard	See what is backing up.
2	Slip review	Decide the slips nobody else could.
3	Bank verify	Verify customers' bank accounts so their withdrawals can go ahead.
4	Usage credit topups	Approve merchants' top-ups.
5	Settlement	Look at disputed payments (the menu shows a count).
6	Webhooks	Check failed notifications to merchants.
7	Gateway reconcile, Slip score alerts, Abuse review	Check and mark as reviewed.

Start of shift: the dashboard

super-admin admin Viewer

The Dashboard has two halves.

Deposit & withdrawal flow (the top half) shows deposits and withdrawals over the dates you pick: the tiles (Deposits, Withdrawals, Stale, Avg fulfilment, First-time), a chart, the amounts customers use, and three breakdowns: How withdrawals settled, How deposits settled and Deposits by rail.

• It is not live. It is rebuilt every few minutes, and the Data as of … line says how fresh it is. Read that line before you quote a figure in an incident.
• It counts deposits made through a merchant's checkout. Split deposits are not in it, so never quote it as "all deposits".

The bottom half is live:

• Queue depths: Matches awaiting slip, Bank accounts unverified, Webhooks failed and Webhooks dead-letter. A number that keeps growing is your first job.
• Last 24 hours: sign-ups, withdrawals and slip checks in the last day.
• System alerts: Open critical findings, Merchant webhook success rate (24h) and Backup verifier. A falling webhook rate usually means one merchant's system is down; see Webhooks are failing.

The dashboard does not show whether the background services are running. If the queues stop moving altogether, tell engineering.

Slip review

super-admin admin

Slip review holds every deposit whose slip could not be checked automatically. Merchant staff work the same deposits from their own portal, so a row may disappear because they decided it first. That is normal.

The page has three lists, in this order:

1. Reservation-keyed reviews (merchant-API): the usual kind, one deposit paid to one account.
2. Deposit-leg reviews: split deposits, paid in parts. Only you can credit these. See A split deposit only you can credit.
3. Match-keyed reviews: an older kind, rare today.

Each list is oldest first. Under them, Decided — direct deposits and Decided — split deposits show what was decided, newest first, so you can check a decision a colleague made a minute ago.

Finding one slip. Type a customer's name, or paste a deposit or leg ID, into Find a slip. It narrows every list on the page, the history included.

The Why queued column shows one of two things:

• Merchant requested cancel, with the merchant's reason: the merchant asked you to cancel it. See A merchant asked to cancel a stuck deposit.
• Cascade exhausted on every other row. It does not tell you why the slip is here: an unreadable QR, an over-payment, a late slip and a failed check all show it. The real reason is on the row's page, under the attempts.

The Slip status column shows the latest check's raw result, or No slip uploaded for a deposit in review without a slip.

Deciding a direct deposit

Open a row. The page shows the deposit (amount, where it should have been paid, the customer), its Verification attempts (every upload and what the check said, under Provider response), and the Latest slip.

The buttons you get depend on the latest attempt:

You see	It means	Do this
Re-scan QR & verify	The QR could not be read, the checking service failed or timed out, or it is a late slip nobody has checked.	Press it first. See The QR can't be read, or the check failed.
Approve (over-cap) and Cancel (over-cap)	The customer paid more than 5% over.	See The customer transferred more.
Approve & credit	Any other slip still in review.	Approve only after you have seen, on the slip itself, the reserved amount paid to the account on the deposit.
The reject form, Reject reservation slip	Always there while the deposit is open.	Reject when the money did not arrive where it should. Pick the reason carefully (below).

Choosing a reject reason

Every reject asks for a Reason and a note. The reason is recorded against the customer and feeds their deposit conduct, which merchants see. Pick the one that fits the facts you have, not the strongest one:

Reason	Counts against the customer
Forged slip, Duplicate slip, Wrong destination account	Heavily
No transfer received, Slip outside the deposit window	Moderately
Wrong amount	Lightly (the money did arrive)
Slip could not be read, Verification unavailable (our side), Customer asked to cancel, Reason not recorded	Not at all (still listed on their record)

If our checking service failed, choose Verification unavailable (our side). If none fits, Reason not recorded is the honest choice.

Deciding a split deposit or an older match

A split-deposit page (Leg #…) has Approve with a Slip amount (THB) you type, and Reject with a reason. It has no re-check button. See A split deposit only you can credit.

Not shown: the capture did not reach this screen in this run.

An older match page (Match #…) shows every verification attempt, with Approve slip and Reject slip. The same rules apply: approve only on a slip you have checked yourself.

Slip score alerts

super-admin admin

Slip score alerts lists deposits where the automatic checker's score found something odd (the receiver's name, the receiver's account or the sender) but the deposit was not stopped. Most settled normally.

1. Leave the filter on For review.
2. Press Review on a row and read the mismatch.
3. Press Mark reviewed.

This page is advice only. Marking a row reviewed changes nothing about the deposit. If one customer keeps appearing, look at their conduct (Customers and risk).

Bank verification

super-admin admin

Bank verify lists customers' bank accounts that no one has verified yet, newest first. A customer cannot withdraw to an unverified account, unless their merchant has Withdrawal auto-approve (skip bank verification) switched on (new merchants start with it on). So for the other merchants, this queue keeps withdrawals flowing.

1. Filter by bank or the last 4 digits if a merchant is chasing one account.
2. Open the row. Compare the Account holder with the customer's name (User).
3. To verify: optionally note where your evidence is in Artifact reference (optional), then press Verify account.
4. To reject: give a Reason code (a short code such as NAME_MISMATCH), a note, and press Reject account.

Usage-credit top-ups

super-admin admin

Usage credit topups lists merchants' requests to add usage credit. A merchant whose credit runs out keeps working but shows as overdrawn, so a backed-up queue costs them.

Open a request: check the Requested amount, the Bank reference and the Slip cascade verdict, then Approve or Reject. The full procedure, including the fast-forward option, is in Usage credit.

Disputed settlement payments

super-admin admin

When a merchant or branch disputes a settlement payment recorded against them, only a platform admin can undo it. The Settlement menu item shows how many are waiting, and they are listed on the To do tab. See A merchant disputed a settlement payment.

Webhooks

super-admin admin

Webhooks (Webhook DLQ) lists notifications to merchants' systems that failed (Failed, still being retried) or that were given up on (Dead letter). A merchant whose system never hears about a payment will credit or pay its customer late, or twice. See Webhooks are failing.

Gateway reconciliation

super-admin admin

Gateway reconcile lists payment-gateway deposits that were credited on a slip because the gateway never confirmed them. Check each with the gateway provider, then record what you found. This moves no money; the deposit stays credited either way. See A gateway deposit was credited on a slip.

Risk queues

super-admin admin

Abuse review and Shared accounts are signals for review, not verdicts. How to read them, and when to act, is in Customers and risk.

Platform fulfillments is always empty

Platform fulfillments still appears in the menu, and says No platform fulfillments pending. Nothing in the product sends a withdrawal there any more. You are not missing work. A merchant's stuck withdrawal is looked at through a support session.

Looking something up: the audit trail

super-admin admin

Audit events records every change to money, customers, merchants and settings, and who made it, at the moment it happened. Nothing on it can be edited or deleted. Use Show filters to narrow by Event type, Actor ID, Target ID or dates. It is the first place to look when someone asks "who did this, and when".

Each entry starts with what you see, explains why in plain words, then gives the steps. Read the "Don't" box before you press anything. Several buttons here cannot be undone, and a few can credit one bank transfer twice.

Most situations reach you because a merchant's staff could not finish them. Each entry says what the merchant can already do, so you can point them to it instead of doing it for them.

If you see… go to

If you see or hear…	Go to
"The customer paid after the deposit expired. Please credit it."	The customer paid after the deposit expired
A slip in review with Re-scan QR & verify, or QR_UNREADABLE under Provider response	The QR can't be read, or the check failed
Approve (over-cap) and Cancel (over-cap)	The customer transferred more than they reserved
A row under Deposit-leg reviews, or "only a platform admin can credit this"	A split deposit only you can credit
Merchant requested cancel in slip review	A merchant asked you to cancel a stuck deposit
"We can't release this deposit", "the gateway says pending", "the slip passed but nothing settled"	A deposit is stuck and the merchant cannot release it
A row on Gateway reconcile	A gateway deposit was credited on a slip
"We rejected a real payment", or The matched withdrawal is no longer available — release or refund this deposit instead	A genuine deposit was rejected, or can no longer be credited
"Our customer was paid twice"	A withdrawal was paid twice
"We stopped receiving notifications", a falling webhook rate on the dashboard	Webhooks are failing
A disputed payment on Settlement → To do	A merchant disputed a settlement payment
"The platform owes us money. When will it be paid?"	A merchant asks the platform to pay out
"Our branch can't withdraw", "it never matches", Cannot remove: owes … to its pool.	A branch can't withdraw, never matches, or can't leave its pool
A customer you need to stop, or to let back in	Freeze or unfreeze a customer
A customer asks for their data to be deleted	A data-erasure request
"Our staff member is locked out", "our reseller owner can't sign in"	A merchant's or reseller's login is locked out
… active account(s) will not receive deposits, or customers told "we couldn't set up your payment"	Customers can't start a deposit, or an account never receives one
"We changed our keys and everything stopped"	A merchant's API key or signing secret

Deposits

The customer paid after the deposit expired, and the merchant wants it credited

super-admin admin

What you see. The merchant says the customer transferred after the payment window closed, and their deposit shows as expired (on your side, the type DEPOSIT_RESERVATION_EXPIRED). Slip review has nothing for it, and the console's review page for it cannot be opened.

Why it happens. Each deposit holds its destination for a short payment window (5 to 30 minutes, set per merchant). If the customer does not confirm in time, the deposit expires, and an expired deposit cannot be reopened. Uploading the customer's slip as a late slip creates a new deposit, copied from the expired one, and parks it in slip review. Nothing checks a late slip until someone asks for it. The merchant's own staff can do all of this from their portal (merchant manual); you do it when they cannot, or when they ask you to.

What to do

1. Merchants → the merchant → Transactions.
2. Type the merchant's order ID or the customer's merchant user ID into the search box. Expired deposits are listed only while something is typed there.
3. Find the row whose type reads DEPOSIT_RESERVATION_EXPIRED (an expired deposit) and press Upload late slip.
4. In Accept a late slip, add the customer's slip:
   • Safest: paste it (Ctrl+V, or Cmd+V on a Mac) or drag it in. Check the preview, then press Upload this slip.
   • Choose slip image sends the file you pick at once, with no preview.
5. When you see Slip accepted. A new deposit is now waiting in the slip-review queue., go to Slip review, find the new deposit (search for the customer's name) and open it.
6. Press Re-scan QR & verify, then Re-verify. If it ends with Verified & settled, you are done.
7. Only if the check still cannot read the slip, and you have seen on the slip that the reserved amount went to the account on the deposit: press Approve & credit, tick I verified the slip shows the reserved amount was paid to the correct destination and press Approve & credit.

If the upload is refused:

• This deposit is no longer expired, so a late slip does not apply to it.: the deposit is not expired. If the customer confirmed in time, the merchant uploads the slip on the deposit itself.
• A late slip has already been accepted for this deposit.: a late slip is already in review. Decide that one.
• The withdrawal can no longer absorb this deposit. It has to be reconciled off-platform.: the withdrawal this deposit was matched to is already paid or closed. P2P cannot credit this payment; see A genuine deposit can no longer be credited.

Screenshot to comeThe merchant's Transactions tab, "Upload late slip" and the "Accept a late slip" dialog

Who to ask. Engineering, when the deposit was released (rejected or cancelled) rather than expired. There is then no Upload late slip button, and a released deposit cannot be recovered in the console.

The QR can't be read, or the check failed. Is it safe to approve?

super-admin admin

What you see. A direct deposit in slip review offers Re-scan QR & verify and Approve & credit. Under Verification attempts, the latest attempt shows QR_UNREADABLE (the QR code could not be read from the photo), LATE_SLIP_PARKED (a late slip nobody has checked), or a status of PROVIDER_ERROR or TIMEOUT (the checking service failed or did not answer).

Why it happens. None of these says the slip is wrong. The photo may be blurred, or our checking service may have been down. Re-scan QR & verify sends the slip to the real checking service again: if it passes, the deposit settles and P2P records the transfer's real bank reference. Approve & credit does not check anything. It credits the full reserved amount and records a made-up reference, so if the same transfer is ever presented again, P2P cannot recognise it.

What to do

1. Press Re-scan QR & verify. The dialog tries to read the QR from the existing picture.
2. If it cannot, add a clearer photo from the merchant or the customer (paste it, drag it, or Choose image), or paste the QR text into QR value (optional — only if auto-scan failed).
3. Press Re-verify. The page shows Re-verifying…, then either Verified & settled (done) or Still needs review with a reason.
4. If the reason says the amount or the receiving account is wrong, do not approve. Reject with the matching reason (Choosing a reject reason).
5. If the slip truly cannot be read by the service, open the slip image and check it yourself: the amount, and that the receiver is the account on the deposit. Only then press Approve & credit. The dialog shows the Reserved amount and the Buyer. Tick I verified the slip shows the reserved amount was paid to the correct destination, add a note, and press Approve & credit.
6. If approving is refused:
   • This slip image already settled another deposit — approving would credit one transfer twice. Resolve that settlement first; retrying will not help. Stop. Find the deposit it already settled.
   • This review was already resolved by someone else. Refresh to see the current state. Refresh.
   • The matched withdrawal is no longer available — release or refund this deposit instead See A genuine deposit can no longer be credited.

Screenshot to comeA deposit in slip review offering "Re-scan QR & verify", and the re-verify dialog

Who to ask. Engineering, if every slip from one merchant fails the same way. The merchant's checking service may be switched off or set up wrongly (Slip-verify providers).

The customer transferred more than they reserved

super-admin admin

What you see. The latest attempt shows AMOUNT_OVER_CAP. The page offers Approve (over-cap), Cancel (over-cap) and the reject form.

Why it happens. A slip up to 5% over the reserved amount settles by itself. More than that waits for a person. Both over-cap buttons settle the deposit the same way: the customer is credited the reserved amount only, the matched withdrawal is filled, and the extra is recorded for the merchant to deal with. The extra is never credited to anyone in P2P. The two buttons differ only in the decision they record: that you accept the over-payment, or that you do not. The note under Cancel (over-cap) says only the reservation is released; in fact the customer is credited either way.

What to do

1. Compare the deposit's amount with the Parsed amount.
2. Press Cancel (over-cap), or Approve (over-cap) if the merchant's policy accepts over-payments.
3. In the dialog, check Reserved amount, Slip amount and Excess (not credited), and compare the receiving account on the slip with the deposit's account.
4. Tick I have verified the slip's receiver account matches the assigned destination account. and press Confirm.
5. Tell the merchant: the customer was credited the reserved amount, and the extra must be settled with the customer outside P2P.

Who to ask. The merchant, for the extra. On a P2P match the extra is with the withdrawing customer who was paid, and P2P holds nothing it could move.

A split deposit only you can credit

super-admin admin

What you see. A row under Deposit-leg reviews. The merchant says they can see it but have no approve button. Its page shows the amount, the Source, the customer and the attempts, with Approve (and a Slip amount (THB) to type) and Reject.

Why it happens. Split deposits are an older mechanism, where one deposit is paid in parts ("legs") to more than one account. Merchant staff may reject them or re-check them, but only a platform admin can credit one. When you approve, P2P settles the part at the amount you type. Nothing checks that figure, and it records a made-up bank reference, as a hand approval always does.

What to do

1. Open the row. Read Verification attempts and open the slip image.
2. If the QR could not be read, ask the merchant's staff to press Re-scan QR & verify on their side first. The console has no re-check for split deposits.
3. If the slip shows the money reached the right account: type exactly the amount the slip shows into Slip amount (THB) (in baht, for example 1500.00), add a note, and press Approve slip.
4. If it did not: choose a Reason, write a note of at least 5 characters, and press Reject slip. For a part matched to a withdrawal, rejecting frees that withdrawal for other deposits.

Not shown: the capture did not reach this screen in this run.

Who to ask. Engineering, if the page says the review was already resolved by someone else but the merchant insists it was not.

A merchant asked you to cancel a stuck deposit

super-admin admin

What you see. A slip review row whose Why queued reads Merchant requested cancel. On its page, a banner: Merchant requested cancellation, with the time, the Reason the merchant's staff gave, and who asked.

Why it happens. Merchant staff cannot cancel a deposit whose customer has already said they paid, because the money may be on its way. They can only ask. The decision is yours. Cancelling is a reject: the deposit is closed with nothing credited and, for a P2P deposit, its matched withdrawal is freed for other depositors.

What to do

1. Read the merchant's reason, then the slip and the attempts, if any.
2. If the customer really did not pay (or asked to cancel before paying): in the reject form, choose Customer asked to cancel or No transfer received, whichever matches the merchant's reason, write a note that quotes it, and press Reject slip.
3. If there is a slip that looks genuine, do not cancel. Decide the slip on its merits (The QR can't be read), and tell the merchant why.
4. There is no "decline the request" button. If you decide not to cancel, leave a note to the merchant through your usual channel; the row stays until the slip is decided.

Who to ask. Compliance, if the merchant's reason suggests fraud.

A deposit is stuck and the merchant cannot release it

super-admin admin

What you see. The merchant says a deposit has been waiting for a long time and their Release hold or Release stuck deposit button is refused. Typically one of these:

• a payment-gateway (QR) deposit the gateway still reports as pending, or cannot be reached about;
• a deposit whose slip passed the check but never settled;
• a deposit that belongs to another merchant and is holding the merchant's withdrawal (their release says it was "not found").

Why it happens. A merchant can release a stuck deposit only when nothing suggests the money arrived. When the gateway still says pending, or a slip passed, releasing could leave a real payment with nothing to credit. The console has no release button for these. A merchant's staff can release their own deposits in the cases that are safe (merchant manual).

What to do

1. Open the merchant's portal read-only (support session) and open the deposit's page. Note what its flow says, the deposit ID and the amount.
2. Gateway deposit, customer says they paid: once the payment window has closed, the merchant's staff can upload the customer's slip on the deposit's page, where the platform allows it. It settles if the slip passes the check against the gateway's account and amount. After it is credited, it appears on Gateway reconcile (A gateway deposit was credited on a slip).
3. Gateway deposit, customer did not pay: the merchant's release works once the gateway reports the payment as failed or cancelled. Ask the merchant to chase the gateway provider.
4. A slip passed but did not settle, or the gateway cannot be reached, or the deposit belongs to another merchant: send the IDs to engineering. Don't have anyone reject or release it.

Who to ask. Engineering, with the deposit ID, the merchant and what the deposit's page says.

A gateway deposit was credited on a slip, and the gateway never confirmed it

super-admin admin

What you see. A row on Gateway reconcile with the Claimant, the Gateway account, the Credited amount and the Gateway status.

Why it happens. When a gateway never reports a payment, merchant staff can settle the deposit on the customer's slip instead. The customer is credited on the slip's evidence, but the gateway has still not said "success". This page is where someone checks that with the gateway provider. Recording what you find moves no money. The deposit stays credited either way.

What to do

1. Leave Pending only ticked.
2. Press Evidence to see the slip under the row, next to the Exact amount. Copy the Gateway txn and the Order.
3. Look the payment up with the gateway provider.
4. If the provider shows it as paid, press Confirm.
5. If it does not, press Flag, write what you found, and press Save flag. Then tell the merchant: the customer was credited on a slip the gateway does not recognise, and the merchant must recover the money outside P2P.

Who to ask. The gateway provider, through the merchant or directly if the gateway is the platform's.

A genuine deposit was rejected, or can no longer be credited

super-admin admin

What you see. One of these:

• The merchant says someone rejected a slip and the customer has now proved they paid.
• Approving fails with The matched withdrawal is no longer available — release or refund this deposit instead
• A late slip is refused with The withdrawal can no longer absorb this deposit. It has to be reconciled off-platform.

Why it happens. A rejected or released deposit is closed for good and takes no more slips. A P2P deposit settles by paying into its matched withdrawal; if that withdrawal was since filled, paid by staff, cancelled or closed, the deposit has nothing to settle into. In both cases the customer's money is with whoever received it (the merchant, or the withdrawing customer), not with P2P. The console cannot credit these. The error's advice to "release or refund" is misleading: releasing credits nobody, and P2P holds nothing to refund.

What to do

1. Don't reject or release anything.
2. Collect the deposit ID, the matched withdrawal's ID (on the merchant's deposit page, through a read-only support session), the slip and its bank reference.
3. Confirm from the slip who received the money.
4. Agree with the merchant how the customer is made whole outside P2P: usually the merchant credits the customer in its own system and recovers the money from whoever received it.
5. If a record in P2P must be corrected, send the IDs to engineering.

Who to ask. Engineering, for any correction in P2P's records.

Withdrawals

A withdrawal was paid twice

super-admin admin

What you see. The merchant says their customer received a withdrawal twice. On the merchant's fulfil page there may be a notice about possible extra transfers, and a row marked as an alleged transfer.

Why it happens. Usually one of two things:

• The merchant's staff paid the withdrawal by hand while a deposit was also filling it, without first closing it to new deposits.
• A depositor's deposit expired or was released, but they transferred to the withdrawing customer anyway, and the withdrawal was then paid again by someone else.

P2P cannot see bank accounts, so a second payment is an allegation until someone checks the bank statement. And P2P holds no money, so it cannot pull the second payment back.

What to do

1. Open the merchant's portal read-only (support session) and open the withdrawal's fulfil page. Read its funding deposits and any alleged-transfer row.
2. If the alleged transfer can still count towards the withdrawal (the row says so), the depositor's genuine slip can be accepted as a late slip, and the depositor credited. The merchant's staff do this from that row (merchant manual). You can do the late-slip part from the console (The customer paid after the deposit expired).
3. Otherwise, the money is with the merchant's customer. The merchant recovers it from them outside P2P.
4. If the merchant's system created two withdrawals for the same customer and both were paid, that is the merchant's integration. Point them to their developer.

Who to ask. The merchant, for recovery from their customer. Compliance, if the same customer is paid twice more than once.

Merchants' systems and settlement

Webhooks are failing: the merchant stopped receiving notifications

super-admin admin

What you see. The merchant says their system is not hearing about deposits or withdrawals. The dashboard's Merchant webhook success rate (24h) falls, or Webhooks failed and Webhooks dead-letter grow.

Why it happens. P2P sends each notification to the merchant's webhook address and retries a failed one for a while (Failed). After the last retry it gives up (Dead letter). Almost always the problem is at the merchant's end: their system is down, their address changed, or it rejects P2P's signature (often after they changed their signing secret).

What to do

1. Webhooks. Filter by the merchant (paste its ID, the last part of its page address in the console) and by status.
2. Read Last error. Open a row for its Payload and Attempt history.
3. Send the merchant the error and the time. Check their Webhook URL on the Profile tab.
4. After the merchant says it is fixed, press Retry on the rows that matter. Each press allows one more attempt, and only a couple of extra attempts are allowed per notification, so don't retry before the fix.
5. To stop a notification being retried at all, press Dead-letter, give an optional reason code, and Confirm.

Who to ask. The merchant's developer, through the merchant. Engineering, if many merchants fail at once.

A merchant disputed a settlement payment

super-admin admin

What you see. The Settlement menu item shows a count. The To do tab lists the payment: who paid whom, the account, the date, the amount, and the claimant's own reason in quotes.

Why it happens. When one party records that it paid another what it owed, the receiving party can dispute it: the money never arrived, or the amount is wrong. A disputed payment already stops counting as paid. Only a platform admin can withdraw a disputed payment, whoever recorded it.

What to do

1. Read the reason. If there is a slip, press View slip.
2. Ask both parties for their bank statements. You are deciding whether the record was wrong, not moving money.
3. If the payment record was wrong, press Undo this payment. In the drawer, write why (the disputing party is shown it) and press Undo payment.
4. The party who paid can then record the correct payment. If the platform was the payer, record it yourself (Record a payment).
5. If the payment was right and the dispute is wrong, leave it and settle it between the parties. There is no button to reject a dispute.

Who to ask. Finance, if the amounts are large or both parties insist.

A merchant asks the platform to pay out money it holds for them

super-admin admin

What you see. A merchant (or a branch) asks when the platform will pay them. On Settlement → Balances, they appear under You owe, perhaps with a Requested … tag.

Why it happens. For merchants switched onto platform fallback, some customers' deposits land in the platform's own accounts. That cash belongs to the merchant, and the platform owes it to them. Nothing pays it out automatically.

What to do

1. Check the freshness line at the top of the page. If it is old, press the ⟳ (Refresh) and wait.
2. Find the party (use Look up a party). Note the amount.
3. Make the transfer first, from the platform account, to the merchant's payout account, in your banking app. Keep the slip.
4. Press Record payment on the row and fill in the drawer (Record a payment).

Who to ask. Finance, before any large payout.

A branch can't withdraw, never matches, or can't leave its pool

super-admin admin

What you see. The merchant says one branch's withdrawals are refused or never get filled, or the branch's pool card says Cannot remove: owes … to its pool.

Why it happens. Three separate things, which look alike from outside:

• The withdraw allowance. Each branch has a withdraw allowance, separate from usage credit. For a branch in a paid pool, a new withdrawal's amount is held against the allowance when it is created, and a withdrawal the allowance cannot cover is refused. For every branch, the allowance is checked again when the withdrawal is matched. For fills by the merchant's own customers, that second check follows the merchant's setting (Enforced on every fill or Cross-merchant fills only); for fills by another merchant's customers it always applies.
• No pool. A branch in no pool is Isolated: its withdrawals can be filled only by its own customers' deposits, which may never come.
• A buy-in owed. A branch that joined a paid pool cannot be removed while it still owes the pool.

What to do

1. Merchants → the merchant → Sub-merchants → the branch → Manage.
2. Read Withdraw allowance. If it is too low for the withdrawal, the merchant (or you, if they ask) adds more with Grant allowance, with a reason.
3. Read Matching pool. If the branch shows Isolated and should match more widely, admit it to a pool (Pools and sub-merchants).
4. On Matching & risk, read the Sub-merchant withdraw allowance limit status.
5. For a branch that owes its pool, what it owes must be settled with the pool's owner first. A reseller that owns the pool records that from its own portal; the console has no action for it. For a pool the platform owns, ask engineering.

Who to ask. The pool's owner (the merchant, its reseller or the platform) for pool membership. Finance, before giving allowance back.

Customers

Freeze or unfreeze a customer

super-admin admin

What you see. A merchant, compliance or your own review says a customer must be stopped, or that a frozen customer should be let back in.

Why it happens. A freeze is the platform-wide stop. It sets the customer to Frozen, which stops them signing in again (a session already open ends by itself within about an hour), and records a platform-wide block with your reason. What the block stops depends on a platform switch set by engineering:

• While block enforcement is on, the customer cannot start deposits or withdrawals with any merchant, their open orders stop being matched, and their withdrawals that can still be cancelled are cancelled. A withdrawal already matched, already partly paid, or with a depositor's payment on its way is held, not cancelled.
• While it is off, the block is only recorded. The customer's merchant can still start deposits and withdrawals for them, and the page's warning applies: Warning: open orders placed before the freeze may still match until they are cancelled separately.

Remember a freeze applies to this customer record, at one merchant. The same person at another merchant is a separate record.

What to do

1. Users → search → open the customer.
2. Read Deposit conduct and Withdrawal experience first. They are on the page above the freeze for a reason.
3. In Freeze account, choose a Reason code (for example Forged slip, AML review or Requested by merchant), add a note, and press Freeze account.
4. Tell the merchant. Withdrawals a freeze cancels are not reported to the merchant's system, so the merchant must restore the customer's balance in its own records.
5. To let them back in: Unfreeze account → an optional note → Unfreeze account. This lifts the platform block. It does not reopen anything that was cancelled or held.

To mark a customer as fraud from the shrinkage queue instead, see Abuse review.

Who to ask. Compliance, before any freeze for money laundering or fraud. Engineering, to confirm whether block enforcement is switched on.

A customer asks for their data to be erased

super-admin admin

What you see. A customer, usually through their merchant, asks P2P to delete their personal data.

Why it happens. Customers have a legal right to ask. An erasure in P2P is carried out automatically, shortly after you submit it, and it cannot be undone: the customer's personal details are anonymised, their bank account details are destroyed, notes that staff wrote about them are redacted, and they are signed out. Their financial records (payments, the ledger, the audit trail) are kept, as the law requires.

The form has no confirmation step. Pressing Submit DSR with Erasure selected submits it at once, as already verified.

What to do

1. Confirm the request is genuine and comes from this customer, at this merchant. Get compliance's agreement if your procedure requires it.
2. Check the customer has nothing in progress: no open withdrawal, no deposit waiting for a slip. An erased customer's bank details are gone, so they can no longer be paid.
3. Users → the customer → Data Subject Request.
4. Set Request kind to Erasure. Check the name on the page once more. Press Submit DSR.
5. When the customer's status later reads Erased, tell the merchant.

The full list of request kinds is in Data subject requests.

Who to ask. Compliance, for every erasure you are unsure about.

Logins and setup

A merchant's or reseller's login is locked out

super-admin admin

What you see. A merchant's staff member (often the only owner) cannot sign in, or a reseller's founding owner has lost their authenticator.

Why it happens. Staff logins have no "forgot password". Normally a merchant's owner resets their own staff (merchant manual). When there is no owner who can sign in, it falls to you. A reseller's founding owner cannot be reset from the reseller portal at all; only from the console.

What to do: a merchant's staff member

1. Merchants → the merchant → Staff & security.
2. Under Staff, find the person and press Reset password.
3. Copy the Temporary password now. It is shown once. Their sessions can no longer be renewed; one already open ends by itself within about an hour.
4. Give it to the person privately, after confirming who they are. They set a new password and authenticator at their next sign-in.

What to do: a reseller's user

1. Resellers → the reseller → Portal users.
2. Press Reset password on the person's row and confirm.
3. Copy the temporary password (shown once) and pass it on privately.

Who to ask. The merchant's other owners, if any; they can reset their own staff.

Customers can't start a deposit, or an account never receives one

super-admin admin

What you see. A merchant says customers are told the payment cannot be set up right now, or that one of their accounts never receives deposits. A deposit accounts page shows … active account(s) will not receive deposits, or an account marked Not verified.

Why it happens. P2P must find somewhere for each deposit to go. An account is skipped when it is switched off, when it is not verified, or when it has reached its daily limit. A gateway is skipped when its credential is switched off. When nothing is left, the customer cannot deposit.

Accounts that a merchant, branch or reseller adds, and merchant accounts you add from the console, count as verified straight away. Platform accounts you add from the console start unverified, and the console has no button to verify one.

What to do

1. Merchants → the merchant → Bank. Check there is at least one account that is Active and Verified.
2. Payment gateways: if the merchant takes QR payments, check its credential is Active, and press Test connection.
3. For a daily limit, the merchant (or you, on Platform bank accounts for the platform's accounts) raises the Daily limit.
4. For an unverified platform account, ask engineering to verify it.

Who to ask. Engineering, for a platform account, or if every destination looks fine and customers still cannot deposit.

A merchant's API key or signing secret

super-admin admin

What you see. A merchant has lost its API key or signing secret, suspects it has leaked, or changed one and now its system is refused, or rejects P2P's notifications.

Why it happens. The API key is how the merchant's system proves itself to P2P. The signing secret (HMAC) is how P2P signs its notifications so the merchant can trust them. Both are shown once, when created or rotated. Rotating replaces the old value at once: the merchant's system stops working until their developer puts in the new one.

What to do

1. Agree a time with the merchant's developer. Rotation breaks their live connection until they update it.
2. Merchants → the merchant → Staff & security → Rotate API key or Rotate HMAC secret → Yes, rotate.
3. Copy the new value now. It is not shown again after you press I've saved it — hide. Hand it to the merchant's developer privately.
4. After a signing-secret change, expect failed webhooks until they update; retry them afterwards (Webhooks are failing).

Who to ask. The merchant's developer.

Almost everything about one merchant lives on its page: Merchants → the merchant. Resellers have their own page under Resellers. Matching pools have one page of their own, Matching pools.

Before you change something for a merchant, check whether the merchant can change it themselves from their portal. Many settings here are also on the merchant's own Settings page, and the merchant knows their business better than you do.

Create a merchant

super-admin admin

1. Merchants → New merchant.
2. Fill in Slug (it can never be changed), Display name, Webhook URL (it must start with https://) and Rate limit / minute.
3. If the merchant has signed the data processing agreement, tick DPA accepted and give the DPA version. Without it, the merchant is created as SUSPENDED and cannot be made ACTIVE until the agreement is recorded.
4. Press Create merchant.
5. The API key and HMAC webhook secret are shown once. Copy both and hand them to the merchant's developer privately. Then press Done — open merchant.

Not shown: the capture did not reach this screen in this run.

Before the merchant can go live, finish these on the merchant's page:

1. Staff & security → invite at least one Owner (Staff logins).
2. Profile → Hosted-checkout return domains. Until one domain is saved, the merchant's hosted checkout does not work.
3. Billing → set a fee schedule (Fees for one merchant).
4. Bank → at least one bank account, unless the merchant adds its own, or takes deposits only through a gateway.
5. If a reseller manages the merchant, assign it (Resellers).

The merchant's page

super-admin admin

The top of the page shows the merchant's name, its status and Act as merchant (support session). Below are eight tabs:

Tab	What is on it
Profile	Name, webhook address, rate limit, status, return domains, the data processing agreement.
Matching & risk	The switches that decide how withdrawals and slips are handled for this merchant.
Billing	Fees, usage credit and the shared-pool buy-in. See Money and settlement.
Sub-merchants	The merchant's branches, their credit, allowance and pool membership.
Bank	The merchant's own bank accounts that deposits go to.
Staff & security	The API key, the signing secret, and staff logins.
Users	The merchant's customers.
Transactions	The merchant's money movements, with the late-slip upload.

Profile

• Edit merchant: change the Display name, Webhook URL, Rate limit / minute and Status, then Save changes. The status list shows ACTIVE, SUSPENDED and DEACTIVATED.
• Hosted-checkout return domains: the web addresses the merchant's checkout may send customers back to. One bare address per line (no https://). A sub-domain is covered automatically.
• Record DPA acceptance: record the agreement version the merchant signed.

Matching and risk switches

super-admin admin

Each switch shows its current status and one button to change it.

Switch	What it does	Default
Withdrawal auto-approve (skip bank verification)	Lets this merchant's customers withdraw to a bank account nobody has verified. It relaxes a compliance control; the merchant becomes responsible for checking its customers. You are asked to confirm before switching it on.	On for merchants created since mid-2026; older merchants keep what they had. The panel's own description still says it is off by default; the status line is what counts.
Credit-check spend gate	Asks the merchant's system to confirm each customer's balance, with a signed reply, before any withdrawal.	Off (opted out)
Slip-provider platform fallback	When the merchant's own slip-checking service cannot be reached, tries the platform's service once before manual review. It only works where the platform-wide switch for it is on.	Off
Allow partial withdrawal fulfillment	Lets a withdrawal be filled by several smaller deposits.	EXACT only
Sub-merchant withdraw allowance limit	Whether a branch's withdraw allowance is checked on every fill, or only on fills by another merchant's customers. Fills by another merchant's customers are always checked.	Cross-merchant fills only
Order amounts	Which of the platform's fixed amounts (฿100 to ฿50,000) this merchant's customers may use. The platform's list itself cannot be changed in the console.	All amounts enabled (platform default).
Reservation expiry window	How long a customer has to pay a deposit, 5 to 30 minutes.	5 minutes
Priority tier thresholds	How many completed deposits put a customer in each priority tier. Only a Super admin can save it.	Platform default: 1 / 3 / 10 / 30

Branches (sub-merchants)

super-admin admin

Sub-merchants lists the merchant's branches with their Usage credit. To add one, fill in External code (the merchant's own code for it) and Display name, and press Create. Usually the merchant does this itself.

Press Manage on a row for four panels:

• Usage credit balance: Allocate moves usage credit from the merchant to the branch; Deallocate moves it back. Each needs a reason.
• Withdraw allowance: Grant allowance adds to the branch's allowance; Claw back takes it back. Each needs a reason.
• Matching pool: which pool the branch is in, who holds the cash (Cash held by), and admit or remove (below).
• Settings: rename, and Suspend, Reactivate or Deactivate.

Put a branch in a pool, or take it out

1. In Matching pool, open Choose a pool… and pick the pool.
2. A free pool: press Admit.
3. A paid pool (Paid pool — buy-in required): only once the branch's buy-in has actually arrived, enter Buy-in received (THB) and Reason (audit), and press Record buy-in and admit.
4. To take a branch out, press Remove from pool. It then shows Isolated. A branch that still owes its pool cannot be removed (Cannot remove: owes … to its pool.).

The merchant's bank accounts

super-admin admin

Bank lists the merchant's own accounts that deposits can go to, with Last assigned and their status. Use Assign a bank account to add one; an account you add here counts as verified, because adding it is your check. Deactivate takes an account out of use without deleting it.

The merchant can add and manage its own accounts, and set how deposits are shared between them, from its portal (merchant manual).

Staff logins, API key and signing secret

super-admin admin

On Staff & security:

• Rotate the API key or signing secret: see A merchant's API key or signing secret. Rotating breaks the merchant's live connection until they update it.
• Invite a staff member: in Invite merchant staff, enter Email, Display name and Role (Owner, Operator or Viewer), then press Generate credentials. Copy the temporary password (shown once) and pass it on privately. They choose their own password and set up an authenticator at first sign-in.
• Reset a password: Reset password on the person's row. See A login is locked out.

There is no button here to switch a staff login off. A merchant's owner does that from their own Team page (merchant manual).

Customers and transactions

super-admin admin

• Users lists the merchant's customers with their Channel, Status and Consent. Search by name or user ID. To act on a customer, use Users (Customers and risk).
• Transactions lists the merchant's money movements. Search by user ID, merchant user ID, merchant order ID or idempotency key. The type column prints a raw code, for example DEPOSIT_RESERVATION_EXPIRED for an expired deposit, and Amount (satang) is in satang (฿1 = 100 satang). An expired deposit offers Upload late slip (The customer paid after the deposit expired).

Matching pools

super-admin admin

Matching pools is where pools are created and switched on or off. Members are admitted from each merchant's own page (Put a branch in a pool), not here. How pools work is explained in Matching pools.

Create a pool

1. Under Create a pool, choose Owned by: Merchant, Reseller or Platform. The owner decides how far its members reach.
2. For a merchant or reseller pool, paste its ID into Owner ID.
3. Give it a Name. Tick Require a buy-in before a sub-merchant may join if members must pay a buy-in.
4. Press Create pool. The pool is created Disabled.

Switch a pool on or off

• Enable: the dialog, Enable this pool?, says how many members will start reaching customers outside their own. From the next match, real money moves between them.
• Disable: every member is isolated at once. No membership is removed, and switching it back on restores them.

Screenshot to comeThe Matching pools page: create a pool, and the enable confirmation

Resellers

super-admin admin

A reseller manages a group of merchants on the platform's behalf, in its own portal. The platform bills the reseller for those merchants, and the reseller keeps the difference between each merchant's rate and the platform base (its spread). The reseller's own manual explains its side (reseller manual).

Create a reseller

1. Resellers → New reseller.
2. Fill in Slug (it can never be changed), Display name, Owner email and Owner display name.
3. Choose a Temporary password (at least 12 characters, with a letter and a digit). You set it, and it is not shown again, so keep it until you have handed it over.
4. Optionally set Base pay-in rate (bps, optional) and Base pay-out rate (bps, optional) (100 bps = 1%; blank means 0), and tick Allow this reseller to create its own merchants if the reseller may set up its own merchants.
5. Press Create reseller, then pass the temporary password to the owner privately.

Not shown: the capture did not reach this screen in this run.

The reseller's page

• Act as reseller: open the reseller's portal read-only (Working inside a reseller's portal).
• Edit reseller: its name, its Status (anything but active locks its portal), and whether it may create merchants.
• Base rates: the platform's cut on this reseller's merchants, which is also the lowest rate the reseller may charge.
• Assigned merchants: Assign a merchant (optionally from a date) or Unassign it. A merchant can belong to one reseller at a time.
• Portal users: the owner, co-owners and sales agents, with Reset password. Only you can reset the founding owner.
• MDR sharing: sales agents' shares (below).
• View earnings →: what the reseller earned (Reseller earnings).

Sales agents' shares (MDR)

A reseller can give its sales agents (MDR users) a share of what it earns. A share is a rate on the merchant's volume, like the fee itself (for example 0.20% of the deposits), and all the shares on one merchant together can never be more than the reseller's spread on that merchant. The card calls it a "share-of-spread", but the figure you type is a rate on volume, not a percentage of the spread.

To set one: Assign share → choose the MDR user, the Fee type, and the Scope (one merchant or a group) → enter Share (%) and Effective from (YYYY-MM-DD) → Assign share. Setting 0 removes a share. Usually the reseller does this itself.

Before you start: one person, several customers

Every customer arrives through a merchant, and the same person at two merchants is two customers in P2P. Everything on this page (conduct, a freeze, a data request) applies to the customer record you opened. If a person must be stopped everywhere, find each of their records.

Signals are not verdicts. The conduct band, the shrinkage flags and the shared-account report exist to point you at something to look at. None of them, on its own, is a reason to freeze anyone.

Find a customer

super-admin admin

Users lists every customer. Search by name, email or user ID; narrow by status (Active, Frozen, Erased, …). The Deposit conduct column shows each customer's band at a glance.

If a merchant gives you their own ID for the customer, open the merchant's Users tab instead, or search the merchant's Transactions by that ID.

The customer's page

super-admin admin

From top to bottom:

• Who they are: Email, User ID, Phone, KYC level and when they joined.
• Wallets: one row per merchant pool, with the Balance and the amount On hold.
• Recent withdrawals.
• Bank accounts: bank, holder and the last digits. Press Reveal to see a full account number. Every reveal is recorded against you, so reveal only when you need the number for a case.
• Deposit conduct, then Withdrawal experience.
• Account actions: freeze or unfreeze, and data requests.

Deposit conduct

The conduct panel summarises the customer's recent deposits: how many went through, and the problems recorded against them (rejected slips, over- and under-payments, expired deposits, duplicates). It gives a band: Clear, Watch or Review.

• Each problem is weighted. A forged or duplicate slip, or a payment to the wrong account, counts heavily. An unreadable photo, our own checking service failing, or a customer's own cancellation counts nothing, but is still listed so you can judge for yourself.
• The band is display only. Nothing is refused, delayed or matched differently because of it.
• Merchants see the same band for their own customers, built from the reasons chosen at reject. That is why the reject reason matters (Choosing a reject reason).

Withdrawal experience is different: How this customer's withdrawals have gone. Mostly a measure of our service, not their behaviour. Never read it as evidence against the customer.

Freeze and unfreeze

super-admin admin

The full procedure, with what a freeze does and does not stop, is the scenario Freeze or unfreeze a customer. In short:

• Freeze account needs a Reason code from a fixed list: Forged slip, Repeated underpayment, Repeated overpayment, Duplicate slip abuse, Chargeback abuse, Identity mismatch, AML review, Requested by merchant or Other. The reason is kept with the block and on the audit trail.
• It stops the customer signing in again and records a block across the whole platform. Whether the block also stops their deposits and withdrawals depends on a platform switch set by engineering.
• Unfreeze account lifts it. Nothing it cancelled or held comes back.

A merchant can also block its own customers, for its own business only, from its portal. A platform freeze is wider: it covers every merchant.

Abuse review

super-admin admin

Abuse review has two tabs.

Shrinkage lists customers who keep paying less than they reserved, with Shrinkages, Total shrinkage and New since last review. For each row, decide:

• Mark honest: the under-payments have an innocent explanation. The flag is dismissed until new ones arrive.
• Mark fraud: choose a Block reason, write what the customer did in Reason for marking fraud, and press Confirm fraud. This freezes the customer, exactly as a freeze from their page does, and records it as fraud.

Deposit conduct lists customers whose conduct band is Review (or, if you choose, Watch and above). It is for looking only; it has no buttons. It will not always agree with the shrinkage tab, and neither is wrong: one counts all time since your last review, the other weighs a recent window.

Empty is the healthy state for both tabs.

Shared bank accounts

super-admin admin

Shared accounts (Shared bank accounts) lists bank account numbers held by more than one party:

• Several users: several customer records share one number. Often one person with records at two merchants, which is normal.
• User and business account: a customer's account is also one of a business's deposit accounts. Usually the business's operator also deposits as a customer. It is listed because that account takes part in matching, so someone should be able to explain it.
• Crosses merchants marks a number seen at more than one merchant.

The counts are a floor, not a total: the same number written slightly differently is not detected. A low count means "what we can see", never "nothing to see".

Screenshot to comeThe Shared bank accounts report

Bank-account verification

super-admin admin

How to work the queue is in Bank verification. What to check before you press Verify account:

1. The Account holder matches the customer's name, allowing for Thai and English spellings of the same name.
2. The bank is one the customer plausibly uses, and the last 4 digits match any evidence you have.
3. The customer is not frozen, and has no fraud record.
4. If you have evidence (a ticket, a statement), note where it is in Artifact reference (optional).

If the name does not match, reject with a short code such as NAME_MISMATCH and a note, and tell the customer's merchant why.

Data subject requests

super-admin admin

Customers have the legal right to see, correct, take away or erase their personal data. You submit a request on the customer's behalf from their page → Data Subject Request. Your identity is the check, so the request goes straight into processing, without a confirmation step.

Request kind	What happens
Access / Portability	P2P gathers the customer's data (profile, bank account details without full numbers, orders, ledger, audit entries and conduct) into an export. The console does not show the export or the request's progress; ask engineering to retrieve it and deliver it.
Rectification	Do not use it from this form. The form sends your note as free text, and the processor can only apply specific fields (email, name, phone, language), so the correction is not made. A request that cannot be processed may also hold up requests submitted after it. Ask engineering to make the correction.
Erasure	Irreversible. Shortly after you submit it, the customer's personal details are anonymised, their bank account details are destroyed, staff notes about them are redacted, and their sessions end. Financial records are kept as the law requires. Their status becomes Erased.

Before an erasure, follow A data-erasure request step by step.

Screenshot to comeThe Data Subject Request card on a customer's page, with the request kind

The audit trail

super-admin admin

Every freeze, fraud mark, reveal, bank verification and data request is recorded on Audit events, with who did it and when. Filter by Target ID (the customer's user ID) to see everything that happened to one customer. See Looking something up.

Who to ask. Compliance, for any freeze, fraud mark or data request you are unsure about. Engineering, for a data export, a correction, or whether block enforcement is on.

Four separate kinds of money appear in this chapter. Never add their figures together, and never use one to fix another:

Kind	What it is	Where
Settlement	Cash the platform holds for merchants in its own accounts, and what it has paid them.	Settlement
Fees	What merchants or resellers owe the platform for using it.	Billing, Fee ledger
Usage credit	A merchant's prepaid balance, drawn down by its deposits.	Usage credit topups, a merchant's Billing tab
Shared-pool buy-in	Money a merchant posted to join a shared matching pool.	A merchant's Billing tab

Nothing here sends money. You make transfers in a banking app, then record them here.

Platform settlement

super-admin admin

Settlement (Platform settlement) is about one thing: cash that landed in the platform's own accounts but belongs to a merchant or branch. That happens only for merchants switched onto platform fallback. The page tells you what the platform owes, what it has paid, and which payments are disputed.

At the top:

• The freshness line says when the figures were worked out (Live or "as of" a time). A figure can be up to a night old. Press ⟳ (Refresh) to have it worked out again before you pay anything.
• What can I do? lists what you can and cannot do on this page, and why.

The tabs:

Tab	What is on it
To do	Disputed settlement payments, from every party, not only the platform. Only a platform admin can undo one, so this is the page's real queue. The menu shows how many are waiting.
Balances	You owe: one row per merchant or branch the platform owes, with Record payment. Owed to you is always empty: the platform has no customers of its own, so no one owes it on this page.
Paid	Every payment the platform has recorded, grouped by who was paid, with the slip if there is one.
Accrual	Pick a merchant to see where its customers' money sits, party by party: the same figures its staff and its reseller see.
Payout accounts	Not used by the platform: payout accounts belong to the parties being paid.

Record a payment

super-admin admin

1. Make the transfer first, from the platform's account, in your banking app. Keep the slip.
2. On Balances, refresh (⟳), find the party (Look up a party filters the list), and press Record payment on its row. A row marked Requested … is a party that asked to be paid; paying it answers their request. If nobody asked, the same button records the payment on the platform's own initiative.
3. Fill in the drawer:
   • Amount (before fee): the full amount you are clearing for this party, before any fee you keep.
   • Fee you keep, if the platform keeps its fee out of the transfer. You transfer then shows what should have left your bank; check it against your slip.
   • Date paid, and the account you sent to (Sent to — bank, Sent to — last 4 digits, Sent to — account name).
   • Bank reference (optional) and Wire slip. The slip is optional, but attach it: without one, a second record of the same transfer cannot be caught.
   • Paid from: the platform account the money left.
4. If the party's money sits in more than one platform account, the drawer splits your payment across them for you.
5. Press Record payment.

The party sees the payment on its own Settlement page, and can confirm it or dispute it.

Correct or undo a payment

super-admin admin

• A payment the platform recorded by mistake (wrong amount, wrong party): on Paid, press Void this on it. In the drawer, say why (the party is shown your reason) and press Void. The amount goes back to owed. Then record the correct payment.
• A payment someone disputed: see A merchant disputed a settlement payment. Every disputed payment is on the To do tab, with Undo this payment. One the platform recorded also shows Void (disputed) on the Paid tab, which lists only the platform's own payments. Both open the same drawer, confirmed with Undo payment.

Voiding and undoing withdraw a record. They move no money.

Billing: what the platform earned

super-admin admin

Billing (Platform billing) shows, for the dates you pick (Bangkok time), Total usage, Total merchant fees, Platform revenue, the resellers' share and the sales agents' share. Below: By reseller, Unassigned merchants (merchants with no reseller), and Merchant fees: search a merchant and press View fees →.

This page says what was earned. Whether it has been paid is on the fee ledger.

Fees for one merchant

super-admin admin

A merchant's fees are set on its Billing tab (the same console opens from View fees →):

• Billing summary: today and this month.
• Fee schedule: the rates in force, newest first.
• Set fee schedule: choose Pay-in (deposits) or Pay-out (withdrawals), an Effective from (YYYY-MM-DD), the Rate (bps) the merchant pays and the Platform base (bps) the platform keeps. 100 bps = 1%. The reseller, if any, earns the difference. Press Set schedule.
• Set day override: a different rate for one day only, for a promotion or a correction, with a reason.
• Usage & fee report: usage and fees over a period, including by branch.

Reseller earnings

super-admin admin

From a reseller's page, View earnings → opens Reseller earnings for the dates you pick: per merchant, the usage, the merchant's fee, the platform's revenue, the reseller's gross, the sales agents' shares and the reseller's net, then By sub-merchant. Use it to agree figures with a reseller before billing.

The fee ledger: who still owes the platform

super-admin admin

Fee ledger is where fees become something someone owes, and where you record that they paid.

Opening the ledger. Until it is opened, nothing is billed to anyone, and the page says The fee ledger is not open. Opening it is the platform's go-live step for billing:

1. Type the Cutoff day (GMT+7). It is deliberately not filled in for you. Activity before that day is never billed.
2. Add a note on why this day, and press Open the ledger.

The day can be corrected only until the first fee is posted. After that it is fixed.

Who owes what. Outstanding by payer shows one row per party the platform bills (accrued − paid = outstanding): the reseller for merchants it manages, otherwise the merchant itself. A negative figure means that party has been credited more than it was billed; look into it.

Recording a payment the platform received. Press Record receipt on the row, enter Amount received (THB), When the payment was made and an optional bank reference, and press Record. No proof is asked for, because recording it reduces the platform's own claim. The party can dispute it from its own Money page.

Correcting a mistake. Under Recorded payments, press Void on a receipt the platform recorded in error, and give a reason. The payment is removed from the balance. If it is the payer who contests a payment, they raise a dispute instead.

Usage credit

super-admin admin

Usage credit is a merchant's prepaid balance for using P2P. Each settled deposit draws it down, and it may go below zero. Merchants top it up by transferring money and asking for it to be added.

Approving a top-up

1. Usage credit topups → a request that is Submitted or Reviewing → Review.
2. Check the Requested amount, the Bank reference, the note, and the Slip cascade verdict (whether the merchant's transfer slip was checked).
3. Press Approve, then Confirm.
4. If the slip could not be checked but you have confirmed the money arrived another way, tick Fast-forward (approve without verified slip), write in Admin note how you confirmed it, press Fast-forward approve, then Confirm.
5. To refuse, give a Reason, press Reject, then Confirm.

Adjusting a balance by hand. On the merchant's Billing tab, Usage credit → Manual balance adjustment: enter Delta (THB) (negative to take credit away) and Reason (required), and press Apply adjustment. Use it for corrections agreed with finance, not for top-ups: a top-up has its own record.

A branch's usage credit is moved from its merchant on the Sub-merchants tab (Branches).

Shared-pool buy-in

super-admin admin

On a merchant's Billing tab, Shared-pool buy-in shows the Reserve posted: money the merchant paid in, off the platform, to join a shared matching pool. On its own it grants nothing and gates nothing.

• Top up: record money the merchant actually sent, with a reason. This only raises the reserve.
• Exchange: turn part of the reserve into one kind of credit, deposit or withdraw, capped at what is Exchangeable now. To split it between the two, exchange twice.

A branch's buy-in for a paid pool is recorded when you admit it (Put a branch in a pool).

Who to ask. Finance, for any payout, void, fee change or manual adjustment you are not sure of.

These pages change how the whole platform behaves, not one merchant. Most changes here take effect for every new deposit at once. Make them in a quiet hour, and tell your team first.

What is not in the console

Several platform-wide switches are set by engineering, outside the console, and can differ between the test and live platforms. The manual says "where the platform allows it" wherever one matters. They include:

• whether a customer block (a freeze, a fraud mark, a merchant's block) actually stops deposits and withdrawals, or is only recorded;
• whether branches' own bank accounts, and resellers' accounts and gateways, take part in deposit routing;
• whether a merchant is switched onto the platform's own accounts as a fallback;
• whether merchant staff may settle a stuck gateway deposit on the customer's slip;
• whether deposits confirmed but never paid are released automatically;
• how many slip uploads a customer gets before they are locked (normally three);
• the platform's default fee, used for any merchant without a fee schedule.

If a merchant's problem depends on one of these, ask engineering what it is set to. Don't guess from how the test platform behaves.

Slip-verify providers

super-admin admin

Slip-verify providers controls the services that check slips. Each deposit is checked by one service: the one set for its merchant, else the one its reseller set up in its own portal, else the platform's default. If that service cannot give an answer, the slip goes to manual review.

Providers lists the services P2P can use, with a status. Turning one to Disabled routes all traffic away from it, for example during that service's outage.

Configured credentials lists the keys stored per scope (the platform's default, or one merchant), and which one is Active.

• Add a key: Add credentials → the Scope (and the Merchant ID for one merchant), the Provider and the API key → Save. The key is never shown again. What saving does depends on the scope:
  • The scope has no active service yet (for example a merchant's first key): the key becomes active at once, and that merchant's slips stop using its reseller's or the platform's service from the next upload.
  • You saved the service that is already active: its key is replaced at once, and the old key stops being used.
  • Another service is already active: the key is stored switched off. Turn it active when you are ready.
• Test it first: Test connection, then paste a slip's QR text or choose a slip image (read in your browser, never uploaded), optionally give the expected amount, and Run test. You see what the service read: the reference, the amount, the sender and the receiver.

Payment gateways

super-admin admin

Payment gateways holds the keys P2P uses to take QR deposits through a payment gateway, and to pay withdrawals from a merchant's gateway balance.

• Add a key: Add credential → the owner (a merchant, or the platform), an optional Display name (optional), the base address if the provider gave one, the API key and API secret → Provision.
  • The first key for an owner goes live at once, and deposits start going to it.
  • If the owner already has an active key, the new one is stored switched off.
• Test connection: asks the gateway for its balance. No customer or deposit is created. Do this before activating anything.
• Activate: puts this key into deposit routing, and takes the owner's other key out.
• Deactivate: deposits for that owner fall back to their other destinations.
• Rotate credentials: replace the key or the secret. The new values are shown once.

The Webhook callback column shows the address the gateway must call back to report payments. If the provider does not have it, gateway deposits never settle on their own.

For gateway deposits that were credited on a slip, see A gateway deposit was credited on a slip.

The platform's bank accounts

super-admin admin

Platform bank accounts opens Deposit accounts: the platform's own accounts that deposits can land in. They are used only for merchants switched onto platform fallback.

• Allocation plan: how deposits are shared between the accounts: Round robin, Least accumulated first or Random.
• Each account shows its status, Today's deposits, Daily limit, Priority and Last used. Edit sets the daily limit (an account is skipped for the rest of the day, Bangkok time, once it reaches it) and the priority.
• View transactions lists the deposits into one account.
• Add, activate or deactivate accounts opens the list where you add a platform account, or switch one on or off.

If you see … active account(s) will not receive deposits: an account marked Not verified never receives a deposit. Platform accounts added in the console start unverified, and the console has no button to verify one. Ask engineering.

Money held, and money moved out

Each account also shows In, Out (recorded) and Remaining: roughly, what customers paid in, minus what the records say has left. Out counts settlement payments recorded as paid from this account, and money moved out. Withdrawal payouts are not counted.

When money leaves a platform account for any other reason (a transfer to another platform account, bank charges), record it so the figure matches the bank statement: Record money moved out → Amount moved out, Date (the date on the statement), What was it for?, and where it went → Record it.

Admins

super-admin

Admins is for Super admins only. Admin accounts lists everyone with access, their role, their state (Active, Has not set a password yet, No authenticator enrolled) and when they last signed in.

Add an admin

1. Under Create admin account, enter the Email and Display name, and choose the Role. The list shows raw codes: ADMIN (Admin), VIEWER (Viewer) and SUPER_ADMIN (Super admin). Give the smallest role that does the job (Your role in five minutes). The role cannot be changed later from the console.
2. Press Create admin.
3. Copy the Temp password. It is shown once and expires. Hand it over in person or by another private channel.

Reset an admin's sign-in

1. Press Reset credentials on their row. This fills in their ID in Reset admin credentials.
2. Optionally give a Reason (optional), for example a lost phone, and press Reset credentials.
3. Copy the Temp password (shown once) and hand it over privately. Their sessions can no longer be renewed, and one already open ends by itself within about an hour. They set up a new password and authenticator with the temporary password.

You cannot reset yourself; another Super admin must.

An admin who leaves. There is no button to switch an admin off. Reset their sign-in (above), with a reason such as "left", and do not hand over the temporary password. They cannot sign in again, but a session they already have open keeps working until it runs out, within about an hour. If they must lose access at once, ask engineering. Either way, ask engineering to remove the account for good.

The names of people and businesses below follow P2P's glossary, so the same thing has the same name in the console, in the merchant and reseller portals, in every manual, and in the Thai versions. Where a term has its own section, it links there.

Terms

• Admin: the everyday operator role, with every working page except managing admins. More
• Allocation plan: how deposits are shared across the accounts in one pool: round robin, least accumulated first, or at random. More
• Audit trail: the record of every change and who made it; nothing on it can be edited. More
• Bank verification: your check that a customer's bank account is theirs. A customer cannot withdraw to an unverified account unless their merchant allows it. More
• Block: a recorded refusal of a customer, by the platform (a freeze) or by a merchant for its own business. Whether it stops money moving depends on a platform switch. More
• Branch: this manual's everyday word for a sub-merchant, a part of a merchant's business with its own customers and staff. More
• Buy-in: money a branch or merchant pays in, off the platform, before it may join a paid matching pool. More
• Claimant: the merchant or branch whose customer's money it is. More
• Conduct band: Clear, Watch or Review, a display-only signal about a customer's recent deposits. More
• Custodian: whoever's bank account a customer's money landed in; it owes the claimant. More
• Data subject request: a customer's legal request to see, correct, take away or erase their data. More
• Deposit route: where a deposit goes: P2P match, Bank transfer or Payment gateway. P2P picks it. More
• Depositor: the person putting money in.
• Depositor's account: the bank account a depositor transfers from.
• Dispute: a party telling P2P that a payment recorded against it did not arrive or is wrong. Only a platform admin can undo a disputed payment. More
• Erasure: the data request that anonymises a customer and destroys their bank details. It cannot be undone. More
• Fast-forward: approving a usage-credit top-up whose slip could not be checked, with a note on how you confirmed the money. More
• Fee ledger: where fees become amounts owed to the platform, and where receipts are recorded. More
• Fee schedule: a merchant's rates (pay-in for deposits, pay-out for withdrawals) and the platform's base, from a date. More
• Freeze: the platform-wide stop on a customer record. More
• Isolated: a branch in no matching pool; its customers match only each other. More
• Late slip: a slip uploaded for a deposit that expired before the customer confirmed; it creates a new deposit for review. More
• Matching pool: a group of members whose customers may be matched with each other. Enabling one moves real money between merchants. More
• MDR user: a reseller's sales agent, who may earn a share of the reseller's spread. More
• Merchant: a business that uses P2P for its customers. Every customer arrives through one.
• Money moved out: a record that cash left one of the platform's accounts, so its figure matches the bank statement. It pays nobody. More
• Over-payment: a slip more than 5% above the reserved amount; only the reserved amount is ever credited. More
• Payment gateway: a provider that takes deposits by QR code and can pay withdrawals from a merchant's gateway balance. More
• Payment window: how long a customer has to pay a deposit, 5 to 30 minutes per merchant. More
• Platform base: the part of a merchant's fee rate the platform keeps. More
• Platform fallback: sending a merchant's deposits to the platform's own accounts. Set by engineering, per merchant. More
• Reach: how far a pool's members can be matched: within a merchant, a reseller, or the whole platform. More
• Receiver: whoever received a bank transfer.
• Record a payment: declaring in P2P that a transfer was made. It does not send money. More
• Reject reason: the reason you give when you reject a slip; it counts against the customer by how serious it is. More
• Reseller: a partner that manages a group of merchants for the platform, and is billed for them. More
• Re-verify: sending a slip to the checking service again with Re-scan QR & verify; always safer than a hand approval. More
• Sender: whoever sent a bank transfer.
• Settlement: paying back money one party holds for another, and recording it in P2P. More
• Shared bank accounts: account numbers held by more than one party; a signal, never proof. More
• Shrinkage: a customer paying less than they reserved, again and again. More
• Slip: the transfer receipt from a banking app, with the QR code P2P checks. More
• Slip review: the queue of deposits whose slip could not be checked automatically. More
• Slip score alerts: deposits the checker flagged as a possible mismatch but did not stop. Advice only. More
• Split deposit: an older kind of deposit paid in parts to more than one account; only a platform admin can credit one. More
• Spread: a merchant's fee rate minus the platform base; what its reseller earns. More
• Sub-merchant: see Branch.
• Super admin: the senior admin role, which can also manage admins. More
• Support session: working inside a merchant's or reseller's portal as that business. More
• Usage credit: a merchant's prepaid balance for using P2P. More
• Viewer: the read-only admin role; it sees the dashboard only. More
• Webhook: a notification P2P sends a merchant's system when money moves. More
• Withdraw allowance: a branch's separate balance that its withdrawals are held against, and that can stop them being filled. More
• Withdrawal: a customer taking money out. No one approves it. More
• Withdrawer: the person taking money out.
• Withdrawer's account: the bank account a withdrawer is paid into.