How to Set Up In-World Purchases in Highrise (2026 Guide)

TL;DR

In-World Purchases (IWP) let Highrise World creators sell access, items, boosts, and other benefits to players for Gold. Setting up in-world purchases in Highrise requires two things: creating a product in the Creator Portal and implementing the Payments API in your Studio project to handle the transaction server-side. The process involves prompting the player, validating the purchase on the server, granting the reward through Inventory or Storage, and acknowledging the transaction. Always test with a non-owner account, since the World owner cannot complete their own IWP purchase flow.

---

An In-World Purchase, often shortened to IWP, is a paid product inside a Highrise World. Creators use IWPs to sell access, items, features, boosts, or other in-world benefits in exchange for Gold.

If you are building a World using Highrise Studio and want to monetize it, IWP is the system you need. But it is not a single button you drop into your scene. It is a pipeline with three parts: a product record in Creator Portal, a secure Payments API flow in your Lua scripts, and a persistent fulfillment system that actually delivers what the player paid for.

This guide covers every step of setting up in-world purchases in Highrise, from planning your product to testing the purchase flow in the app.

What Does “In-World Purchase” Mean in Highrise?

An In-World Purchase is a monetization product that lives inside a Highrise World. Players spend Gold to buy it, and the creator delivers whatever benefit was promised, whether that is a VIP pass, a bundle of tokens, event entry, or a cosmetic item.

IWP is different from other ways money moves through Highrise:

• It is not buying Gold itself. Players already have Gold (or buy it from the Highrise shop) and then spend it inside your World.
• It is not an engagement payout. Engagement payouts are based on how much time HR+ subscribers spend in your World. IWP is a direct purchase.
• It is not a Marketplace trade. Marketplace transactions happen between players. IWP transactions happen between a player and your World.

The official IWP documentation defines these products as a way for World Creators to monetize by offering exclusive items, access to special areas, or other benefits in exchange for Gold.

How In-World Purchases Work

Think of IWP as a three-part system. Every working purchase flow needs all three parts.

Part 1: Product setup. You create the IWP product in the Creator Portal. This gives you a product ID, which is the unique string your code uses to reference that specific product.

Part 2: Secure purchase handling. Your Studio script prompts the player to buy (client-side), but the actual purchase validation, reward granting, and acknowledgment all happen on the server. The Payments API documentation makes clear that server-side methods like GetProduct and AcknowledgePurchase are only available on the server, while PromptPurchase runs on the client.

Part 3: Reward fulfillment. After the server confirms the purchase, it grants the reward and persists it through the Inventory API (for items, tokens, or virtual goods) or the Storage API (for progress flags, access unlocks, or VIP status). Without persistence, players lose what they paid for when the session ends.

Here is the flow in plain terms:

Player taps Buy
→ Client calls PromptPurchase(productId)
→ Highrise purchase prompt opens
→ Server PurchaseHandler receives the purchase
→ Server checks product_id
→ Server grants the reward
→ Server calls AcknowledgePurchase
→ Player sees success and gets the benefit

If any step is missing, the purchase either fails silently or, worse, charges the player without delivering anything.

How to Set Up an IWP in Highrise

Step 1: Decide What the Player Gets

Before you write a single line of Lua, decide exactly what you are selling and why a player would want it. Good IWP products are clear about what the buyer receives. Vague labels like “premium upgrade” with no explanation will frustrate players.

A few categories that work well:

• Access: VIP room, private event, tournament entry, backstage area
• Consumables: tokens, extra attempts, temporary speed boosts
• Permanent unlocks: badges, area access, cosmetic world objects
• Social support: tip-the-creator button, event sponsor perk, recognition wall
• Prize loops: buy-in competitions, community games funded through World Wallet

If your product gives a random reward, you must disclose the odds before the player spends Gold. Highrise’s Terms of Service require creators to disclose the odds of receiving each type of random Virtual Item before the transaction. Apple and Google Play enforce the same rule for any mechanism that provides randomized virtual items from a purchase.

Step 2: Create the Product in Creator Portal

You do not start by writing Lua. You start by creating the IWP product record. Your script later calls that product by its product ID.

The official workflow is:

