foldrun 2.10.9 → 2.10.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/budgets-and-billing.md +17 -10
- package/package.json +1 -1
|
@@ -370,9 +370,11 @@ when. If the invoice is still unpaid when the grace ends, the hourly sweep
|
|
|
370
370
|
suspends the account for new runs with the reason **payment overdue**, and
|
|
371
371
|
one more email says so; the banner turns red. Runs in flight finish, people
|
|
372
372
|
can still sign in, nothing is deleted. The moment `invoice.paid` arrives
|
|
373
|
-
for it — or `invoice.voided
|
|
374
|
-
|
|
375
|
-
|
|
373
|
+
for it — or `invoice.voided` or `invoice.marked_uncollectible`, which is
|
|
374
|
+
how a debt is written off — the suspension is lifted, and a payment gets a
|
|
375
|
+
thank-you email. The subscription ending does not settle it: the plan
|
|
376
|
+
ends, but an invoice it left unpaid is still owed and still payable, and
|
|
377
|
+
the account stays paused until it is paid or written off. Every step is once per invoice, however often
|
|
376
378
|
Stripe retries or redelivers; a second invoice failing during the grace
|
|
377
379
|
does not restart it. Dunning lifts only a suspension it placed: an account
|
|
378
380
|
the super admin suspended for another reason stays suspended. The super
|
|
@@ -496,7 +498,7 @@ is `<public url>/api/billing/stripe`, sending exactly:
|
|
|
496
498
|
| `invoice.voided` | an overdue invoice cancelled; dunning ends |
|
|
497
499
|
| `invoice.marked_uncollectible` | an overdue invoice written off; dunning ends |
|
|
498
500
|
| `customer.subscription.updated` | a plan swap, or a status change |
|
|
499
|
-
| `customer.subscription.deleted` | the plan it paid for ends;
|
|
501
|
+
| `customer.subscription.deleted` | the plan it paid for ends; what it left unpaid stays owed (dunning and its pause stay) |
|
|
500
502
|
| `payment_intent.succeeded` | an auto top-up credited |
|
|
501
503
|
| `payment_intent.payment_failed` | an auto top-up refused; the warning goes |
|
|
502
504
|
| `charge.refunded` | a refunded top-up's credits come off |
|
|
@@ -504,12 +506,17 @@ is `<public url>/api/billing/stripe`, sending exactly:
|
|
|
504
506
|
| `charge.dispute.closed` | won: it goes back on; lost: it stays off |
|
|
505
507
|
|
|
506
508
|
Every delivery is logged — the event, the account, what was done or the
|
|
507
|
-
error, and a hash of the payload
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
|
|
509
|
+
error, and a hash of the payload. Since 28 Oct 2026 the event itself is
|
|
510
|
+
kept too, for the types above only, up to 256 KB, set when it first
|
|
511
|
+
arrives and emptied after **180 days**: Stripe keeps events for 30, and a
|
|
512
|
+
replay after that needs a copy. It carries what Stripe sends (names,
|
|
513
|
+
emails, addresses, a card's last four digits — never a full card number),
|
|
514
|
+
so only the super admin's console reads it and lists never load it. The
|
|
515
|
+
super admin lists the log at `GET /api/admin/stripe-events` and replays
|
|
516
|
+
one event with `POST /api/admin/stripe-events/<id>/replay` — Stripe's copy
|
|
517
|
+
while Stripe has it, the kept copy after — through the same handler; every
|
|
518
|
+
write it makes is keyed once, so a replay of an event that was handled
|
|
519
|
+
changes nothing.
|
|
513
520
|
|
|
514
521
|
## Plan gates
|
|
515
522
|
|