Connecting Steam login to VIP purchases
A VIP purchase on DeadlockRust.gg connects three systems: the website, a payment provider, and the Rust game server. The player buying a rank on the website needs to be the same player who receives it in-game.
Integrating Steam login with third-party payments was one of the challenges in this project. Security was a priority, particularly around how the application identifies the player and passes that identity into checkout. Here’s how the current flow works.
Start with the Steam account
The website sends players to Steam to sign in using OpenID. When Steam redirects them back, the backend asks Steam to validate the response. After a successful response, it stores the Steam ID in an application session using iron-session.
That identity is what the checkout endpoint uses. Although the browser submits a product selection, the backend reads the player’s Steam ID from the session. It does not use the Steam ID sent in the browser’s checkout request to decide who the customer is.
This distinction matters: a value supplied by the browser should not be enough to establish which account is making a purchase.
Connect that identity to PayNow
The checkout endpoint requires a signed-in Steam account. It then looks up a PayNow customer by Steam ID, creating one if no matching customer exists.
Next, the backend requests a customer token and uses it to create a PayNow checkout for the selected product. The website sends the player to the checkout URL returned by PayNow. The API credentials used for these requests are read from server-side environment variables.
The sequence is:
- Sign in through Steam.
- Read the Steam ID from the application session.
- Find or create the matching PayNow customer.
- Create checkout and redirect the player to PayNow.
- Deliver the purchased group through PayNow’s in-game plugin.
Deliver access on the game server
PayNow’s in-game plugin handles delivery by running a console command that assigns the player ID to a group. This is the connection between the web purchase and the player’s VIP access on the Rust server.
The website’s custom payment webhook is not the delivery mechanism in the current deployment. Keeping that distinction clear is important when tracing where a purchase goes and which system is responsible for granting access.
Purchases have been tested, and the website’s current main branch is deployed. That confirms the tested purchase flow; it does not establish that every failure or retry scenario has been covered.
Security is ongoing work
Using the session identity for checkout and keeping API credentials on the backend are specific parts of this implementation. They are not a claim that the entire integration is security-complete. Authentication review and fulfillment reliability remain areas for further verification.
This project connects frontend interaction, backend authentication, an external payment API, and a game-server plugin. Following the Steam ID through those systems makes the integration easier to explain and reason about.
See the DeadlockRust.gg project overview for more about the application.