1. Go to Creator Portal.
2. Select your World.
3. Open Monetization, then In-World Purchases.
4. Click Create.
5. Fill in the product ID, name, and description.
6. Create the product.
7. Add an image, enable “List For Sale,” and set the price in Gold.

The product must exist and be listed for sale before the Payments API will work with it in a published World. The Accepting Gold documentation confirms this prerequisite.

Step 3: Add the Product ID to Your Script

The product ID is the bridge between Creator Portal and your code. It is a unique string, and it must match exactly. A typo means the purchase prompt will not appear or the server will not recognize the product.

Good naming conventions for product IDs:

• Use lowercase
• Use underscores
• Include quantity or tier when relevant: vip_pass, tokens_100, speed_boost_1h
• Do not rename product IDs after publishing scripts that reference them

The Payments guide shows example IDs like token_100, token_500, premium_coins, and premium_bundle.

Step 4: Prompt the Purchase

On the client side, call PromptPurchase(productId) when the player taps your buy button. This opens the Highrise purchase prompt where the player confirms or cancels.

One critical warning: the PromptPurchase callback can be a false positive. The Payments documentation explicitly states that this callback should not be trusted as proof of payment. Use it for UI feedback (like showing a “processing” message), but do not grant any rewards based on it.

Step 5: Handle the Purchase Server-Side

This is where the real work happens. Set up a PurchaseHandler on the server that receives incoming purchases. When it fires:

1. Check purchase.product_id to identify what was bought.
2. Grant the correct reward.
3. Reject unknown product IDs.

The Payments API reference confirms that the handler, fulfillment, and acknowledgment must all run server-side. This protects against client-side manipulation and ensures the transaction is trustworthy.

Step 6: Grant and Persist the Reward

Granting the reward means more than setting a local variable. The example code in the Payments guide explicitly warns that storing tokens locally is only for example purposes and recommends using Storage or Inventory for persistence.

Which system should you use?

What the player bought	Best system	Why
Consumable currency, tokens, items, bundles	Inventory API	Designed for player items, currency, and transaction-based operations
Progress, access flags, VIP unlock, quest state	Storage API	Designed for persistent data that survives sessions and restarts
Gold prizes or player rewards	World Wallet	Holds and transfers Gold from a world balance to users

Step 7: Acknowledge or Reject the Purchase

After the reward is granted, call AcknowledgePurchase to tell Highrise the transaction is complete. If something went wrong (unknown product, failed inventory write), reject it instead. Always grant the reward before acknowledging, not after.

Log the transaction on the server: player ID, product ID, reward granted, and acknowledgment result. This log becomes essential when a player says “I paid but got nothing.”

Step 8: Test With a Non-Owner Account

Here is the part that trips up almost every new creator: the World owner cannot purchase their own IWPs. The Payments guide states this directly. You need a second account to test the full purchase flow.

Additional testing notes:

• Use test product IDs goldfish and eel in Studio before uploading your World.
• After upload, switch to your actual product IDs.
• Unity Editor testing does not deduct Gold, so always do a final test in the Highrise app.

If you need to download Highrise on another device for testing, grab it on iOS, Android, or through Steam.

IWP Setup Checklist

Use this before publishing your World:

• Product created in Creator Portal
• Product ID is final and matches your script exactly
• Name and description clearly explain the reward
• Price is set in Gold
• Product is listed for sale
• Buy button calls PromptPurchase client-side
• Server has a PurchaseHandler registered
• Server checks purchase.product_id
• Reward is granted through Inventory, Storage, or another persistent system
• Purchase is acknowledged only after fulfillment
• Unknown products are rejected
• Transaction is logged server-side
• Player receives clear success or failure feedback
• Tested with a non-owner account in the Highrise app
• Random reward odds are disclosed before purchase (if applicable)

Common IWP Mistakes

Creating the button before creating the product

The Payments API needs the product to exist in Creator Portal before the purchase prompt will work. If you build the buy button first and test it, nothing will happen, and you will waste time debugging code that is actually fine.

Trusting the client callback as proof of purchase

The PromptPurchase callback can return a false positive. The official docs warn against using it as the final purchase decision. Always validate on the server through PurchaseHandler.

