UEFN In-Island Transactions: Verse Setup That Works in 2026

Quick answer

To sell an item on a UEFN island, you need a Verse-defined entitlement, a valid offer, Marketplace handling, debug-tested grant logic, and a public publish flow that makes the offer live.

This guide is about the working 2026 setup, not a monetization pitch. The goal is to help you wire the Verse side correctly, avoid old tutorial traps, and understand what a purchase actually means for your island.

The key shift is simple: after UEFN v39.10, the transaction model is entitlement-first. If your mental model is still "I sell an item and then run code after a buy button," you are likely to build something fragile.

What you're actually building

You are building a transaction layer: entitlements define what players can own, offers define what players can buy, and Verse decides what ownership changes do inside the island.

"Entitlement" is the official Verse term for a sellable item. The term was renamed in UEFN v39.10 — code and tutorials written before v39.10 break at compilation.

An entitlement is the thing the player receives access to. An entitlement offer is the sellable package attached to it. A bundle offer groups multiple offers when one purchase should grant more than one entitlement or packaged benefit.

Keep those concepts separate. The entitlement is the owned right. The offer is the storefront object. Your gameplay code should react to entitlement ownership, not blindly assume that showing or buying an offer means the player now owns the thing.

You will usually define either consumable or durable items. A consumable is spent, counted down, or used after purchase. A durable item is owned permanently inside the island experience.

A consumable might be a one-use challenge entry, a limited token, a temporary gameplay boost, or a stackable island-only resource. A durable item might unlock a room, class, mode, cosmetic-style island effect, or permanent access path.

Durable items have MaxCount=1 and can be purchased only once. That makes them cleaner for permanent access, but it also means you must validate ownership whenever the player joins, not just when the purchase happens.

Use consumables when the player clearly spends the benefit. Use durable entitlements when the player expects lasting access. Most player-trust problems start when an offer sounds durable but behaves like a consumable.

Before you write Verse: what a sale really pays you

A UEFN in-island transaction pays the creator from post-fee V-Bucks value, not gross retail V-Bucks price, and the temporary 100% post-fee period ends on 2027-01-31.

In-island transactions pay 100% of post-fee V-Bucks value through 2027-01-31, then 50%. The percentage applies post-fee, never on the retail V-Bucks price. In practice that means roughly 74% of retail value survives platform fees (12–30% depending on platform) — so after 2027-01-31, a creator keeps roughly 37% of retail value per sale.

That distinction changes the economics. A 200 V-Bucks offer is not 200 V-Bucks of creator value. The retail price is reduced by platform fees first, then the creator percentage applies to what remains.

Worked example: for a 200 V-Bucks offer, the rough post-fee value is about 148 V-Bucks-equivalent using the ~74% assumption. Through 2027-01-31, the creator receives 100% of that post-fee value, so roughly 148 V-Bucks-equivalent. After 2027-01-31, the creator receives 50% of that post-fee value, so roughly 74 V-Bucks-equivalent.

The post-fee V-Bucks value is what later converts to USD at payout. The full math — fees, the cliff, and what it means for your island economy — lives in the in-island revenue share breakdown.

This is why pricing should be tested against post-cliff economics. A consumable that feels viable during the temporary 100% post-fee period may not survive after the split changes. Design your island economy as if the post-2027-01-31 rate matters.

Engagement payouts are a separate program and are unchanged by in-island transactions. Do not mix engagement revenue and purchase revenue into one fake "sale rate" when you evaluate an island.

Setup walkthrough

A safe UEFN transaction setup defines entitlements and offers in Verse, listens for entitlement changes, validates ownership on join, and keeps purchase flows asynchronous so gameplay does not block.

Start by creating a dedicated Verse file for transactions. Keep it separate from round logic, class logic, and map-specific device wiring. A clean transaction file makes migration and debugging easier.

Use the Marketplace module as the transaction-facing layer. Your gameplay systems should not guess whether the player owns something. They should query or react to entitlement state.

Start from the In-Island Transactions template device (Verse Explorer → right-click your project → Add new Verse file → In-Island Transactions Device). It contains a current reference implementation for the entitlement model, offer definitions, storefront behavior, and purchase handling. Do not copy old pre-v39.10 snippets unless you migrate the vocabulary and logic.

The blocks below are conceptual flows, not runnable Verse — start from the template device and Epic's documentation for the real syntax.

