Security

What is true today

This platform makes no claim about protections that do not exist. What follows is what is actually implemented, and the boundary between that and what is planned is kept sharp.

• Routes that are off stay off. A route that is not open refuses the request instead of guessing an answer.
• Sessions you can end. Signing in creates one session, it is revocable, and signing out ends it.
• Password hashing. Passwords are stored as slow hashes, never as text.
• No secrets in the browser. A password or a session value is never written into browser storage.
• Owner-scoped access. Every order, ticket, key, session and sell submission is looked up by its identifier and by the authenticated owner at the same time. An identifier alone is never sufficient.
• Same-origin mutations. A state-changing request must come from this site, and the check is on the server.
• Expiring, owner-scoped downloads. A delivery link expires and is tied to the account that owns the order.
• Transport and framing headers. A strict content security policy, a transport security policy, a denial of framing, a MIME sniffing prohibition, a referrer restriction and a permissions restriction are set on every response.
• No stored browser secrets. A password, a session token or an API key is never written into browser storage.
• Sanitised audit. Audit records are written with credentials, tokens, numbers and identifiers redacted, and URLs reduced to a marker.

What is designed but not yet built

These are specified, and they are not present. They are listed so that the distinction is visible, and so that nobody reads the list above as a guarantee of a system that has not been built.

• Rate limiting with a dedicated hashing secret and a fail-closed path.
• Independent secrets for session metadata, API activity and rate limiting, each distinct from the application and cron secrets.
• Transactional wallet writes: a reserve or debit, a ledger entry and a local order, all recorded before a supplier is called.
• Unique indexes awaited before any write that depends on them.
• Durable queue leases with fencing, backoff and recovery of expired work only, with no in-memory timer standing in for durable work.
• Payment callbacks that are idempotent, and a binding of the payment reference to the order that cannot be claimed twice.
• Reconciliation of an uncertain supplier result before any retry, replacement or refund.
• Owner-issued, expiring, read-only support access, where the server refuses every mutation regardless of the interface.

Safe support practice

Support never asks for your password, a banking one-time password, a UPI PIN, a session file or a mailbox password, and no legitimate process on this platform requires any of them. A request for one of those is a request from someone else.

They all share a shape: a deadline. The code expires, the session closes, the payment is about to be reversed. That urgency is the technique, and a real support process has no deadline, because nothing in it expires while you are typing.

When you contact support, use an order reference or a payment reference, and never send credentials. Support requests are visible only to the people handling them, and a support-access session is read-only by construction.

Reporting a vulnerability

A private disclosure contact has not been confirmed, and no unverified address is published here. A public issue tracker is not an appropriate place for a vulnerability report, and a posted secret stays posted.

What we do not claim

There is no certification claim, no uptime claim, no penetration-test claim and no compliance claim on this page, because none has been performed or obtained. A platform that sells accounts has a strong commercial incentive to describe itself as secure, which is exactly why the claims here are limited to what is implemented and testable.

When an independent assessment is carried out, its scope, its date, its findings and its limitations are published, including the parts that were not covered.

Incidents

If a security incident affects customer data or order availability, it is recorded on the status page with the time, the scope, what was done and what changed afterwards. Incidents are not removed from the history. The purpose of publishing an incident is not to look good, and a platform that hides its incidents is telling you something about the rest of its claims.