Forgetting to acknowledge the purchase

If your server handles the purchase and grants the reward but never calls AcknowledgePurchase, the transaction stays in limbo. The Payments API docs require acknowledgment after fulfillment.

Granting rewards only in local variables

A local variable resets when the session ends. If a player buys 100 tokens and you store them in a local table, those tokens vanish on disconnect. Use Inventory or Storage.

Testing with the World owner account

This one catches nearly everyone. The owner cannot complete the IWP purchase flow in their own World. Use a different account.

Selling random rewards without disclosing odds

Highrise Terms, Apple App Store guidelines, and Google Play policies all require odds disclosure before any randomized virtual item purchase. Skip this, and you risk both platform enforcement and player distrust.

IWP vs Payments API vs Inventory vs Storage vs World Wallet

These terms overlap, and the official docs spread them across different pages. Here is how they relate:

Term	What it means	When you use it
IWP	A product sold inside a Highrise World for Gold	When defining what players can buy
Payments API	The Studio API that prompts, handles, and acknowledges purchases	When writing the purchase flow in Lua
Product ID	A unique string referencing the IWP	When connecting Creator Portal to your script
Inventory API	Server-side system for tracking player items and currency	When the purchase gives a player a virtual good or consumable
Storage API	Persistent data storage for progress and flags	When the purchase unlocks access or saves a state
World Wallet	World-level Gold balance for receiving or awarding Gold	When your World needs to fund prizes or reward players
Earned Gold	The Gold creators accumulate from IWP revenue and engagement payouts	When tracking your earnings
Creator Exchange	The cash-out system for eligible Earned Gold	When converting earnings to real money

What Should Creators Sell Through IWP?

The best in-world purchases in Highrise are products where the value is obvious before the player spends Gold. Browse active Highrise Worlds to see what kinds of experiences are already live.

Access products work well because exclusivity has clear value: a VIP lounge, a premium quest line, a private event, or a backstage area.

Consumables like tokens, boosts, and extra attempts are easy for players to understand and easy for creators to fulfill through the Inventory API.

Permanent unlocks (badges, cosmetic world objects, lifetime area access) can command higher prices because they persist. Use Storage to remember the unlock.

Social support products like a “support the creator” button or a recognition wall give players a way to contribute without expecting a competitive advantage. These tend to feel good rather than exploitative.

Prize-loop products tie into the World Wallet. Players buy into a competition, the Gold goes to the World Wallet, and the winner receives a payout. These require clear rules and careful scripting, but they can drive repeat engagement.

Practitioners on Reddit’s r/HighRiseMobileApp frequently discuss how hard it is to earn Gold as a free-to-play user. Players treat Gold as scarce and emotionally loaded. Price your products carefully, and make the benefit unmistakable. If players feel a purchase is vague, overpriced, or unfair, they may avoid your World entirely.

Pricing, Player Trust, and Random Rewards

Player trust is a design problem, not just a marketing one. When setting up in-world purchases in Highrise, the purchase experience itself matters as much as the product.

Show what the player gets before they buy. A name, description, and image should make the reward completely clear. Do not rely on a cryptic product name and hope curiosity drives sales.

Make the cost obvious. The Highrise purchase prompt shows the Gold price, but your own UI leading up to it should also display the cost. Players should never feel surprised by a charge.

Avoid accidental purchases. The FTC has taken enforcement action against game purchase designs that make inadvertent purchases too easy or obscure real-money cost through confusing currency chains. Even though IWP uses Gold inside Highrise rather than direct real-money charges, the UX principle still applies: confirmation steps should be clear, and buy buttons should not be placed where accidental taps are likely.

Disclose odds for random rewards. If your IWP triggers a randomized outcome (a mystery box, a random cosmetic, a loot-style mechanic), you must show the probability of each outcome before the transaction. This is required by Highrise’s Terms of Service, Apple, and Google Play.

Use only official payment flows. Community discussions on Reddit mention scams, third-party Gold, and off-platform payment disputes. Highrise Terms do not recognize third-party services for selling, transferring, or otherwise using Gold outside allowed services. Route all transactions through the Payments API.

