Integration security
Trusted checks run on the server. The browser controls the interface, but cannot establish identity, financial status or final amounts.
On this page
Sessions and ownership#
A valid server session identifies the account. Settings, requests, notifications and links are filtered by owner. A userId submitted from a form cannot replace that filter.
Mutations additionally check Origin and CSRF. A public invoice URL exposes only that invoice and does not grant account access.
Secrets stay on the server#
Secrets must not appear in Git, HTML, client JavaScript, OpenAPI examples, llms files or support messages. The public bot username is not a secret.
- Telegram bot token and webhook secret.
- External AI provider credentials.
- Payment gateway credentials and signing secrets.
- Session hashes and browser sign-in proofs.
Financial checks#
The server reads saved invoice terms and checks ownership, merchant review status, currency, method and approved amount. URL values and browser calculations cannot change the price.
A signed gateway notification triggers an additional authenticated operation read. Verified state, receipt and event commit together. Replays and older versions cannot confirm duplicate fulfilment.
Card details and one-time codes are relayed only as encrypted envelopes. Do not add session recording, field-reading analytics or request-body logging to payment forms.
Assistant boundaries#
The model receives public articles and facts, the page catalog, readiness flags, the question, three recent message pairs and a safe section label. It has no tools to read accounts or move money. Invalid structured answers or unverified sources fall back to documentation search.
Website and user text are data. An instruction inside a question cannot alter fees or authorize a payout.
Scope of the documentation#
The documentation does not assert a PCI DSS certification, banking licence, Merchant of Record status, guaranteed uptime or absolute security. Such claims require separate, documented confirmation.