Payouts

Pay Robux from your group to the people who earned it: drafted by one person, approved by a second once the run is large enough, released with an authenticator code, and checked once more by an isolated service that pays only what was approved.

What payouts are

A payout run pays a list of Roblox users from your group's funds, in one batch. You build it by hand on the Payouts page or from payroll rules, and it walks the same path either way. Roblox publishes no API for group payouts, so the payment itself is made with a Roblox account cookie, by a separate service that is the only thing able to read it.

Payouts are part of Plus and Max. Plus pays out up to 50,000 Robux a month and Max up to 250,000, within the workspace's own limits below.

Before you start

You need	Why
Plus or Max	Payouts, payroll and schedules are part of the paid plans.
The Payouts module	It is where runs are built, approved and released, and where the credential and schedules live.
A verified email and an authenticator app	Using payouts at all needs both. Connecting the credential, releasing a run, a second approval and anything done to a schedule each ask for a fresh code.
The right permissions	`payouts.view` reads, `payouts.run` builds runs and sets up schedules, and `payouts.approve` approves and releases. No single role may hold both `payouts.run` and `payouts.approve`.
A payout credential	A Roblox account that can pay out from your group.

The payout credential

Roblox lets a group pay out only through its website, signed in as an account allowed to spend the group's funds, so Rostack needs that account's .ROBLOSECURITY cookie. A cookie acts as the whole account, not one group permission, so use an account that owns nothing you would mind losing and can do nothing in the group beyond paying out.

The website encrypts the cookie the moment it arrives, with a key it can encrypt with and never decrypt, and stores only the ciphertext. Only the payout service can decrypt it, and only inside the request that pays. The security page describes exactly how.

If Roblox asks for a challenge

Roblox sometimes asks the payout account to confirm a payment with its own security prompt. Nothing is paid, the run goes back to approved, and a notice says so. Clear the prompt on that account, then release the run again.

A run, from draft to paid

the path a run walks

draft                 built by hand, or by payroll
  │  submit           payouts.run
  ▼
pending_approval
  │  approve          payouts.approve; once the run is large enough,
  │                   a second person, with an authenticator code
  ▼
approved
  │  release          payouts.approve, with a fresh code
  ▼
executing ──▶ settled | failed

A run can be cancelled until it is released. At or above the second-approval threshold, 50,000 Robux unless the workspace set another, the approver may not be the person who prepared it: both the Roblox user and the account have to differ, so one person with two accounts is still one person, and the approval needs a code from their authenticator. Releasing always needs a fresh code, because drafting and approving can be undone and releasing cannot.

Roblox pays only people who have been in the group for 14 days. Anyone a run cannot pay is recorded on it as a skipped line with the reason, not quietly dropped.

Limits

Limit	Default	What it means
Per person, per run	100,000	A line above it is recorded as skipped, not paid.
Per run	1,000,000	A run above it is refused.
Per calendar month	5,000,000	A run that would cross it is refused whole.
Second approval	50,000	At or above it, somebody other than the person who prepared the run approves it.
Plan allowance	50,000 on Plus, 250,000 on Max	Robux paid out in a calendar month (UTC). A run that would cross it is refused whole.

The payout service keeps ceilings of its own, set where the service is deployed rather than in the database: 1,000,000 Robux in one run and 100,000 to one person. No setting in Rostack raises them.

What releasing does

Releasing moves the run to executing and names that release in one step only one person can win, so two people pressing Release at once cannot pay twice. The website then asks the payout service to pay that release. It does not tell the service who to pay: the service reads the run from the database itself and pays only a run being released under that exact release, started in the last five minutes, approved as its size requires, to the recipients and amounts recorded on it.

What happens	What you see
Roblox accepts the payment	The run is settled, each line is written to the ledger, and every monthly limit counts it.
Roblox asks for a challenge	Nothing is paid. The run goes back to approved, and a notice asks you to clear the challenge and release it again.
The payout service refuses	Nothing is sent. The run fails with the service's reason, and a notice says so.
Roblox refuses the payment	The run fails with Roblox's reason, and a notice says so.
No answer in time	The run stays executing and is not retried, because the payment may still have landed. Check the group's transactions on Roblox before doing anything else.

Schedules

A schedule pays a fixed list of people on its own, weekly, every two weeks or monthly, at an hour you choose in UTC. It is the one place money moves with nobody present, so the consent is given in advance, and it is specific.

Step	What it takes
Setting it up or changing it	Someone with `payouts.run`, with a code. Any change to who, how much or when is a new version, and a new version has no approvals.
Approving it	Someone with `payouts.approve`, with a code, naming that version. At or above the second-approval threshold, somebody other than its author has to approve.
When it fires	Rostack checks again that every approver still holds the permission at their live Roblox rank and still has the authenticator they approved with. If anything changed, it drafts the run for a person to release instead of paying. If Roblox cannot answer, it waits for the next check, and after about an hour drafts the run or pauses the schedule rather than guess.
How often it can pay	A monthly or weekly schedule pays at most once per calendar month or week, and a biweekly one at least thirteen days after its last payment, even when its timing is changed.
Pausing, changing or deleting it	Stops any payment it has not sent yet. Pausing, resuming and deleting each ask for a code.

Schedules need Plus or Max, which also sets how many can exist at once: 5 on Plus and 25 on Max. On Free, a schedule pauses at its next run instead of paying.

The record

Every step writes an entry to the audit log with the actor, the reason and a trace id. A failed run, a challenge and a schedule that could not build its run each raise a notice in the dashboard, and in Discord when the workspace has connected it. Paying for Rostack and paying your staff never meet: they run on separate systems, with separate keys.