How to accept CS2 and Rust skin payments in your store

What a skin payment actually means

Skin payments let a customer use eligible CS2 or Rust inventory items toward a purchase. With Skinloop, your store creates a hosted checkout, the customer follows the trade flow, and your server confirms the payment before delivering the order. A skin payment is not a card payment, and a submitted trade is not automatically a completed payment.

For a merchant, the important question is not just whether a customer has clicked Confirm. It is whether the checkout belongs to the correct account and order, the accepted value covers the expected price, and the authoritative payment state allows fulfillment. This guide focuses on those decisions rather than suggesting that every trade settles instantly.

What you need before connecting a store

• A Skinloop merchant account and an API key with the checkout permissions and games your integration needs.
• A server-side integration, or a storefront platform that implements one. Keep the merchant API key out of browser code.
• A stable HTTPS webhook receiver, plus the signing secret for that endpoint.
• A way to associate a checkout with a specific local order, including its expected merchant, game, amount and currency.
• Return pages that explain payment status without treating a browser redirect as proof of payment.

A platform serving several stores should use each merchant’s own account and credentials. Sharing one API key across unrelated stores breaks account ownership and makes it harder to reconcile payments correctly. This is a key-based integration; creating an API key alone does not configure the platform’s return pages or webhook receiver.

A practical checkout flow

1. Save the order and its expected price on your server before creating the payment attempt.
2. Create a hosted checkout using the merchant’s server-side API key, a merchantOrderId, and an idempotency key for that attempt.
3. Send the customer to the hostedUrl returned by Skinloop, rather than building or accepting a checkout URL supplied by the browser.
4. Let the hosted checkout handle the customer’s eligible inventory selection and trade flow.
5. Use verified webhooks or an authenticated server-side status lookup to update the order.
6. Deliver only after completed status and fulfillmentAllowed: true. Make the delivery operation idempotent.

Follow the documented platform setup and return URL options →

Plan for pending and protected trades

A CS2 payment can remain in a provider hold while the underlying trade is protected. Show the customer that the order is awaiting payment completion, and keep the webhook receiver available. Do not deliver a digital product just because the browser has returned to your store.

CS2 and Rust have separate trade behavior. Do not apply a CS2 countdown to Rust payments, or assume that a particular game always completes immediately. Your integration should rely on the state returned for the specific checkout, not a game-wide shortcut. If a payment is reversed, stop fulfillment and reconcile the order.

Understand the difference between a protected trade and a completed payment →

Keep order value and payouts separate

An inventory item has a discrete value, so a customer’s selected skins can cover more than the requested checkout amount. Your receiver should validate the original required amount and currency against the order, then handle legitimate overpayment according to the documented fields. Overpayment must not silently change the quantity of goods delivered.

The trade value, the completed payment, the merchant’s settled balance and a payout request are related but different records. Skinloop supports USDT payout requests from settled funds; a pending or protected trade is not immediately available money. Do not promise a payout date based only on the time the customer started checkout.

Check the failure paths before launch

• A duplicate webhook must not cause a second delivery.
• A success return URL must not mark an unpaid order as paid.
• A held payment must remain pending even if an estimated release time has passed.
• A canceled, failed or reversed payment must not authorize fulfillment.
• A changed API key must still belong to the merchant expected by the installation.

Start with one storefront integration and validate its complete order lifecycle. Add more supported games or store platforms only when you have verified their actual behavior. A working payment button is the beginning of the integration, not the final acceptance test.

Read the guide to safe payment webhook processing →