CS2 trade protection: when is a skin payment complete?
Understand Steam trade protection, Skinloop payment holds, release estimates and why a timer alone cannot authorize order delivery.
The short answer: wait for verified completion
A protected CS2 trade is not a completed Skinloop payment. Merchants should deliver an order only when an authenticated checkout response or a verified webhook confirms completed status and fulfillmentAllowed: true. Neither a browser return nor an expired countdown replaces that confirmation.
This distinction matters most for irreversible delivery: activating an account balance, sending a license key or releasing an item can be difficult to undo. Treating a protected trade as cash before completion moves that risk into your store.
Steam protection and the payment hold are not the same clock
Steam’s official support page says Counter-Strike 2 items received in a trade are Trade Protected for seven days. During that window, the items cannot be consumed, modified or transferred, and the trade can be reversed under Steam’s rules.
Skinloop’s platform documentation separately describes CS2 payments that can remain in a provider hold for eight days once the hold begins. That is the payment integration’s documented hold behavior, not a claim that Steam’s protection period itself is eight days. Do not calculate merchant completion by adding seven days to an order creation timestamp.
Read the current payment state
- created: a hosted checkout exists, but no trade is attached yet.
- pending or active: processing or trade progress is visible; this does not authorize delivery.
- hold: the CS2 payment is under the provider hold; keep the order reserved and unfulfilled.
- completed with fulfillmentAllowed: true: verified completion permits fulfillment.
- reverted: the payment was reversed; do not fulfill, and reconcile if delivery may already have happened.
- reconciliation_required: the outcome is ambiguous; stop automatic fulfillment and investigate.
Not every intermediate state must appear. A provider can skip observations, and notifications can be delayed or repeated. A store that requires an exact sequence of statuses can get stuck even when the current authoritative status is clear.
What if the estimated release date has passed?
An estimated release date helps explain the hold, but it is not a payment-completion command. A holdUntil value is informative. Your application must not mark an order paid, credit a customer balance or deliver products simply because its local clock has crossed that time.
- Retrieve the current checkout state from your server using the merchant’s authenticated API access.
- Compare the result with the latest verified payment event, rather than only the browser’s cached display.
- If the authoritative payment is completed and fulfillment is allowed, process the order through the normal idempotent fulfillment path.
- If the status still indicates a hold or an uncertain outcome, keep the order pending and ask support to investigate the checkout.
For support, keep the public checkout or payment ID and the relevant timestamps. Never send an API key, session token or webhook signing secret in a customer-facing screenshot. Avoid starting another payment attempt for the same order while the existing trade may still complete.
Checkout expiry does not cancel an attached trade
Before a trade is attached, a checkout deadline can expire. After attachment, a pending, active or protected trade can continue beyond that original offer deadline. Skinloop’s state map explicitly distinguishes checkout expiry from cancellation of a trade.
A later reversed state must also be taken seriously, even if a previous observation showed completion. Reconciliation means checking the payment and local order history before taking another business action; it does not mean automatically collecting a second payment from the customer.
Give customers a clear status message
Use a pending treatment rather than a green payment-success message while a hold is active. Keep the explanation focused on the customer’s order. Separate the payment’s completion from the merchant’s later balance availability or payout request.