---
title: "What checkout can refuse"
description: "Why a purchase can stop before it starts, what the delayed confirmation means, and why the answer is almost never to pay a second time."
updated: "2026-08-28"
verifiedAgainst:
  - apps/web/app/api/billing/create-checkout/route.ts
  - apps/web/lib/server/checkout-intent-fence.ts
  - apps/web/lib/server/workspace-subscription-activation.ts
  - apps/web/lib/server/dormant-checkout-subscription-preflight.ts
  - apps/web/components/plan-gate.tsx
  - apps/web/lib/refund-terms.ts
---

A workspace can have one checkout open at a time, and that checkout is written
down before Stripe is ever called. Almost everything on this page follows from
those two facts, including the reason a refusal is usually protecting you from a
duplicate charge rather than standing between you and one.

<Callout variant="warning" title="Do not pay again">
  None of the states below is fixed by starting a second purchase, and none of
  them is a sign that the first one failed to reach us. If a card has already been
  accepted, a second attempt is the only thing on this page that can actually cost
  you money twice.
</Callout>

## Something else is already open

<PropertyList>
  <Property name="Another checkout for this workspace is already open">
    You started a purchase somewhere else, on different terms, and it has not been
    finished or closed. Go back to it, or close it, then choose again. Two
    concurrent purchases on different terms is exactly what this prevents.
  </Property>
  <Property name="This checkout is already being prepared in another tab">
    The same purchase, on the same terms, is mid preparation. It is not stuck.
    Wait a moment and try again, and it will hand you the session it was already
    building rather than opening a second one.
  </Property>
</PropertyList>

## A previous payment is still being reconciled

An earlier subscription payment reached us and has not finished being applied.
The workspace stays closed until it has been, and starting another checkout is
refused rather than allowed to stack a second subscription on top of the
unfinished one.

Contact [hello@blogged.dev](mailto:hello@blogged.dev) rather than retrying. This
is the one refusal on this page that will not clear on its own.

## Something changed while the purchase was being prepared

Between choosing a plan and paying for it, the thing being bought has to still be
the thing you agreed to. Three checks run at that moment, and each stops before
any money moves.

<PropertyList>
  <Property name="This Project stopped being active">
    The Project was archived, or otherwise left the active state, while checkout
    was prepared. Nothing was charged. Refresh and start again.
  </Property>
  <Property name="This Project's entitlement changed">
    The Project's signup benefit is no longer the one the purchase was priced
    against, usually because another session changed it. Nothing was charged.
    Refresh and review the current terms before continuing.
  </Property>
  <Property name="Choose this Project's paid plan first">
    A Project created as a paid sibling has no plan yet, and setup, publishing and
    generation all refuse until it has one. This is not a failed purchase; it is
    the purchase not having happened yet. See
    [creating a Project](/workspaces/projects).
  </Property>
</PropertyList>

## Confirming your subscription

After a successful payment you may see a short waiting state rather than the
product: **payment went through, and Stripe has not confirmed it to us yet.** It
usually clears in seconds.

<Callout variant="danger" title="This is the state that costs people money">
  A wait is not a failure. Leaving this screen and buying again is how one
  subscription becomes two. If it has not cleared after a few minutes, contact
  support with the workspace name instead of paying a second time.
</Callout>

If confirmation genuinely cannot be completed, the product says so in those
words rather than leaving you on a spinner.

## When delivery cannot be completed

Occasionally a payment succeeds and the exact entitlement it bought cannot be
delivered: the set of Projects it was priced against changed underneath it, or
reconciliation could not verify that Stripe holds exactly what our records say it
should.

Blogged retries. After five failed attempts it stops, cancels the new
subscription, and refunds the charge. Access stays closed throughout, which is
the point: you are never left paying for a subscription that was never applied.
In the rare case the reversal cannot be completed without a person, it is raised
for support rather than left alone.

<Callout variant="warning" title="This is not the Refund Policy">
  These two are unrelated and it is worth keeping them apart.

  The automatic cancel and refund above is a machine undoing a purchase that could
  not be delivered. It needs no request, has no conditions and no window, and it
  is not something you can ask for.

  The [Refund Policy](/billing/plans#refunds) is the separate, human one: a first
  paid charge, asked for within 168 hours, on a Project that has generated almost
  nothing. Being refunded by the first has no bearing on your eligibility for the
  second.
</Callout>

## What none of this changes

No refusal on this page deletes content, cancels an existing subscription, or
alters a Project's plan. Every one of them stops before the charge, or reverses
it in full. Your posts, topics, knowledge and blog are untouched in all of them.

## Related

<CardGrid>
  <Card title="Plans" href="/billing/plans">
    What is being bought, and the refund conditions.
  </Card>
  <Card title="Changing a plan" href="/billing/change-plan">
    Moving a Project up or down once it is paid for.
  </Card>
  <Card title="Coming back after cancelling" href="/billing/reactivate">
    Why reactivation buys the whole portfolio at once.
  </Card>
</CardGrid>