API and Developer Terms

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

In short: These terms govern your use of the Paysell merchant API at https://paysell.me/api/merchant/v1, your API keys and your webhook endpoint. Keep your keys secret, verify every webhook signature before acting on it, stay within the rate limits, and never treat an unverified callback as proof of payment. These terms sit on top of the Terms of Service.

1. Scope#

1.1 These API and Developer Terms apply to any access to the Paysell merchant API, to API keys issued to your Shops, and to webhook deliveries Paysell sends to your endpoints. They supplement the Terms of Service, which continues to apply in full; defined terms have the meaning given there.

1.2 "API" means the HTTP interface published under https://paysell.me/api/merchant/v1, together with its documentation. "Integration" means any software you build or operate that calls the API or receives webhooks.

1.3 By requesting an API key or calling the API you accept these terms on your own behalf and on behalf of any developer or agency acting for you.

2. License and permitted use#

2.1 Paysell grants you a non-exclusive, non-transferable, revocable license to call the API for the sole purpose of accepting payments and managing payouts for your own Shops during the term of the Terms of Service.

2.2 You may allow a developer, agency or platform to integrate on your behalf. You remain fully responsible for their acts and omissions and for anything done with your credentials.

2.3 You must not:

use the API to process payments for a business other than the one approved for the Shop, or resell access to the API as a payment service of your own, without Paysell's prior written approval;
reverse engineer, scrape or circumvent any part of the Services, or attempt to access data belonging to another merchant;
use the API to build a service that competes with Paysell by mirroring its functionality;
run load, penetration or vulnerability testing against production without Paysell's prior written consent (see the Security and Responsible Disclosure policy);
misrepresent your identity, spoof headers, or share a single API key across unrelated businesses.

3. API keys and authentication#

3.1 API keys are issued per Shop from the merchant cabinet. A key is displayed once at creation and is not recoverable afterwards; if you lose it, revoke it and issue a new one.

3.2 API keys are credentials of the same sensitivity as a password. You must store them server-side, encrypted or in a secrets manager, and must never place them in browser code, mobile applications, public repositories, log files, screenshots or support tickets.

3.3 Any request authenticated with your key is treated as made by you. You are responsible for the consequences, including Invoices created and Withdrawals requested, subject only to Paysell's own fault.

3.4 You must revoke a key immediately if it may have been exposed, if a developer with access leaves your project, or if Paysell asks you to. Paysell may revoke a key at any time where it reasonably suspects compromise, abuse or a breach of these terms, and will normally tell you when it does.

3.5 Withdrawal requests require a valid TOTP code where two-factor authentication is enabled on the Account. Do not attempt to automate TOTP generation in a way that stores the shared secret alongside the API key, as this removes the protection two-factor authentication is meant to provide.

4. Rate limits and fair use#

4.1 Each Shop may create up to 60 Invoices per hour. Other endpoints are subject to fair-use limits that Paysell may set and adjust to protect the platform.

4.2 Exceeding a limit results in a rejected request. Your Integration must handle rejection gracefully, back off before retrying, and must not retry in a tight loop.

4.3 Polling is not a substitute for webhooks. Do not poll invoice status more frequently than the documentation permits; use webhooks as the primary notification channel and polling only as a reconciliation fallback.

4.4 Paysell may throttle, suspend or block an Integration that generates abnormal traffic, degrades the Services for other merchants or appears to be automated abuse.

5. Webhooks#

5.1 Paysell notifies your endpoint of payment events by HTTP POST to the URL configured for the Shop. The endpoint must be served over HTTPS with a valid certificate.

5.2 Signature. Each delivery carries the header X-Paysell-Signature, containing an HMAC-SHA256 computed over the string timestamp.body using your Shop's webhook secret, where timestamp is the value delivered with the request and body is the exact raw request body.

5.3 Verification is mandatory. Before acting on a webhook you must: recompute the signature over the raw, unparsed body and compare it in constant time; reject the delivery if the timestamp is outside a window of ±300 seconds from your server time; and confirm that the event refers to an Invoice belonging to you. Never release goods or services on the basis of an unverified callback.

