ForHosting KIT · Math

Expected payoff calculator for games and gambles

A 10 % chance to win 100 adds 10 to the average, while a 50 % chance to lose 10 takes away 5. Enter every result with its probability and see the long-run average per play, in the same unit as your payoffs. Free in your browser.

Free
Runs in your browser
No sign-up
Your data stays on your device

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

Worked example

If you enter

Payoffs: 100, 20, -10
Probabilities: 0.1, 0.4, 0.5

You get

Expected payoff: 13
Probability sum: 1
Outcomes: 3

The expected payoff is the probability-weighted average result of a game, gamble, promotion, or other uncertain choice. Enter one payoff for every possible result and the corresponding probability of that result. The calculator checks that both arrays have the same length, that every probability is valid, and that all probabilities sum to one before doing any arithmetic. It then returns the expected payoff in the same unit as the entered gains and losses.

How expected payoff summarizes a game or gamble

Expected payoff combines every possible financial or point result with its chance of occurring. For each result, multiply the payoff by its probability, then add all those products. A ten percent chance to win 100 contributes 10 to the average, while a fifty percent chance to lose 10 contributes negative 5.

The final total is the long-run average payoff per play if the same game could be repeated many times under unchanged conditions. It is not a promise about the next attempt: a lottery ticket may have a negative expected payoff even though one buyer wins a large prize, and a favorable game can still lose on a single play. Positive values indicate an average gain, negative values indicate an average loss, and zero describes a fair game before fees or other costs.

Because the output retains the unit of the payoffs, dollar entries produce a dollar expectation, point entries produce a point expectation, and percentage-return entries produce an expected percentage return. This single number is useful for comparing alternatives, but it does not describe volatility, worst-case loss, liquidity, personal risk tolerance, or whether repeated play is actually possible.

Preparing payoff and probability arrays correctly

Provide two parallel arrays named payoffs and probabilities. Their positions define the pairing: the first probability belongs to the first payoff, the second probability belongs to the second payoff, and so on. Include gains as positive numbers, losses as negative numbers, and a no-change result as zero.

Probabilities must be ordinary numeric values from zero through one, not percentage strings. For example, twenty-five percent should be entered as 0.25. Every distinct and mutually exclusive result should appear once, and the listed results should cover all possible outcomes.

Consequently, the probabilities must total one. The calculator allows a very small tolerance for normal floating-point representation, but it rejects a genuinely incomplete or overallocated distribution. It also rejects empty arrays, different array lengths, non-numeric entries, infinite values, and probabilities outside the permitted range.

Before submitting a model, check whether fees, ticket prices, taxes, refunds, or retained stakes belong inside each payoff. A prize of 100 from a ticket costing 5 may represent a net payoff of 95 rather than 100, depending on the question being answered. Consistent net or gross treatment is essential for a meaningful result.

How to read the result with care

Expected_payoff is the weighted sum used for comparison. Probability_sum confirms the accepted distribution totaled one, while outcomes reports how many payoff-probability pairs were evaluated. When comparing games, keep currencies, time horizons, stake sizes, and definitions of payoff consistent.

An expected gain of 2 on a stake of 10 is not directly comparable with an expected gain of 2 on a stake of 1,000 without considering return on stake and exposure. Likewise, two choices can have equal expected payoff but radically different chances of ruin. Use this result as a first decision statistic, then examine the distribution and practical constraints when consequences matter.

The implementation uses a bounded, deterministic pass through the arrays and never calls a model, external service, random generator, or clock. That makes it suitable for reproducible worksheets, game-balance tests, educational tools, and automated checks. Store the original inputs alongside the output so later reviewers can verify how each probability was paired with its payoff.

What you can do with it

Compare promotional games

Weight every prize, discount, and losing result by its probability to compare the average cost or benefit of campaign designs.

Check a wager before playing

Combine net wins and losses with their chances to see whether a bet is favorable, fair, or unfavorable on average.

Test game economy balance

Calculate the expected coins, points, or resources awarded by randomized mechanics with explicit outcome probabilities.

FAQ

What formula does the expected payoff calculator use?

It calculates the sum of each payoff multiplied by its corresponding probability.

Can a payoff be negative?

Yes. Enter losses and costs as negative finite numbers, gains as positive numbers, and neutral results as zero.

Can I enter percentages such as 25%?

Enter probabilities as numbers between zero and one, so 25 percent is 0.25 rather than a percentage string.

Does a positive expected payoff guarantee a win?

No. Expected payoff is a long-run weighted average and does not predict the result of one play or measure the risk around that average.

Should ticket prices or fees be part of each payoff?

Yes. Put fees, ticket prices, taxes or refunds inside each payoff before you calculate. A prize of 100 from a ticket that cost 5 is a net gain of 95, and that net figure is what belongs in the list.

Related tools

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/stat/expected-payoff

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/stat/expected-payoff \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payoffs":[100,20,-10],"probabilities":[0.1,0.4,0.5]}'

const res = await fetch("https://api.kit.forhosting.com/stat/expected-payoff", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "payoffs": [
      100,
      20,
      -10
    ],
    "probabilities": [
      0.1,
      0.4,
      0.5
    ]
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/stat/expected-payoff",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "payoffs": [
        100,
        20,
        -10
    ],
    "probabilities": [
        0.1,
        0.4,
        0.5
    ]
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/stat/expected-payoff", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"payoffs":[100,20,-10],"probabilities":[0.1,0.4,0.5]}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"payoffs":[100,20,-10],"probabilities":[0.1,0.4,0.5]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/stat/expected-payoff", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "payoffs": [
    100,
    20,
    -10
  ],
  "probabilities": [
    0.1,
    0.4,
    0.5
  ]
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "stat.expected_payoff",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

max_items 10000

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Technical notes

The calculation is deterministic, runs free in the browser, and costs $0.002 for each successful API request.

Interpreting results and using the API safely

The response includes expected_payoff, probability_sum, and outcomes. Browser calculations are free, and a successful API item costs $0.002; invalid inputs are rejected instead of producing a misleading number.

Technical questions

Do probabilities have to sum to one?

Yes. The complete probability array must sum to one within a small floating-point tolerance, or the request returns invalid_input.

Read the full KIT documentation →

Run — free