How to Price Your Game Passes to Get Exact Pending Token Payouts

Define the target and the transaction model

Begin with the whole amount you want credited from one sale. In this tutorial, the model assumes the creator retains seventy percent and the platform deduction accounts for the remaining thirty percent, with the creator amount rounded down to whole Robux. Those assumptions must match the applicable transaction before the result is useful. A desired payout is not the same as an account's pending balance, and this page cannot inspect either. Write the units beside your target so a dollar goal is not accidentally entered as a Robux amount. The reverse calculator answers a narrow pricing question; it does not establish eligibility, settlement timing, or business profit after other costs.

Calculate the required listing price

Divide the target by 0.70 and round upward to the next whole Robux. For a target of 1,000, the division gives approximately 1,428.571, so the listing price is 1,429. Verify it by applying the forward calculation: floor of 1,429 multiplied by 0.70 is 1,000. A listing of 1,428 would return only 999 under the same model. The upward rounding therefore matters even when the shortfall is only one token. Adding thirty percent to the target is not equivalent: the deduction is taken from the final listing amount, so the gross-up must use division by the retained share rather than a simple markup of the target.

Understand why small prices behave differently

Whole-token rounding has a larger visible effect on small transactions. A listing price of 101 produces a modeled payout of 70, leaving a deduction of 31. Calculating and rounding the fee independently can create an inconsistent total. Keep the sale price, creator credit, and deduction connected: compute the credit first, then subtract it from the price. If you project many identical purchases, calculate the per-sale credit before multiplying by the purchase count. A percentage applied once to combined gross revenue may produce a different estimate. This is why a statement containing many small purchases can disagree with a spreadsheet that rounds only the final monthly sum.

Use exact arithmetic when implementing the helper

The example below uses integer-oriented arithmetic for bounded whole-number targets in Luau. It is a teaching helper, not an account integration. Validate the input and keep values within the range your application can represent precisely. The formula computes the ceiling of one hundred times the target divided by seventy. The forward assertion checks the result using the equivalent whole-number ratio. A production quote should still be compared with the actual charged price and applicable transaction category. Keep the helper in one place so a future fee change is not applied in one screen and forgotten in another. Tests should include zero, a small target, and a target that does not divide evenly.

local function listingForTarget(target)
    assert(type(target) == "number" and target >= 0
        and target <= 1000000000 and target % 1 == 0,
        "Use a bounded, nonnegative whole-Robux target")
    return math.floor((target * 100 + 69) / 70)
end

local price = listingForTarget(1000)
assert(price == 1429)
assert(math.floor(price * 70 / 100) == 1000)
assert(math.floor((price - 1) * 70 / 100) == 999)

Account for price adjustments and sale context

The price shown in a reference listing is not always the amount charged in every transaction. Regional pricing or other platform pricing features can affect the purchase amount. If those features apply, check how the buyer-facing price and credited revenue are determined instead of treating the reference-price calculation as an unconditional promise. Retrieve appropriate platform price information for the actual interface and avoid hard-coded labels that become misleading. Keep avatar-item commissions separate from the gamepass model, because their creator and affiliate shares can differ. An exact mathematical answer is exact only for its stated inputs. It cannot compensate for using the wrong price or a fee structure that belongs to another product category.

Build a transparent quote or funding milestone

If the target funds a contractor milestone, describe the deliverable and payment basis before sharing the listing price. Specify whether the milestone is defined in net Robux, a gross listing amount, or another currency. If several milestones are paid separately, calculate each separately and review the combined customer cost. Keep a dated record of the assumptions and state when the quote needs to be refreshed. Do not conceal an additional charge after the customer accepts the scope. If the required price is too high, reduce the deliverable or change the arrangement through a clear agreement. The calculator should make the discussion easier to understand, not create a false impression that fees can be avoided through a numerical trick.

Reconcile the real transaction after settlement

When the sale appears in your transaction records, compare the amount charged, deduction, credited earnings, and status with the original model. Investigate any mismatch before repeating the estimate across a large forecast. Keep pending, credited, and settled figures distinct in your notes. Refunds, reversals, review conditions, or another sale context can affect usable earnings. Even a correctly credited amount is not automatically cash available for spending. The useful outcome of this workflow is a repeatable record: target, assumptions, required price, forward verification, and actual result. Over time that record can show which scenarios the model predicts well and which need a separate calculation rather than an unexplained correction factor.