Payment proof

Mystra reaches your Stripe Checkout and never pays. It presses the upgrade button, waits for checkout.stripe.com, reads the plan name and amount, stops, and then checks that the paid area is still gated for the fresh account.

How does Mystra test Checkout without paying?

The pay step starts from the upgrade page you configured, or from an Upgrade, Pricing or Billing link the runner finds on its own. It presses the plan button, follows a plan dialog if one opens, and waits for the browser to land on checkout.stripe.com. On that page it reads what Checkout shows, the product name and the total, and records it as a check such as Checkout shows `Pro · $79.00 per month`. The Stripe price id and plan name you enter under Path settings are shown on the run next to it, for comparison. Then the runner leaves. It never focuses the card field, never types a number and never presses Pay, so the session Stripe created simply expires, the way an abandoned checkout from a real visitor would. Nothing appears in your Stripe balance and no customer is charged. Because every action is one a visitor could take, the same configuration is safe on production with live Stripe keys.

What is proven

• Your app creates a Checkout Session for a brand-new account and hands it to Stripe with the right plan, so the price id, the mode and the success and cancel URLs your server sends are all working.
• The plan and amount Checkout shows match what you expect, which catches a price id swapped in a deploy or an environment variable missing from production.
• An account that has not paid does not see the paid area. After leaving Checkout the runner performs the access proof and expects it to fail. A paid area that opens without payment is a broken run, with the screenshot as proof.

What is not proven

That a completed payment unlocks access. Proving that needs a purchase on your Stripe account, real or 100% discounted, and a webhook round trip, which Mystra does not do today. The gate check is the closest safe substitute: it proves the two halves that break most often, the hand-off to Stripe and the wall in front of paid content. The guide How to test a Stripe Checkout flow without paying walks through the ways to cover the last part by hand, including a 100%-off promotion code and a real card followed by a refund.

What a price mismatch means

A different plan name or amount on Checkout does not fail the run, because pricing pages change on purpose. It is there to be read: open the run detail and compare the Checkout shows check with the plan you configured. Update the plan in settings when the change was intended; when it was not, you have found a deploy that changed your prices.

What it leaves behind on Stripe

Depending on how your app creates sessions, Stripe may show an incomplete Checkout Session and, if you create the customer before checkout, a customer object with the run's throwaway email, run-<id>@inbox.mystra.run. Neither carries a charge. The cleanup webhook tells your app when the run is over so it can delete the account and, if you want, the Stripe customer with it.