# Security Skins are real money, and a payment gateway's job is to be boring with it. This page describes the controls that make that possible — what we verify, what we sign, and what structurally cannot happen without your backend's consent. ## How are trades verified? Every deposit is a real Steam trade against infrastructure we operate. Users authenticate through Steam, and items are verified for ownership and trade eligibility **before** anything is credited — the trade that completed is checked against the trade that was priced, so a swapped or ineligible item is rejected rather than booked. Steam's own trade restrictions (holds, locks, CS2's trade protection) are modeled as explicit trade states, so value inside a protection window is never presented as settled. The mechanics are documented in the [trade lifecycle](/docs/guides/trade-lifecycle). ## How is the accounting kept honest? Every balance change lands as **two matching entries in a double-entry ledger** — a balance is never a running total someone has to trust. The two sides must agree, or the discrepancy surfaces immediately. Months later, any credit can be reconstructed: which items, priced when, settled how. Instant crediting distinguishes spendable value from value still inside a trade protection window, so reversals debit exactly what they should. ## How do merchants know an event is genuine? Every state change reaches your backend as a webhook carrying an **HMAC-SHA256 signature** over the delivery ID, timestamp, and raw body, keyed with a secret that never travels on the wire. Verification is timestamped against replay, and the [callback guide](/docs/guides/callbacks) documents the exact scheme with reference code. A forged callback cannot credit anyone. ## What stops value leaving without permission? Withdrawals pass through an **approval gate**: before any cashout executes, your backend receives the signed request and must explicitly approve it. Deduct-then-approve ordering makes concurrent overdraw structurally impossible — a second request finds the balance already gone. Nothing leaves your platform on our say-so alone; the policy is yours, enforced in one webhook handler you control. ## How is API access contained? Merchant API keys are **scoped** to the operations they need. User-facing flows run on short-lived client tokens (24-hour JWTs) that are limited to one user's session — safe to hand to a frontend, useless for merchant operations. Merchant dashboard accounts support **multi-factor authentication**. ## What happens if my endpoint is down? Callbacks are **retried**, and every delivery carries an ID your handler should treat as an idempotency key — the same event arriving twice must credit once. That combination means a deploy, a timeout or a brief outage delays your view of a trade without losing it, and the [callback guide](/docs/guides/callbacks) documents the retry schedule and the exact verification steps. The ledger is the source of truth either way: if your records and ours ever disagree, the trade history endpoints let you reconcile against it directly. ## Who are you, legally, and where does data go? AssetPay is operated by **AssetPay Oy**, a Finnish company, business registration number **3537599-6** — an EU entity under GDPR, not an anonymous brand. Every third party that processes data on our behalf is listed on the [sub-processor page](/subprocessors), with what data reaches it and where it operates; the [privacy policy](/privacy) adds the lawful basis for each category of processing, retention posture, and how transfers outside the EEA are handled. A Data Processing Agreement is available from [support@assetpay.gg](mailto:support@assetpay.gg). For end-user data flowing through your checkout, you are normally the controller and we act on your instructions as processor. ## Who handles user risk and KYC? Your platform owns its user policy; the gateway is built to enforce it rather than replace it. Client sessions carry the risk context you attach — KYC level, wager history, deposit provenance — and the approval gate lets your backend apply that context to every cashout: instant for established users, review for fresh accounts, thresholds wherever you set them. Skin trades also have no chargeback mechanism, which removes an entire fraud class card processors carry — what replaces it is the trade verification described above. ## How do I report a security issue? Write to [support@assetpay.gg](mailto:support@assetpay.gg) with details and, if relevant, reproduction steps. Reports go to the engineers who run the infrastructure, not a ticket queue, and good-faith research is welcome. --- The implementation details behind everything on this page are public: [the docs](/docs) cover authentication, callbacks and the trade lifecycle, and [the integration walkthrough](/blog/integrate-skin-deposits) shows the signature verification in working code.