A Note on Revenue Share

Public documentation currently shows conflicting numbers about what percentage of IWP revenue creators keep. Some official pages state 70%, while the Payments guide and Support Center reference 90%. Until Highrise confirms a single canonical figure, check the current Creator Portal terms before pricing your World’s products. IWP earnings are credited as Earned Gold according to Highrise’s current creator-economy rules.

Troubleshooting: Why Your IWP Is Not Working

“The purchase prompt does not appear.”

Check these first:

• Is the product ID in your script an exact match for the one in Creator Portal?
• Does the product exist in Creator Portal?
• Is the product listed for sale?
• Are you calling PromptPurchase from the correct client-side script context?
• Are you testing in the right environment? If you have not uploaded the World yet, use test IDs goldfish or eel.

If everything looks correct and the prompt still fails, check Highrise system status for any service issues.

“The purchase completes, but the player gets nothing.”

This usually means one of:

• No PurchaseHandler is registered on the server.
• The handler does not match purchase.product_id correctly.
• The reward is stored only in a local variable (not persisted).
• The Inventory or Storage call failed silently.
• The purchase was acknowledged before fulfillment finished.

“I can’t buy my own IWP.”

Expected behavior. The Payments guide confirms the World owner cannot purchase their own IWPs. Use another account.

“It works in Unity but not in the app.”

Are you still using test product IDs (goldfish, eel)? Those work in Studio before upload. Once the World is published, switch to your actual product IDs from Creator Portal. Also remember that the Unity Editor does not deduct Gold, so you need to test the real flow in the Highrise app.

“Players say they paid, but I don’t see fulfillment.”

Add server-side logging that captures: player ID, product ID, reward granted, acknowledgment result, and Inventory or Storage write result. Without logs, you are guessing. The Payments docs recommend server-side logging and client notification only after the server verifies the purchase.

FAQ

What is an IWP in Highrise?

An IWP (In-World Purchase) is a paid product inside a Highrise World. Creators use it to sell access, items, features, or other benefits for Gold. It is configured in the Creator Portal and delivered through the Payments API in Highrise Studio.

Do I need to create the product before writing any code?

Yes. The Payments API requires a product to exist in Creator Portal with a valid product ID. Your script references that ID, so the product must be created first.

Can I test my own IWP?

Not with the World owner account. The official Payments guide says the World owner cannot complete the purchase flow for their own IWPs. Use a second account to test in the app.

Can I test before uploading my World?

Yes. Use the test product IDs goldfish and eel in Studio before upload. Once the World is published and IWP products exist in Creator Portal, switch to your actual product IDs.

Should I use Inventory or Storage after a purchase?

Use the Inventory API for player items, consumables, currency, and virtual goods. Use the Storage API for persistent progress, access flags, preferences, or world state that needs to survive across sessions.

Do random IWP rewards need odds disclosure?

Yes. If a purchase leads to a randomized outcome, you must disclose the probability of each possible reward before the player spends Gold. This is required by Highrise’s Terms of Service and by Apple and Google Play store policies.

How much do creators earn from IWP sales?

Current public documentation is inconsistent on the exact percentage. Some official pages reference 70%, while others reference 90%. Check the current terms in Creator Portal before making pricing decisions. IWP earnings are credited as Earned Gold, which eligible creators can cash out through the Creator Exchange.

What is the difference between IWP and World Wallet?

IWP is the product a player buys. World Wallet is a Gold balance that belongs to the World itself, which can receive a portion of IWP earnings and award Gold to players. They work together but serve different functions. You set up the in-world purchase to collect Gold, and you can use World Wallet to redistribute it as prizes or rewards.

---

Setting up in-world purchases in Highrise is not just about dropping a buy button into your World. It is about building a reliable pipeline: create the product, script a secure payment flow, fulfill the reward persistently, and protect player trust at every step. Get the fundamentals right, and IWP becomes a real monetization channel for your World.

Ready to build? Download Highrise and start creating, or explore the Highrise community to see what other creators are building. If you have ideas for items or concepts beyond Worlds, check out Highrise Ideas and Highrise Concepts for other ways to contribute to the creator ecosystem.