Building an ARC Raiders-Inspired Reward Deck with AccelByte

One thing I liked about the original Raider Deck system in ARC Raiders was that players didn't have to unlock every reward in sequence. They could spend points on whichever rewards they wanted, and their total spending would gradually unlock access to later tiers. They could even skip rewards from an earlier tier without blocking progression.

From a backend perspective, that seemingly simple experience involves several systems working together: player identity, virtual currency, item purchasing, ownership, progression tracking, and eligibility rules.

To explore how we could build something similar, we created Signal Range: a small, playable Reward Deck prototype using AccelByte Gaming Services (AGS). We'll use it to walk through the backend services involved, where custom logic is needed, and how we handle a purchase that succeeds before progression gets updated.

Try the prototype:

• Play Signal Range

• View the source code

Context: ARC Raiders replaced its original Raider Decks with Reward Passes in the October 8, 2026 Frozen Trail update. Our example is inspired by the earlier choice-based purchasing mechanic, not a recreation of ARC Raiders’ own backend or economy. See Embark’s explanation.

Breaking Down the Reward Deck

At its core, we can think of the system as a collection of rewards divided into multiple tiers. For a simplified example, our deck has:

• Three tiers, with nine rewards in total.

• Rewards priced at 10, 20, or 30 points.

• Tier 1 available immediately; Tier 2 available after spending 40 points; Tier 3 after spending 100.

• Each reward purchasable once.

The key is that access depends on total spending, not on collecting everything from an earlier tier. A player can buy a 10-point Field radio and a 30-point Ridge pack, reach 40 points spent, and open Tier 2 while leaving the 20-point Pathfinder reward unpurchased.

In the live prototype, a new demo player starts with 180 points. Here's how those first two purchases change the player's state:

These values answer different questions. The wallet tells us what the player can spend now. Entitlements tell us which rewards they already own. Deck spending tells us which tiers they can purchase from. Adding more points to a wallet shouldn't, by itself, unlock the next tier.

What Backend Systems Does This Require?

With the player behavior defined, we can map each responsibility to the relevant AGS capability.

Why Use Commerce Instead of Season Pass?

At first glance, this looks similar to a battle pass. AGS already has a Season Pass service for XP-based progression and reward claiming, so why not use that?

The main difference is how players get the rewards. In our example, players purchase individual catalog items using virtual currency rather than reaching an XP tier and claiming rewards from that track. Commerce is a better fit for those transactions, while Statistics records the player’s spending within the deck. Purchasing Requirements then decide which items become available.

This is a design choice for this particular mechanic, not a rule that all reward passes should use Commerce. A traditional XP and claim-based system may be better served by Season Pass.

Following a Reward Purchase Through the Backend

Now let's look at the flow when a player selects a reward. The transaction and the progression update are related, but they aren't the same operation.

1. The authenticated player chooses a reward. The client checks the displayed balance, ownership, and tier eligibility to give immediate feedback.

2. The game creates an AGS order for the selected item. We wait for a fulfilled purchase; creating an order alone is not proof that a reward was bought.

3. Commerce handles the currency purchase and fulfillment. The wallet balance changes, and the reward is granted through Entitlements.

4. Our trusted backend reads the completed order, checks whether its item belongs to this Reward Deck, and works out the total qualifying spending.

5. That total is written to a server-controlled AGS statistic. Store Purchasing Requirements evaluate the statistic when the player tries to buy an item from a later tier.

The important custom rule is identifying which purchases count toward this specific deck. AGS knows the player bought an item, but the game defines how that purchase contributes to Reward Deck progression. We keep that calculation on the server rather than trusting a spending value sent by the client.

In Signal Range, the player UI is built in React/TypeScript and a small server-side worker verifies player identity and reconciles orders. A production implementation could put equivalent trusted logic into your own backend or use AccelByte Extend, depending on your architecture.

Why Keep the Spending Logic Separate?

This separation lets Commerce handle purchases while our game decides how they affect progression. It also gives us flexibility if the design changes.

For example, we might have rewards that do not count toward deck spending, bonus progression that is different from a reward’s price, or multiple decks with their own progression values. We can adjust those rules without replacing the underlying purchase system.

It also means we're not treating the wallet balance as progression. A player might earn additional points, buy unrelated items, or come back later. None of those actions should accidentally advance the deck.

Handling Interrupted Progression Updates

There is one failure case we need to account for: what happens if a reward purchase succeeds, but the progression update fails?

At that point, the player already owns the reward. We shouldn't try to purchase it again or charge them another 30 points just because the spending statistic hasn't caught up.

For Signal Range, the trusted backend can reconcile progression from authoritative AGS Orders. It reads the player’s fulfilled orders for the configured deck items, validates the item, currency, quantity, and price against the deck configuration, and counts each order once. It then calculates an absolute spending total, rather than blindly adding another increment after each callback.

The total is published to AGS Statistics using a MAX update strategy. If one reconciliation reads 40 points and a newer one reads 60, an older update arriving afterward should not reset the player to 40. Repeating the same update should not add the points again, either.

In the current prototype, reconciliation happens when the player connects, around purchases, and when they refresh or retry progression. It is request-driven, not a background process that runs indefinitely. If an order response is uncertain, the client needs to check the authoritative state instead of immediately submitting the same purchase again.

This approach works for our fixed-price, one-time, no-refund example. If we introduce refunds, discounts, repeatable purchases, or multiple currencies, we also need to define how those change the spending calculation. In particular, a MAX-only statistic cannot reduce progress after a refund.

Taking the Prototype Further

Signal Range deliberately keeps the scope small so the core mechanic is easy to follow: one deck, nine durable rewards, one currency, and fixed prices. Before using the same pattern in a live game, we'd make a few additional decisions:

• How players earn the deck currency, and how the game validates those awards.

• Whether discounted purchases count at list price or the actual amount paid.

• How refunds, revoked entitlements, and repeat purchases affect progression.

• How separate decks and seasons are identified, tracked, and retired.

• Whether to add a background trigger for reconciliation, and how much order history it needs to process.

Those are game-specific choices, which is why I find it useful to start with the player rules before choosing endpoints. Once the rules are clear, it's easier to see what AGS already handles and which parts need custom logic.

Planning a Similar Integration with the AccelByte AI Plugin

If you want to explore the same mechanic for your game, the AccelByte AI Plugin can give an AI coding agent AccelByte-specific context about services, integration patterns, and project setup. One useful starting point is describing the behavior you want and asking the agent to map it to existing AGS capabilities.

I want to build a Reward Deck where players purchase one-time rewards using virtual currency. Tier 2 should be available after 40 points of validated deck spending and Tier 3 after 100. Identify the relevant AGS services, the game-specific backend logic, and how to recover if a purchase succeeds but progression does not update. Purchases must not be counted twice.

If you already have an implementation plan, you can also ask the agent to review your service mapping and identify gaps. The plugin helps with planning; you should still verify the purchase conditions, authentication boundaries, and failure behavior in your AGS test environment.

Plugin source and installation: AccelByte AI Plugin on GitHub

Try Signal Range or Explore the Implementation

We built the prototype as a small example you can play with and inspect. If you want to follow the setup in your own namespace, the tutorial goes into the configuration and implementation details that we have only summarized here.

• Play the Signal Range prototype — try buying rewards and unlocking Tier 2 without finishing Tier 1.

• Read the implementation tutorial — configure the wallet, catalog items, statistics, purchase requirements, and reconciliation flow.

• Browse the source code — inspect the UI, AGS integration, backend validation, and tests.