Not translated yet — showing English.

Catalog & Commerce

Items, prices, wallets, storefronts, purchases, entitlements. Real store integrations where the platforms allow them (Stripe, App Store, Google Play, Steam, Xbox); scheduled, audience-targeted storefronts; and a purchase flow whose every step is hookable.

When to use it

• You sell things, for real money through Stripe, App Store, Google Play, Steam or Xbox, or for wallet currency.
• Storefronts must resolve per player: schedule, audience and price computed server-side, never eligibility math in the client.
• Pricing rules belong in one testable hook: discounts, repricing and vetoes run before any charge.
• Receipts must be replay-proof, and a refund must revoke the entitlement through the same events the grant used.
• Skip it when items are never sold. Rewards still land through commerce's one Grant with origin reward (Leaderboards cycle chests arrive that way), so even a shopless game keeps a single auditable grant ledger.

Who does what

At a glance

// client — the storefront arrives already resolved for this player
var front = await playserv.Commerce.Storefront("main");
var order = await playserv.Commerce.Purchase(front.Items.First(), pay: Pay.Wallet("gems"));

// client — the storefront arrives already resolved for this player
const front = await playserv.commerce.storefront('main');
const order = await playserv.commerce.purchase(front.items[0], { pay: Pay.wallet('gems') });

# client — the storefront arrives already resolved for this player
front = await playserv.commerce.storefront("main")
order = await playserv.commerce.purchase(front.items[0], pay=Pay.wallet("gems"))

// client — the storefront arrives already resolved for this player
Client->Commerce->Storefronts->Select().Then(
    TPSOnResult<TPSPage<FPSStorefront>>::CreateWeakLambda(this, [this](const TPSResult<TPSPage<FPSStorefront>>& Result)
    {
        if (!Result.HasValue()) { return; }
        const FPSStorefront& Front = Result.Value().Rows[0];
        Client->Commerce->Orders->Create(FPSIdempotencyKey(CartId), Front.Items[0], FPSPay::Wallet(TEXT("gems")));
    }));
// co_await support ships later: a built-in SDK coroutine wrapper that respects Unreal's GC and threading.

// client — the storefront arrives already resolved for this player
var front = await playserv.Commerce.Storefront("main");
var order = await playserv.Commerce.Purchase(front.Items.First(), pay: Pay.Wallet("gems"));

[Before(Commerce.Purchase)]                    // veto or reprice
public static Verdict FirstBuyDiscount(PurchaseIntent p) =>
    p.Player.Purchases == 0 ? Hook.Continue(p.WithPrice(p.Price * 0.5m)) : Hook.Continue(p);

[After(Commerce.Purchase)]                     // grant — side effects only
public static Task Grant(Purchase done) =>
    done.Player.Inventory.Grant(done.Item, done.Count);

// veto or reprice
export const firstBuyDiscount = before(Commerce.purchase, (p: PurchaseIntent) =>
  p.player.purchases === 0 ? Hook.continue(p.withPrice(p.price * 0.5)) : Hook.continue(p));

// grant — side effects only
export const grant = after(Commerce.purchase, (done: Purchase) =>
  done.player.inventory.grant(done.item, done.count));

@before(commerce.purchase)                     # veto or reprice
def first_buy_discount(p: PurchaseIntent) -> Verdict:
    return Hook.continue_(p.with_price(p.price * 0.5)) if p.player.purchases == 0 else Hook.continue_(p)

@after(commerce.purchase)                      # grant — side effects only
async def grant(done: Purchase):
    await done.player.inventory.grant(done.item, done.count)

The model

What a catalog item declares.

What composition is allowed to be.

What a storefront declares.

A storefront whose audience a player does not fall into does not exist for that player.

An order's states.

Each extension point names the type it hands the hook: a purchase intent before the purchase — player, offer, provider, price — and the purchase itself after. A hook never receives an untyped bag.

Errors

• Outside the audience answers not found, and repeating is pointless. Outside the schedule also answers not found, but is worth repeating once the window opens.
• The provider is unavailable and the provider declined the payment are deliberately different answers: the first is unavailable and retryable with backoff, the second a conflict that retrying will not fix.
• An invalid receipt is a validation refusal; a receipt already consumed by another order or another player is a conflict — that is what makes replay useless.
• The price changed between reading the storefront and buying is a precondition failure: re-read and decide again, rather than being charged the new price silently.
• Insufficient game currency is a conflict, not forbidden: the permission to buy is held, the balance isn't enough. Worth repeating after topping up.
• A durable entitlement already held is a conflict.
• The region or age does not permit the purchase answers forbidden, and repeating is pointless.
• The order's deadline has passed is a conflict: create a new order.
• The spending limit exhausted answers as a conflict or a rate limit depending on which limit it was, and it states when the limit resets.

Limits

The numbers arrive with the platform limits chapter; what happens at each ceiling is fixed now.

• The catalog's size: publishing another item is refused as a conflict.
• Storefronts per project: creation is refused.
• Offers in a storefront: an addition is refused; the storefront is never truncated silently.
• The lifetime of an order awaiting payment: a transition to expired, with an event.
• The rate of purchase attempts: a rate limit with a deadline.
• The spending limit per period: a conflict that states when the limit resets.
• Retention of orders: past the declared period an order is no longer readable, rather than vanishing without explanation.
• Entitlements per player: a grant is refused, and those already granted are never evicted.
• A price's precision is not a limit but a type: an integer in minor units.