Picture the first payment test for Audit Pad, a Next.js app that sells a monthly plan for exporting audit notes. You deploy a test copy, buy the plan with a test card, and check that the charge matches the offer and that your workspace can export a note. Before switching to live payments, test what the deployed app does when a card is declined, a notice arrives twice, or the next month's charge fails.
Rehearse those cases with synthetic data and check whether the workspace can export after each billing change. Set up and review the live app separately so you can verify where its requests and events go.
Keep every part of the test in the same environment
In this example, Audit Pad uses an API and Postgres. Give its test website a test API, database, and payment environment. Verify which API the site calls, which database the API uses, and where the payment provider sends events. A staging page can look right while sending a purchase to the live API.
Use a synthetic workspace with a name you can recognize in safe logs. Record its ID and the expected plan. Keep real customer files and card details out of the exercise.
Stripe sandboxes let you simulate payments without moving money. Use test keys and documented test payment values. Stripe warns against testing with real card details in live mode. Keep genuine business transactions separate from your test cases. Stripe testing guide
Start with a complete browser journey
Sign in as Audit Pad's test billing owner and buy the plan. Check that the payment record matches the price shown at checkout and points to the workspace that made the purchase. Then call the export API and open the file to see what the purchase lets the team do.
Next, use the documented decline and card-authentication cases. A buyer who needs to confirm their card should see the next action. A buyer whose card is declined should have a clear way to try again without losing track of the first attempt. Stripe test scenarios
Close the tab after a successful payment and before returning to the app. Reopen Audit Pad and check access. The server event path should finish the purchase even when the browser doesn't return. Stripe fulfillment guide
Keep the purchase reference visible while the app waits for a result. If the buyer refreshes, show the same pending order so support can find the original attempt.
Test the event route on its own
Send the same valid event again and check that access doesn't grow twice. Try two copies at once if the handler can receive concurrent requests. Then send a request without valid proof of its source and check that the route rejects it.
A synthetic request helps test what the handler does after a notice arrives. To check delivery, complete a sandbox payment through the deployed app and find the matching provider notice in the deployed API's request history.
Save expected and observed results separately. If the handler passed a local test but the public route hasn't received a provider notice, keep that delivery check open. It gives the next reviewer a precise gap to close.
Move through later billing states
Subscriptions keep changing after the first session. Rehearse a successful renewal, a failed renewal, a repaired card, and cancellation. After each case, check the billing record and the actual export API against your written access policy.
Stripe Billing has test clocks that advance simulated time for supported subscription tests. They can help exercise later invoices and events without waiting a full month or year. Follow the setup and limits in the current guide. Stripe Billing testing
Stripe's test clock advances simulated time in Stripe Billing. If your billing layer schedules renewals separately, use its supported test path to check how it creates the charge. Record that result separately from an event replay, which shows how the handler responds once a renewal event arrives.
Practice a support request
Try a refund and inspect the access result under the chosen policy. Cancel a plan and check its paid-through date. Retry a failed export after payment without creating a fresh charge.
Give the person on support the workspace ID and order reference and ask them to find the payment, the notice about it, and the last access change. See whether someone who didn't write the handler has enough information to help the buyer.
Save safe evidence with the release commit and list any cases that still need to run. If you time the rehearsal, use that result to plan support for this app. A broader claim about launch speed would need more than one run.
Review live settings as a fresh setup
Inventory the live price references, credentials, event destination, public return address, and allowed origins. Check which objects and settings must be created again for live use. Confirm who can stop new purchases if the first real buyer gets stuck.
Use a read-only review after deployment to confirm that the intended environment is selected. Show setting names and safe IDs, without exposing secret values. Leave the test environment available so later fixes can use the same rehearsal.
Rehearse the Forte path in a Sandbox Project
Forte sends Sandbox Project payment calls to its Stripe test-mode path. Start Audit Pad there, create the subscription, confirm the first charge, and inspect payment and access records. Live payments require approved compliance registration. Forte subscriptions
Use forte payment-triggers test for the documented local handler test. It sends the trigger shape without making a real payment state change. Pair that check with a real sandbox payment against the deployed Service. Forte local trigger tests
If the offer includes a setup fee, rehearse the Checkout flow too. Check the first mixed charge and the later subscription separately so the one-time fee doesn't become part of the renewal.
Create a separate live Project when you're ready. Sandbox mode is fixed at project creation, so you cannot turn the test Project into the live one. Repeat the settings review and keep live approval and renewal checks open until their own evidence is complete. Forte project modes