docs: clarify Premium recurring top-up setup

[anhtho-lago]

Context

The recurring top-up guide currently omits the Premium requirement and uses an expired 2022 wallet date in both API examples. A buyer following those examples could misread what is included or create a wallet that has already expired.

Description

• Mark recurring rules as a Lago Premium capability, matching the current API license guard.
• Link the existing Stripe setup guide for automatic paid collection and state that purchased credits become usable after payment succeeds.
• Remove the expired optional wallet dates from both examples and correct the threshold tab's label.

Validation

• pnpm exec mint validate passed locally.
• git diff --check passed.
• GitHub validate and Mintlify Deployment checks passed.
• The hosted HTML preview and Markdown fallback both returned HTTP 200 and contain the corrected wording. The fallback has no expired 2022-07-07 date.

This corrects one guide; it does not claim an end-to-end Premium Cloud and Stripe test. The guide should still be tested with a Premium Cloud organization and Stripe test connection before using it as a verified buyer benchmark.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
lago-docs	🟢 Ready	View Preview	Oct 17, 2026, 5:41 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[sarkissianraffi]

No blockers.

What held up (checked against lago-api main, not the PR text)

• Premium gate: Wallets::RecurringTransactionRules::CreateService#call returns early unless License.premium?, and Wallets::UpdateService guards recurring_transaction_rules the same way. The new note is accurate.
• Credit availability: Invoices::PrepaidCreditJob grants credits only when the payment status is succeeded (and not paid by credit note). "Available only after payment succeeds" matches.
• The Stripe guide path guide/payments/stripe-integration.mdx exists on this branch, so the link resolves.
• The only 2022 date in the file is gone. The threshold tab label fix (interval to threshold) is correct against the surrounding steps.

Non-blocking

• The note says the purchase invoice is marked succeeded. The API field is payment_status. Consider payment_status set to succeeded so integrators can map it to the field.
• The threshold example still shows invoice_requires_successful_payment: true next to the new note. Consider one sentence on how that flag interacts with credit availability, since it is the setting that decides whether the invoice finalizes before payment.
• The PR says no end-to-end Premium plus Stripe test was run. I did not run one either. Mint validate was not re-run by me; I only checked the content claims.

Merge order: no overlap found with the other open PR touching the wallet guides. Safe to merge on its own.

---

Generated by Claude Code