5.4 Retries. If your endpoint does not return a 2xx response, Paysell retries the delivery after 1 minute, 5 minutes, 15 minutes, 1 hour, 6 hours and 24 hours. After the final attempt the delivery is dropped and is not sent again. Keeping your endpoint available is your responsibility; reconcile through the API if you believe you have missed an event.

5.5 Idempotency. The same event may be delivered more than once. Your handler must be idempotent: record the event identifier and ignore duplicates rather than crediting an order twice.

5.6 Fast responses. Respond within a few seconds. Acknowledge first and process asynchronously; long-running work inside the handler causes timeouts and unnecessary retries.

5.7 Paysell keeps your server time out of its trust model: it signs with the timestamp it generated. If your clock drifts, verification will fail. Synchronize your servers with NTP.

6. Your integration#

6.1 You are responsible for the correctness, security and maintenance of your Integration, for the systems it runs on, and for the data it stores.

6.2 You must not display to Buyers any information that misstates how payments work, in particular the number of confirmations required, the expiry of an Invoice or the treatment of underpayments and overpayments. See the Fee Schedule and Limits and Refunds, Disputes and Chargebacks.

6.3 Your Integration must not present Paysell as the seller, as an escrow agent, or as a guarantor of your obligations to Buyers.

6.4 You must keep an independent record of orders and payments sufficient to reconcile against your Balance, and must not rely on Paysell as your only books of record.

7. Changes to the API#

7.1 Paysell may add endpoints, fields and event types at any time. Your Integration must tolerate unknown fields and unknown event types without failing.

7.2 Paysell will use reasonable efforts to give at least 30 days' notice, by e-mail or in the cabinet, before a breaking change to a stable endpoint, and will normally introduce breaking changes under a new version path rather than altering v1 in place.

7.3 Paysell may make an immediate change without notice where required by law, by a security concern or by a third-party dependency such as the network or a data provider.

7.4 Deprecated endpoints may be withdrawn after the notice period. Paysell is not obliged to maintain compatibility with an Integration that ignores deprecation notices.

8. Availability and support#

8.1 The API is provided on the same "as is" and "as available" basis as the rest of the Services, with no uptime commitment. See Service Availability and Support.

8.2 Integration support is provided through tickets in the merchant cabinet and at [[Support email]]. Paysell does not write, review, host or debug your code, and does not accept responsibility for third-party libraries or plugins that call the API.

9. Data and confidentiality#

9.1 API credentials, webhook secrets, non-public documentation and any security information Paysell shares with you are confidential. You must not disclose them except to people in your organization who need them and are bound to keep them confidential.

9.2 Where your Integration causes Paysell to process personal data on your behalf, the Data Processing Agreement applies.

9.3 You must not use the API to collect, infer or store data about other merchants, about Paysell's infrastructure or about Buyers beyond what your own business genuinely requires.

10. Suspension and termination#

10.1 Paysell may suspend or revoke API access, in whole or for a single Shop, immediately where these terms or the Terms of Service are breached, where a credential is compromised, where an Integration threatens the stability or security of the Services, or where required by law.

10.2 Access ends automatically when the Terms of Service terminate. On termination you must stop calling the API, delete stored credentials and destroy any confidential material.

10.3 Suspension of API access does not by itself release funds held on a Balance or waive any obligation under the Terms of Service.

11. Liability#

The limitations and exclusions of liability, and the indemnity, in the Terms of Service apply to these terms. In particular, Paysell is not liable for losses caused by an Integration that fails to verify webhook signatures, fails to handle duplicate deliveries, or treats an unconfirmed payment as settled.

12. Changes to these terms#

Paysell may amend these terms in the manner set out in the Terms of Service. The current version is always published at https://paysell.me/legal with its version number and effective date. Continuing to call the API after the effective date means you accept the change.

13. Governing law#

These terms are governed by [[Governing law]], and disputes are subject to the process and forum stated in the Terms of Service.

Contact#

[[Company legal name]], [[Registered address]], [[Jurisdiction]]

Integration and technical support: [[Support email]] or a ticket in the merchant cabinet
Security reports and suspected key compromise: [[Security email]]
Legal notices: [[Legal email]]