Email and notifications

Configure notification channels, templates, delivery, and billing.

Mandatory account notices

Balance credits, withdrawal updates, subscription results, and account-security changes generate in-app notices and account emails. Merchant templates cannot disable these notices.

Notifications and templates

Click Channel management to open Notification channels in a sidebar on the current page. Add at the top right or edit from the list, both in dialogs. Use the Channels / Notification history tabs at the top to switch between destinations and notification records. Notification settings no longer appears in the sidebar. Both panels slide within the current page without changing the URL, preserving their filters and pagination.

Template switches control payment notifications; cards show enabled templates as tags.

Payment templates bind a specific channel. Only one template is allowed per event, channel and language; new templates start disabled. Each destination uses enabled content matching its notification language, then enabled English, at most once per event. Lists stay in management panels; Add and Edit use dialogs. Closing a changed draft asks before discarding it, and busy operations cannot be interrupted by closing the panel. Tests send only to the selected destination without saving or enabling the template.

Payment template variables are collapsed above Cancel and Save. Expand them and click a variable to insert it.

The default wallet income and expense templates in English and Chinese include Telegram in their titles. Their content starts with the cash-flow tag, without leading emoji.

On desktop, drag the left edge of the message templates sidebar to resize its width. Drag the content editor’s bottom-right corner to adjust its height, up to 600px or 70% of the viewport height, whichever is smaller.

Configure templates and channels from the gear entries in the address form. Management lists open in panels; Add and Edit open dialogs that preserve the address draft. The Send test button uses only its own row’s saved channel and selected template. It does not save the address or prove that a real transfer was detected. When a monitored address is disabled, deleted, or paused for billing, failed channel alerts stop retrying and manual resends are blocked. Messages already sent are not recalled.

Telegram tests return error 10036 when the bot token is rejected (401 Unauthorized). Check or replace the token using BotFather. When testing a saved channel, a masked token keeps the saved credential; enter the full new token to replace it.

Delivery and retries

Inspect delivery history before retrying. Failed emails use stepped backoff, with up to five attempts. Wallet catch-up and resends obey the address state and 72-hour window described below.

Wallet monitoring sends notifications only for transactions whose on-chain time is within the past 72 hours. This limit applies to initial scans, catch-up notifications, and retries. Older transactions can remain in transaction history, but no in-app, external-channel, or Webhook notifications are sent.

Email language

Email supports English and Chinese. Selection follows event language, merchant email language, account interface language, then English.

Independent Webhook

Manage one wallet-monitoring Webhook in the Webhook section below the templates in Notification Settings. It does not reuse payment Webhook configuration or notification-channel Webhooks. The configuration has its own event and address scope, secret, HMAC-SHA256 signature, retry state, and fixed versioned JSON payload. Changes to the URL, scope, events, or secret disable it until it passes another test. Legacy channel Webhooks are read-only; use their migration action to create and test the configuration.

Verify each request with the raw request body before parsing JSON. Read X-PolyPay-Timestamp and X-PolyPay-Signature (t=<timestamp>,v1=<hex>), calculate HMAC-SHA256 with the complete whsec_... secret over <timestamp>.<raw body>, and compare the bytes in constant time. Reject timestamps more than 5 minutes away from the current time and process each payload id only once. Every test request uses a unique test event ID.

Plans and usage

Payment subscriptions, order quotas, and receiving-wallet usage belong to each merchant. Wallet-monitoring plans, monitored addresses, and notification allowances belong to the account; switching merchants does not create another monitoring allowance.

Payment human notifications and wallet-monitoring Webhooks are unlimited. Only the first successful wallet-monitoring human-channel delivery per destination consumes the account monitoring allowance or applicable PAYG charge. Failed deliveries, in-app notices, and system notices do not consume it.