Refund guarantee: the 30-day window, and how it is enforced

Full refund within the window your workspace sees - 30 days today - of your workspace’s FIRST paid charge, once per workspace, ever. It has to be the first charge, not merely the first time you ask: pay for several months, then change your mind about an early one, and that month is outside the guarantee. The promise is try it, and if it is not for you, get your money back - not a standing option on any month you later regret. The window is a row the platform owner can move, never a number baked into the app, so what your workspace actually sees is whatever this page and Billing ▸ Invoices agree on at the moment you ask, not a fixed thirty written here.

After the window closes, fees are non-refundable and the term you paid for is served out to its end. Cancelling stops the next renewal; it does not claw back the payment you already made. A downgrade takes effect at your next renewal too, never mid-cycle, so there is no cash back for the unused part of a term you already paid for.

1. 1

   1. Ask, from a specific charge

   A workspace owner or admin opens Billing ▸ Invoices and, on an eligible charge, clicks Ask for a refund and gives a reason. A plain member cannot do this, and cannot even see whether the workspace is eligible - that answer is the workspace’s revenue timeline, and the server refuses the question from anyone who is not an owner, admin or the platform.

2. 2

   2. The amount is computed, never typed

   There is no amount field anywhere, in the screen or underneath it. The request names a charge and a reason; the database works out what that charge is owed back, checks the window, the once-only rule and the usage exclusion against the actual policy row, and that is the number shown before you confirm. A pending request can be withdrawn; once it is approved, withdrawing it is no longer offered, because approving is the seller’s side of the transaction agreeing to pay.

3. 3

   3. Only the platform approves

   Enforced in the database, not the screen: a workspace owner can request their own refund, and cannot approve it, whatever their role says. A workspace owner who could approve their own refund would not have a refund guarantee, they would have a withdrawal facility.

4. 4

   4. Approving agrees to pay; a worker actually pays

   Approval marks the request payable - it does not move money by itself. A background worker then claims it, calls Stripe once with an idempotency key that was minted the moment the request was made, and reports back what happened, so a retried worker or a doubled click can never refund the same request twice.

5. 5

   5. What lands when it succeeds, or does not

   On success the money returns to the original payment method and a credit note is issued against the original invoice, so the books move with the money rather than a number appearing on a card statement that nothing in the ledger explains. If Stripe fails the attempt, the request goes back to Approved, not to a dead Failed - the decision to refund still stands; one attempt at paying it did not, and a fresh attempt follows.

Status on your own Billing ▸ Invoices row reads Pending, Approved (refund on its way), Refund in progress, Refunded, Rejected (with the platform’s note, if one was given), or Refund attempt failed (WorkBOS will retry; the approval still stands). The platform sees every request from every workspace under Platform ▸ Billing ▸ Refunds, with a count of what is waiting for a decision shown right on the tab.

Resellers: a reseller’s own end customers claim against the reseller, under whatever policy the reseller itself publishes - not against WorkBOS, and not through any WorkBOS screen. WorkBOS in turn refunds the reseller, on the reseller’s own first paid charge to WorkBOS, through this exact same mechanism: a reseller is an organisation like any other, so its owner asks from its own Billing ▸ Invoices and the platform decides the same way.