OpenSaaS paid workflows
Working baseline established for authenticated paid workflows and selected adversarial checks.
From the payment boundary to an owned, durable result.
The native application moved from signup and free-credit use through the payment-required boundary, a sandbox purchase, signed entitlement delivery, a paid generation and an independently verified owner readback after reload and fresh login.
Application gates
Selected negative checks
Recorded executions
Authenticated paid workflows
What was verified
The accepted source-bound baseline passed all four application gates. Both authenticated paid workflows produced four durable outputs and returned them through the native owner query.
- Source, build, runtime and browser identity stayed bound to the accepted candidate.
- Native signup and login completed through the isolated email flow.
- Free-credit use reached the payment-required boundary.
- A sandbox purchase delivered the entitlement through the signed provider event.
- Two authenticated paid workflows produced usable durable output.
- Reload and fresh login returned the same owned results.
- The authenticated output query returned only the querying owner’s durable results.
Coverage of this run
Four application gates and fifteen selected payment, ownership and delivery checks were established across forty-six recorded executions.
| Area | Recorded coverage |
|---|---|
| Payment replay | Previously fulfilled, sequential, parallel, restart and alternate-event-ID replays. |
| Credit admission | Two-credit concurrency, one-credit concurrency and zero-credit provider admission. |
| Ownership and authorization | Owned output query, foreign task write and spoofed generation owner. |
| Provider and browser failure | Provider failure, browser disconnect and lost response after output commit. |
| Checkout return | Paid purchase remained usable after the success return was blocked and the browser was closed. |
The preserved payment-failure inventory contains 125 historical families. This OpenSaaS report shows the selected slice executed here; it does not claim that all 125 families ran on this candidate.
Selected negative checks
Each check compared the application’s observed response with the expected safety property and then reopened the relevant state where applicable.
Replay and idempotency · PASS
The same logical invoice stayed a single award when replayed after fulfillment, sequentially, in parallel, after process restart and with a different event ID. Credit balances did not receive a second award.
Credit races · PASS
With two credits and two concurrent requests, both completed and the balance reached zero. With one credit, one request completed and the other received the payment-required response. With zero credits, no provider request was admitted.
Ownership and authorization · PASS
A different purchaser could not change the original owner’s task. A client-supplied owner field did not move a debit or output to another account. The authenticated owner query returned four results, all belonging to that owner.
Provider and browser interruptions · PASS
A provider failure left credits unchanged and created no output. A browser disconnect or lost response after a committed generation still left one charged, owner-readable result available after fresh authentication.
Closed Checkout return · PASS
The paid purchase survived a blocked success return and closed browser. Fresh login showed the entitlement, and the purchaser recovered a usable owned output.
Selected evidence
The full run includes browser, provider, application and database records. These captures show the payment boundary, the paid result and the independent owner readback.
Recommended next verification
Apply the same questions to another application.
Keep payment, ownership, credit and delivery expectations attached to the next source-bound candidate.
Add production-equivalent provider cases.
When authorized, repeat the journey with live-provider behavior, production tax configuration and broader invoice states.
Keep repair evidence connected.
Record the source, environment, observed behavior and independent recheck together for each repair.
Scope boundary
This public sample uses a controlled provider, a Stripe sandbox, isolated test services and fictional application data. It establishes the selected OpenSaaS workflows and their recorded safety checks. Production configuration, live-provider behavior, tax setup, custom integrations and semantic answer quality require separate verification.