Security and Responsible Disclosure

Version 1.0 · Effective [[Effective date]] · Last updated [[Effective date]]

In short: This document describes the security measures Paysell applies to a custodial crypto payment service, what we expect from merchants, and how to report a vulnerability. Researchers who follow the rules below may test our production systems within the stated scope and will not be pursued by us for that testing. Send reports to [[Security email]].

1. Our security measures#

Because Paysell holds crypto-assets on behalf of merchants, our controls are focused on account takeover, key compromise and unauthorized payouts.

1.1 Accounts and authentication#

• Passwords are hashed with Argon2; we never store or transmit them in plaintext, and our staff cannot read them.
• Account email addresses and two-factor secrets are encrypted at rest.
• Two-factor authentication (TOTP) is available to every merchant, with single-use recovery codes issued at enrollment.
• Active login sessions are listed in the cabinet with their IP address, user agent and last activity, and any session can be revoked individually.
• Sensitive actions and administrative decisions are written to a staff audit log.

1.2 Funds and withdrawals#

• Every withdrawal is reviewed and approved by a Paysell operator before it is broadcast. There is no fully automatic payout path.
• Withdrawals require a TOTP code where two-factor authentication is enabled on the account.
• Operating funds are separated between hot wallets, holding the working balance needed for payouts, and cold storage for the remainder.
• Incoming payments above 500 TON or 2,000 USDT may be held for manual review before crediting.
• Payments are credited only after inclusion in the TON masterchain plus three further masterchain blocks and a cross-check against a second data source.

1.3 Application and infrastructure#

• All traffic is served over HTTPS; authentication cookies are HttpOnly and Secure (see the Cookie Policy).
• API keys are stored hashed, are scoped to a single shop, are displayed once at creation, and can be revoked at any time.
• Outbound webhooks are signed with HMAC-SHA256 over timestamp.body and delivered in the X-Paysell-Signature header, with a ±300-second replay window.
• Webhook destinations are validated to prevent server-side request forgery: internal, loopback, link-local and private address ranges are rejected, and redirects are constrained.
• Rate limits apply to authentication, API calls and invoice creation (60 invoices per hour per shop).
• Backups are taken regularly, and access to production systems is limited to the personnel who need it.

We do not claim to operate automated sanctions screening, automated identity verification or automated transaction monitoring; where such checks are performed today they are manual, and we reserve the rights described in the Terms of Service.

2. What we expect from merchants#

Security of your Paysell account is a shared responsibility. You should:

• Enable two-factor authentication and store recovery codes offline, not in the same password manager entry as your password;
• use a unique, strong password and an email account that is itself protected by two-factor authentication;
• treat API keys as secrets — keep them server-side, never in front-end code, mobile apps or public repositories; rotate them periodically and revoke any key that may have been exposed;
• verify the webhook signature on every notification before acting on it, reject signatures outside the 300-second window, and treat notifications as idempotent;
• expose webhook endpoints over HTTPS with a valid certificate;
• verify state through the API before releasing goods, rather than trusting a webhook payload alone;
• review your sessions and payout addresses regularly, and check that your payout address is correct before every withdrawal;
• report a suspected compromise immediately to [[Security email]] and revoke the affected sessions and keys.

Actions taken with your credentials or API keys are treated as your actions until you notify us, as set out in the API and Developer Terms.

3. Responsible disclosure#

We welcome reports from security researchers and will work with you in good faith.

3.1 In scope#

• https://paysell.me and its subdomains operated by Paysell
• The merchant cabinet
• The merchant API at https://paysell.me/api/merchant/v1
• Webhook delivery and signature verification
• Authentication, session handling, two-factor authentication and API key management

3.2 Out of scope#

• Denial-of-service, volumetric or stress testing of any kind
• Social engineering of Paysell staff, merchants or our suppliers, and physical attacks
• Attacks against third-party infrastructure — our hosting provider, the TON network, TON data providers, Tether
• Reports produced only by an automated scanner, with no demonstrated impact
• Missing security headers, weak TLS ciphers, SPF/DMARC configuration, version disclosure, self-XSS, clickjacking on pages without sensitive actions, and rate limiting on non-sensitive endpoints, unless you can show a concrete exploit
• Vulnerabilities in a merchant's own website or integration

3.3 Rules#

By testing, you agree to:

1. use only accounts you created yourself, and stop as soon as you have proof of concept;
2. never access, modify, exfiltrate or retain data belonging to another user — if you encounter such data, stop, do not save it, and tell us in the report;
3. never move, spend or attempt to withdraw funds that are not yours, and never place funds at risk;
4. avoid any action that degrades the Service for others, including automated scanning at volume;
5. keep the finding confidential until we have remediated it or [[90]] days have passed, whichever is earlier, and coordinate any publication with us;
6. comply with applicable law.

3.4 Safe harbour#

If you make a good-faith effort to follow these rules, we will treat your research as authorized, will not initiate legal action against you in respect of it, and will not report it to law enforcement as an attack. If a third party brings a claim in relation to activity that complied with this policy, we will make that clear. This safe harbour does not extend to testing that breaks the rules above, to extortion, or to activity that harms merchants or their customers.

4. How to report#

Send your report to [[Security email]]. Encrypt sensitive details with our PGP key if you prefer: fingerprint [[PGP key fingerprint]], key available at [[PGP key URL]].

Please include: a clear description of the issue and its impact; precise reproduction steps or a proof-of-concept; the affected URL, endpoint or parameter; the accounts, timestamps and source IP addresses you used; and any screenshots or request captures. Reports in English are processed fastest.

Do not open a vulnerability report as an ordinary support ticket, and do not disclose it publicly before we have responded.

5. Our response#

We will tell you when the issue is fixed and, if you wish, credit you in a public acknowledgements list. Paysell does not currently operate a formal bug bounty program; a discretionary reward may be offered for a high-impact, well-documented and previously unknown vulnerability. We decide the amount and eligibility, and a reward is never guaranteed.

6. Changes#

We may update this policy as our systems and program develop. The version and effective date at the top identify the current text.

Contact#