Service Availability and Support

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

In short: Paysell is provided on a best-effort basis. We do not commit to a guaranteed uptime figure unless we have signed a separate service level agreement with you. The Service also depends on the TON network and on third-party data providers that we do not control, and every withdrawal is reviewed by a human operator, so no payout timeframe is guaranteed.

1. Availability commitment#

We operate the merchant cabinet at https://paysell.me and the merchant API at https://paysell.me/api/merchant/v1 with reasonable skill and care, and we monitor them continuously. However:

• the Service is provided as is and on a best-effort basis;
• we give no guaranteed uptime percentage, response time or payout time unless a separate written service level agreement has been signed with you;
• availability targets stated informally in documentation or in support correspondence are indicative and do not create a contractual obligation.

Where a service level agreement exists, its terms prevail over this document for the services it covers.

2. What the Service depends on#

Paysell is not responsible for the acts, omissions or availability of these third parties, but we will make reasonable efforts to work around problems and to keep merchants informed.

3. Maintenance#

We carry out planned maintenance in a window of [[Maintenance window, e.g. 02:00–05:00 UTC]] and aim to announce it at least [[48]] hours in advance through the merchant cabinet and, for changes that affect integrations, by email to the account address.

Emergency maintenance — for example to apply a security patch or to respond to an incident — may be carried out without notice. In that case we will publish information as soon as we reasonably can.

During maintenance the cabinet or API may be unavailable or read-only. Payments already sent by buyers to invoice addresses are not lost: they remain on the blockchain and are detected and credited once the Service resumes.

4. Incidents and communication#

If an incident affects payments, withdrawals, the cabinet or the API, we will:

1. publish a notice in the merchant cabinet describing what is affected and, where known, the expected time to restoration;
2. update that notice as the situation develops, and confirm when the incident is closed;
3. notify merchants by email where the incident materially affects the crediting of payments or the security of accounts;
4. provide, on request and where proportionate, a short summary of the cause and of the measures taken to prevent recurrence.

Security incidents affecting personal data are handled in accordance with the Privacy Policy and applicable law.

5. Support#

In scope: questions about your account, invoices, payments, balances, withdrawals and fees; interpreting API responses and webhook payloads; investigating a payment that is missing or was credited unexpectedly; account security, two-factor authentication and session problems.

Out of scope: writing or debugging your application code; advising on your business, tax or regulatory position; recovering funds sent to the wrong address or on a network other than TON; arbitrating disputes with your customers (see Refunds, Disputes and Chargebacks); and any request that would require us to reverse a settled blockchain transaction.

6. Webhooks#

Webhook notifications are signed HMAC-SHA256 over timestamp.body and delivered with the X-Paysell-Signature header; signatures older than 300 seconds must be rejected by your endpoint. Verification is described in the API and Developer Terms and in Security and Responsible Disclosure.

If your endpoint does not return a success response, we retry on this schedule and then stop:

A dropped webhook does not affect your balance: the payment is credited regardless, and the current state can always be read from the API. Design your integration so that the API — not the webhook — is the source of truth, and make your handler idempotent, since a notification may be delivered more than once.

7. Operational parameters#

Current operating limits, which are set out in full in the Fee Schedule and Limits and may change under section 8:

• invoice amounts: 0.1–7,000 TON, or 3–10,000 USDT per invoice;
• invoice creation: 60 invoices per hour per shop;
• invoice expiry: 2 hours by default, configurable between 1 minute and 24 hours;
• confirmation: credited after inclusion in the TON masterchain plus 3 further masterchain blocks and a cross-check against a second data source — typically about one minute from payment to webhook;
• large incoming payments above 500 TON or 2,000 USDT may be held for manual review before crediting;
• withdrawals: minimum 19 TON or 25 USDT, each reviewed and approved manually by a Paysell operator, with no guaranteed timeframe.

8. API versioning and changes#

The merchant API is versioned in its path (/api/merchant/v1); the API and Developer Terms govern its use. Our approach to change:

• Backward-compatible changes — new endpoints, new optional request fields, new fields in responses, new enumeration values — may be introduced at any time without notice. Your integration must tolerate unknown fields and unknown values rather than failing on them.
• Breaking changes are introduced under a new version path. We will give at least [[90]] days' notice before deprecating a version, through the cabinet and by email, and will keep the deprecated version available during that period.
• Emergency changes required for security or legal compliance may take effect immediately; we will explain them as soon as possible.

Operating limits, thresholds and manual-review parameters may be adjusted with reasonable notice, or immediately where required for security or compliance. Fee rates agreed for an existing shop are handled as described in the Terms of Service.

Contact#