Define a consumable first. You need to state what the player receives, how many units are granted, when one unit is spent, and what happens if the spend action fails. A consumable should not disappear unless the promised gameplay effect actually succeeds.

Concept — validate in UEFN

Consumable entitlement:
  Name: Extra Round Token
  Type: consumable
  Quantity granted: 1
  Spend rule:    remove token only after extra round starts successfully
  Failure rule:  keep token if the round cannot start

Define a durable item next. Durable items have MaxCount=1 and can be purchased only once. Use them for persistent access, not repeat spending.

Concept — validate in UEFN

Durable entitlement:
  Name: Pro Training Room Access
  Type: durable (MaxCount: 1, purchasable once)
  Join rule:    validate ownership when player joins
  Access rule:  allow door / teleporter / class selector only if owned

Create an offer for each entitlement. Price must be 50–5000 V-Bucks, in multiples of 50. Offer and entitlement Name must be ≤50 characters, Description ≤500 characters, and ShortDescription ≤100 characters.

Keep names plain. Do not use Fortnite Item Shop terms or "XP" in offer naming. If the item gives a meaningful gameplay advantage, set ConsequentialToGameplay correctly. If the offer is a PaidRandomItem, disclose the exact numerical odds.

Do not drive grants from the success condition of BuyOffer or ShowOffersDialog. Showing an offer or completing a purchase call is not the same as safely updating island state. Subscribe to GetEntitlementChangedEvent and let ownership changes drive grants.

Let the player open the purchase flow. Epic's guidance is to call BuyOffer or ShowOffersDialog only after a player action, like pressing a shop button. A storefront that pops open on its own removes player agency and is a fast way to get unhappy reviews.

Also validate previous purchases when a player joins, with GetPurchasedEntitlements. This matters for durable entitlements, returning players, and any case where the purchase happened before the current session state existed. Your island should behave correctly even if the purchase event is not fresh.

Concept — validate in UEFN

OnBegin:
  subscribe to GetEntitlementChangedEvent

OnPlayerJoined(player):
  validate existing entitlements
  apply owned durable unlocks
  restore consumable balances if applicable

OnEntitlementChanged(player, entitlement):
  durable    → apply unlock
  consumable → update balance

Define purchase methods with <suspends> and call them via spawn{}. Transaction calls can wait on UI, network, or storefront behavior. Do not let that pause freeze the rest of your gameplay logic.

Concept — validate in UEFN

PurchaseOffer(player) <suspends>:
  open offer or storefront flow
  do not grant from the success condition
  the entitlement change event handles the grant

OnPlayerPressedBuy(player):
  spawn { PurchaseOffer(player) }

Before publishing, check that every defined entitlement is intentional. Active unused entitlements can create a moderation trap if your IARC questionnaire does not declare in-app purchases. The official workaround is to comment out entitlements in Verse until they are actually used. This check belongs in your publishing pass, right next to the IARC questionnaire.

Why your pre-v39.10 code breaks

Old UEFN transaction snippets break because the old sellable-item vocabulary no longer matches the current Verse API — the terminology was renamed to "entitlement" in v39.10, and anything written against the old names fails to compile.

If a tutorial talks about old item definitions, old store objects, or outdated purchase handlers, assume it needs migration. Do not paste it directly into a 2026 project and expect it to compile.

Common symptoms include unresolved identifiers, missing type names, invalid module members, and offer definitions that no longer match the expected structure. The compiler may point to one line, but the real issue is often that the whole snippet uses the old model.

There is another easy compile failure: an entitlement without a valid icon texture path fails to compile. Use a square power-of-two texture for the icon. Do this early so you are not debugging transaction logic when the actual problem is an invalid asset path.

Migration should be boring. First, map every old sellable item to an entitlement. Second, classify it as consumable or durable. Third, rebuild its offer. Fourth, move grant logic to entitlement-change handling.

Migration checklist:
1. Find every old sellable item concept.
2. Rename the concept to entitlement.
3. Choose consumable or durable.
4. Add a valid square power-of-two icon texture path.
5. Recreate the offer around the entitlement.
6. Subscribe to entitlement changed events.
7. Validate previous purchases on player join.
8. Compile before changing the island economy.

Do not migrate and redesign in the same pass. First make the old behavior compile under the entitlement model. Then adjust pricing, bundle strategy, storefront copy, and balance.

Also update your comments. If your code still says "item shop item" everywhere, you will confuse yourself later. Use "entitlement," "offer," and "bundle offer" consistently.

