A credit-based software balance should be explainable from purchases, usage and explicit adjustments. Review that ledger separately from the payment provider: a successful charge establishes a payment fact, while the application still has to decide how credits are granted and consumed.
The Stripe catalogue, observed on October 3, 2026, includes PDFtoMarkdown.ai. Its listing describes PDF conversion through a web interface, API and MCP, with pay-per-page Stripe credits. The directory has not tested its current charging rules, credit expiry or failed-conversion policy.
Define the unit before the balance
For document processing, ask what counts as a billable page. Blank pages, unsupported files, repeated submissions and partially completed documents can expose ambiguity in a simple per-page label.
Write the rule in customer language, then identify the record that supports it. A user should be able to connect a deduction to a particular job and its accepted input, rather than seeing only an unexplained lower balance.
If a quote is available before processing, distinguish the estimated requirement from the final deduction. Explain what happens when the estimate changes, and obtain the necessary authorization before exceeding the customer's accepted scope.
Separate purchase retries from credit grants
Stripe documents idempotent API requests so a matching retry can reuse the first result rather than repeat an operation. Keys have retention semantics, so that mechanism is not a substitute for a durable application record of which purchase granted which credits.
Give each confirmed purchase one grant identity. A repeated notification or a support replay should locate that grant rather than add another balance increment. Preserve the historical amount and currency even if the current credit package changes later.
Keep test-provider records visibly separate from production purchases. A sandbox success is useful integration evidence, but it is not customer revenue or a legitimate production credit grant.
Review concurrent jobs and failures
If several jobs can run together, define whether credits are reserved before work starts or deducted afterward. Two jobs should not both assume they can spend the same final credits without a documented policy.
Use small synthetic documents in an authorized test environment. Submit concurrent jobs around a known balance and inspect the resulting reservations, completions and remaining credits. Record every outcome rather than only the successful conversion.
For a failed job, ask whether the reservation is released, the deduction is reversed or a partial charge remains. The correct answer follows the stated product policy; it should not depend on which worker happened to report first.
Make support adjustments traceable
An adjustment should have an amount, reason and link to the relevant purchase or job. Avoid editing the current balance without preserving how it changed. That makes later reconciliation possible and prevents one support correction from hiding another issue.
Compare the reconstructed balance with the number shown to the user. Report any unresolved difference as an investigation item rather than silently normalizing the records.
Recurring subscriptions introduce different questions about time and plan changes. The Stripe subscription change review covers that boundary without treating a subscription credit and a prepaid usage credit as interchangeable.
Stardew Valley Tracker
IcyZip
Xeramail Temp Mail