Settlement & Service Terms

This page summarises the commercial and operational terms of the UnknownPay service: how your balance is settled back to you, the transaction limits, service hours, and the acceptable-use rules your account must follow.

Payment methods

Deposits can be collected over two channels:

• PromptPay QR (PROMPTPAY_QR) — the default; render qr_payload for the customer to scan.
• Bank transfer (BANK_TRANSFER) — show pay_to for a manual transfer.

See Deposits for the full flow.

Transaction limits

Amounts are sent as baht strings (e.g. "100.00"). A value outside this range is rejected with 422 INVALID_AMOUNT.

Settlement

Settlement is how UnknownPay pays your available balance back to you. It is separate from a withdrawal, which is a payout you send to a customer / destination account.

You can be settled in either currency:

• THB — 0% spread. Settled at face value, with no conversion spread.
• USDT — up to ±5% spread. The conversion rate is derived from CoinGecko and Coinbase reference rates, and the rate applied may differ from the market mid-rate by up to ±5% (the spread). Minimum 1,000 USDT per USDT settlement, processed within 24 hours.

Daily force settlement. UnknownPay may automatically settle your balance once per day. The trigger threshold and the amount to settle are configured per account — when your settle-able balance rises above the configured threshold, the system settles out the configured amount.

Service hours & maintenance

The service is unavailable between 23:00 and 02:00 (UTC+7) for routine maintenance, and may also be unavailable outside these hours when announced by the partner bank.

• During a window, transactional calls may be rejected or delayed — retry after the window closes.
• Bank-driven maintenance is announced ahead of time where possible; the 23:00–02:00 (UTC+7) window is the usual default.

Supported merchants & acceptable use

• Prohibited funds. Funds originating from scams, fraud, or call-center scams are strictly prohibited.

Merchant responsibility & liability

UnknownPay operates at the merchant pool level. We can see and control the balance of your pool — your UnknownPay wallet, exposed via Get Balance — but we have no visibility into the ledger inside your platform: the per-player / per-user balances and entitlements of your own end customers. That ledger lives entirely on your side, and only you can read it.

Because of this boundary, when you submit a withdrawal:

• UnknownPay validates the request against your pool balance only. If the pool is funded, the payout can be approved and dispatched.
• That check is not a verification that the end customer requesting the money actually held a real, withdrawable balance on your site. UnknownPay is structurally unable to perform that check — only your system can.
• You are therefore solely responsible for validating each end customer's entitlement and balance before you call POST /v1/withdrawals, and for all activity performed with your credentials.

A correctly signed request from an allowed IP is your request, and you are bound by it. UnknownPay cannot distinguish a genuine request from one made with leaked, shared, stolen, or misused credentials — whether they are used by you, your staff, your agents, or any third party who obtains them.

Securing your side is your obligation. Treat your credentials as the keys to your pool:

• Protect your show-once secrets. Your API key secret (used to HMAC-sign every request) and your webhook signing secret are each shown only once, at rotate time, and are never recoverable afterwards. Store them in a secrets manager — never in source control, client-side code, or logs — and rotate immediately if one is exposed. See Authentication.
• Sign and verify everything. Every S2S request must carry a valid X-Api-Key and a matching HMAC signature, and every inbound webhook must be verified on its raw bytes before you act on it, so a forged event can never drive your business logic. See Signature Verification. Never treat the synchronous PENDING response as final.
• Lock down the network. Maintain the S2S source IPs you call from so the IP Allowlist admits only your own servers.
• Prevent replay and duplication. Send a unique Idempotency-Key per payout so a retried or replayed request cannot pay out twice.

Allocation of liability. To the extent permitted by applicable law, UnknownPay is not liable for losses, shortfalls, or a drained pool arising from causes that originate on the merchant side, including but not limited to:

• Merchant negligence — failing to validate an end customer's entitlement or balance before submitting a payout.
• Lax or insecure integration — a loose, misconfigured, or unmonitored integration that lets unauthorised or unvalidated requests through.
• Compromise of your systems — your platform, servers, or staff accounts being hacked or misused.
• Compromised credentials — X-Api-Key, secret, or webhook secrets that are leaked, shared, stolen, or misused.
• Fraud originating on the merchant side — fraudulent, collusive, or unauthorised requests submitted through your integration.

Each of the above is the merchant's responsibility, and the resulting loss is borne by the merchant. A payout that UnknownPay approved against a funded pool does not transfer that risk to UnknownPay. Where a loss arises in connection with your credentials, integration, systems, or end-customer validation, you bear the burden of demonstrating that it arose solely from UnknownPay's own act.

You may not rely on an approval, a SUCCESS status, or a withdrawal.success webhook as validation of an end customer or of the underlying transaction — UnknownPay makes no such representation. Any monitoring, screening, or fraud detection that UnknownPay performs is undertaken at its sole discretion for its own risk management; it is not a duty owed to you, creates no warranty, and a failure to detect or prevent any pattern or breach does not create liability for UnknownPay or shift the allocation set out above. UnknownPay's approval or processing of any request, or its not acting on a pattern, does not waive these terms. A payout that reaches SUCCESS is final and irreversible on UnknownPay's side; UnknownPay is under no obligation to reverse, recover, or refund funds already paid out, and any recovery effort it may undertake is best-effort, without guarantee, and not an admission of liability. This allocation of liability survives suspension, closure, and termination of your account.

Our response to abuse. Where UnknownPay detects such patterns — for example structured "salami" payout traffic, a sudden change in withdrawal behaviour, a suspected credential or webhook secret compromise, or any other breach of these terms — it reserves the right to suspend or restrict your account, hold or decline in-flight withdrawals, and, per Account suspension, freeze assets pending investigation. These measures are protective, are taken in good faith, do not by themselves constitute acceptance of liability by UnknownPay, do not transfer to UnknownPay your liability for activity that has already occurred, and, to the extent permitted by applicable law, shall not give rise to any claim against UnknownPay.

Account suspension

If your payment-gateway account is suspended and an investigation finds that the cause originated from your shop, UnknownPay reserves the right to permanently close the shop and freeze all assets for further investigation.

Bank risk control

Bank-side risk control is handled by the UnknownPay team — you do not manage banking relationships or bank risk directly.

How deposits & withdrawals are confirmed

The webhook is the source of truth for the final status of both deposits and withdrawals. Confirm payment to your end customer on the webhook event (e.g. deposit.success / withdrawal.success), not on the synchronous PENDING API response. See Webhooks and Signature Verification.