# How to Accept Rust Skins as Payment

*2026-08-10 — ruushedd, AssetPay team*

Most platforms that take skins take CS2 skins and stop there. That's understandable — the headline items are worth more and the community is louder. It also means that if your audience overlaps with Rust at all, you're declining a working payment method from players who have inventory sitting right there.

Rust is a different economy wearing the same plumbing. The trades settle through Steam exactly like CS2 trades do, so the integration cost of adding it is close to zero. What changes is everything around pricing.

## Same rails, different economy

Every point in the [skin payment flow](/blog/accept-cs2-skins-as-payment) is identical between the two games. A bot sends a trade offer, the user confirms it in the Steam mobile app, the items land, the value is credited. Rust items live in the same Steam inventory system, move through the same trade offer API, and are subject to the same account-level restrictions.

So if you already accept CS2 skins through a gateway, Rust is a configuration change, not a project. If you're building from scratch, supporting both costs you nothing extra at the trade layer.

The differences are all economic:

| | CS2 | Rust |
| --- | --- | --- |
| Typical item value | Wide spread, long high-value tail | Compressed, mostly low |
| Condition system | Float and wear tiers | None |
| Item source | Valve-created cases and collections | Largely Workshop, creator-submitted |
| Per-trade item count | Often few, high value | Often many, low value |

## Rust items have no float, and that simplifies everything

This is the single biggest structural difference. A CS2 skin's value depends on a float value fixed at creation, which splits visually identical items into [tiers that price hundreds of dollars apart](/blog/how-cs2-skin-pricing-works). Rust has no equivalent. A Rust skin is a texture applied to an item, and every copy of that skin is the same as every other copy.

For a payment gateway that removes an entire class of problem. There's no per-item inspection, no wear-tier boundary to get wrong, no pattern index to look up. Two items with the same name are genuinely interchangeable, so pricing collapses to "what does this skin trade for right now."

What replaces float as the source of pricing difficulty is **supply**. Rust skins are sold in the in-game store on a rotation, and many are never brought back. A skin that was available for a week three years ago and never returned behaves like a limited edition: thin float supply, jumpy pricing, and a market that a single large sale can move. Discontinued items are where Rust valuations go wrong, not condition.

## The volume problem

The other thing that changes is shape. A CS2 deposit might be two items worth $300. A Rust deposit is more often twenty items worth $15 total.

That matters more than it sounds:

- **Per-item overhead stops being free.** Anything you do per item — a pricing lookup, a market check, a database write — happens twenty times instead of twice. Naive implementations that are fine on CS2 volumes start timing out.
- **Steam trade offers have item limits.** A large enough deposit has to be split across multiple offers, which means multiple user confirmations, which means more places for the flow to be abandoned halfway.
- **Rounding errors compound.** A half-cent of pricing slack on a $300 item is noise. On a hundred items a day at $0.80 each, it isn't.
- **The floor matters.** Below some value, an item costs more to price, trade, store and eventually liquidate than it's worth. That threshold needs to be a deliberate decision, not an accident.

## Trade restrictions apply identically

None of Steam's timers care which game an item came from. The 15-day hold on accounts without an established mobile authenticator, the cooldown on items recently bought from the Community Market, and the CS2-era protection changes to the trade system all behave the same way for Rust inventory. Our [merchant reference on trade holds and locks](/blog/steam-trade-holds-what-merchants-need-to-know) covers each one and what it means at checkout.

The practical note: because Rust deposits carry more items, they're statistically more likely to contain at least one restricted item. A checkout that rejects the whole basket because item 14 of 20 is locked will lose you deposits. Filter at the eligibility check, tell the user which items can't be sent, and let the rest through.

## What this is worth adding

Rust players skew toward having inventory they'd rather spend than sell. The items are individually cheap, which makes them psychologically easy to part with, and the [Steam Community Market's cashout restrictions](https://help.steampowered.com/) mean the value is otherwise stuck inside Steam. A platform that turns that into balance is offering something the player genuinely can't get elsewhere.

If you're evaluating providers, the question to ask is whether Rust is actually supported or just technically accepted — whether the pricing engine treats discontinued items properly, whether large multi-item baskets are handled in one flow, and where the value floor sits. Those are the same evaluation criteria as anything else in [choosing a skin payment gateway](/blog/skin-payment-gateways-explained), applied to a market with different failure modes.

AssetPay prices and settles Rust alongside CS2 on the same integration. If you want to talk through the specifics for your platform, [get in touch](/contact) or start with the [merchant API docs](/docs).


---

Written by ruushedd — Covers the merchant side at AssetPay: accepting CS2 and Rust skins, pricing inventory, and running cashouts at volume.