The most dangerous migration bug is partial migration. You rename definitions but still grant rewards from an old buy-success path. The code compiles, but ownership and gameplay state drift apart.

Testing and debugging

Test in-island transactions in Live Edit and Private Playtest debug sessions before publishing, because debug purchases cost no V-Bucks and all granted entitlements are wiped at session end.

Live Edit and Private Playtest sessions are debug sessions. Transactions deduct no V-Bucks in those sessions. All granted and purchased entitlements are wiped when the session ends.

Use the Debug Command menu during testing. On PC, open it with Esc. On controller, open it with Start or Options.

The Store Debug Commands include Open Storefront, Grant All Entitlements, Grant One Entitlement, Force Remove Entitlements, Print Owned Entitlements, and Purchases Always Fail. Use them to test the happy path and the failure path.

Start with Open Storefront. Confirm the right offers appear, names fit, descriptions are clear, and prices match your intended setup. Bad storefront copy is a transaction bug because it creates player confusion before the purchase.

Then use Grant One Entitlement. Check whether your GetEntitlementChangedEvent subscription reacts correctly. The island should grant access or update balance because ownership changed, not because a buy button returned success.

Use Print Owned Entitlements after each test. This catches silent mismatches between what your UI claims and what the player actually owns. It is especially useful when debugging durable access.

Use Force Remove Entitlements to test removal and reset behavior. A durable unlock should disappear when ownership is removed. A consumable balance should not leave stale access behind.

Use Purchases Always Fail to test failed-purchase handling. The player should not receive the entitlement. Your UI should recover cleanly, and gameplay should continue.

Test joins and rejoins. When a player enters the island, validate previous purchases and apply owned durable unlocks. Do not assume the entitlement change event will always happen during the current session.

Test round resets. Consumables should not duplicate, vanish, or spend themselves during a reset unless that is the intended rule. Durable access should survive round transitions.

Players' purchases are final and non-refundable on their side, but creators can process bulk returns via the Creator Portal up to 20 days back. Treat bulk returns as damage control, not QA. If a broken offer reaches players, you need to know which entitlement, offer, and build caused the issue. Keep a small transaction test sheet before public release.

Offers only become live once the island is published publicly. Until then, debug sessions help you test logic, storefront behavior, and ownership handling without charging players.

Frequently asked questions

How much do I earn per sale?

You earn from post-fee V-Bucks value: 100% through 2027-01-31, then 50%. For a 200 V-Bucks offer that means roughly 148 V-Bucks-equivalent now, and roughly 74 after the cliff — the full worked math is in the revenue-share guide linked above.

Do I need the Fortnite Developer Program?

Yes. Per Epic's in-island transactions overview, you need to be enrolled in the Fortnite Developer Program, be at least 18 years old, and accept the updated Fortnite Developer Terms in the Creator Portal (Creator profile → Programs). The island's IARC questionnaire must also declare digital purchases. The publishing walkthrough covers enrollment, IARC, and moderation, so treat in-island transactions as part of publishing, not as a standalone Verse feature.

Consumable or durable — which should I pick?

Pick consumable when the player spends the benefit. Pick durable when the player should own the benefit permanently inside your island.

Consumables fit limited-use value like tokens, entries, boosts, or temporary resources. Durable entitlements fit permanent access like rooms, classes, modes, or persistent unlocks.

If players might reasonably think "I bought this once, so I keep it," use durable. Durable items have MaxCount=1 and can be purchased only once.

How do refunds work?

Player purchases are final and non-refundable on their side, but creators can process bulk returns via the Creator Portal up to 20 days back.

A bulk return targets an island, an offer, and a time window, and Epic processes it within five days. One more rule worth knowing: if you stop transactions less than 20 days before permanently unpublishing an island, the V-Bucks from that final 20-day period go back to players.

That means your offer copy should be precise before launch. If you ship the wrong entitlement or break the grant flow, the Creator Portal bulk return option is your recovery path.

Continue the cluster

In-island transactions are one monetization layer; pair this setup guide with the revenue-share pillar and the engagement-payout guide before designing your full island economy.

Read the revenue-share breakdown next for the post-fee math, the 2027-01-31 cliff, and how V-Bucks value converts to USD at payout.

Then read how engagement payouts work for the separate program. Engagement payouts and in-island transactions can stack, but they are different revenue streams with different calculations.