> For the complete documentation index, see [llms.txt](https://docs.paymento.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.paymento.io/security-and-trust/security-model.md). # Security Model Paymento's security model rests on one structural decision: **Paymento never holds a key that can move your money.** Everything else is defence in depth around that. ### Custody Whichever wallet model you use, no Paymento system holds a credential capable of spending your funds. **Bring Your Own Wallet** — Paymento holds your extended public key. An extended public key derives addresses; it cannot produce signatures. There is no field in Paymento's data model that could hold a private key or recovery phrase for your wallet. **Embedded wallet** — your key is generated and used inside hardware-isolated AWS Nitro Enclaves at Turnkey. It is not a multi-party scheme with a share held by Paymento, and the raw private key is never exposed to Paymento, to Turnkey's application servers, or to employees of either company. Policies attached to the wallet deny Paymento's credential the ability to sign, to create a signing session, or to add a signing credential. The full mechanism is on [Custody and Signing Authority](/embedded-wallet/custody-and-signing-authority.md). Paymento cannot independently authorize transfers or seize merchant-controlled on-chain funds. Paymento may, however, restrict access to its software services in accordance with its Terms of Service. Paymento’s service credentials cannot independently authorize Embedded Wallet transactions. A merchant-authorized signing session is required before settlement or wallet-based refunds can be processed. ### Authentication **Merchant API.** Each store has its own API key and secret key. Requests carry the key in the\ `Api-Key` header. A key scoped to one store cannot read or act on another store's payments, even within your own account. **Merchant panel.** Sessions use HttpOnly cookies, so session tokens are not reachable from\ JavaScript. Time-based one-time password (TOTP) two-factor authentication is available and TOTP secrets are encrypted at rest. **Sensitive operations.** Settlements and passkey refunds require a code emailed to your account address in addition to your session, and — for embedded wallets — a passkey approval on top of that. ### Sensitive data at rest Credentials that must be stored are encrypted with authenticated encryption (AES-256-GCM), including the credential Paymento uses to derive addresses on your embedded wallet and any short-lived signing session while a settlement job is running. Session keys are cleared when the job completes. The service refuses to start if its encryption key is absent or malformed. Running with these values in plaintext is not a supported configuration. ### Integrity of notifications Payment notifications (IPN) are signed. Paymento computes an HMAC-SHA256 of the exact request body using your store's secret key and sends it in the `X-HMAC-SHA256-Signature` header. Verify it. Recompute the HMAC over the raw body you received and compare using a constant-time comparison. Then, before acting, confirm with a server-side `POST /v1/payment/verify` call. ### Access control within your account Sub-users can be invited with scoped permissions — viewing a store, managing integrations and API keys, viewing transactions, creating payment links, managing customers, managing billing — so day-to-day staff do not need owner access. Store creation is restricted to the account owner. For embedded wallets, note that permissions govern the *panel*. They do not grant signing authority: moving funds still requires the passkey. ### Platform hardening * **Rate limiting** with distinct policies per surface, including the external merchant API.\ Throttled responses return HTTP 429 with a `Retry-After` header — honour it rather than retrying tightly. * **Cross-store isolation** enforced at the data-access layer, not only in the UI. * **Server-authoritative derivation.** Values a client supplies that affect address derivation are validated and rejected when out of range, never silently corrected — a substituted value would produce addresses you do not control. * **Immutable audit trails** for billing events and wallet ledger entries. * **Idempotency keys** on charges and store creation, so a retried request cannot double-charge. ### Blockchain monitoring Payments are detected by Paymento's own monitoring of the chains it supports, not by trusting the payer or the merchant. An order's state is derived from observed on-chain transactions and their confirmation depth. Once a payment is settled — paid, verified, rejected or refunded — later chain activity does not move it backwards, and paid notifications are not re-fired. ### Reporting a vulnerability Paymento publishes a disclosure contact per RFC 9116 at\ `api.paymento.io/.well-known/security.txt`, pointing to\ [paymento.io/contact-us](https://paymento.io/contact-us/). If you find something, report it there. Please include enough detail to reproduce. ### What is on you The model above protects the parts Paymento controls. The integration on your side is yours to get right, and the most common serious mistake is a specific one. See\ [Merchant Responsibilities](/security-and-trust/merchant-responsibilities.md) — start with the first section.