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.

#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 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 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, with what data reaches it and where it operates; the privacy policy 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. 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 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 cover authentication, callbacks and the trade lifecycle, and the integration walkthrough shows the signature verification in working code.