Suppose you run Field Notes, a Node.js app that small teams use to write site reports. You're adding a monthly plan that lets them export PDFs, and you want a coding agent to build it. To connect the buy button to the API, the agent needs to know who can purchase the plan and when a workspace gains or loses access. Those choices also determine whether a team can export reports when a renewal payment fails.
Give the agent one billing task you can review from the buy button through the first renewal. Describe who buys the plan, what the workspace gets, and what the app should do when a payment fails or a customer cancels. Ask the agent to show how each rule works in the deployed test app.
Describe the plan in terms of the customer's work
In this example, Field Notes saves its records in Postgres and offers one monthly plan with no trial. Each workspace has one billing owner who can start or cancel the plan. Other members can export reports while the workspace has paid access. Spell out those roles so the agent knows what to do when an ordinary member tries to buy the plan.
When the billing owner cancels, Field Notes keeps exports available through the period the team has already paid for. If a renewal fails, the app shows a warning and keeps access open for a limited time. Decide how long that grace period lasts and tell buyers when exports will stop. Put both rules in the task so the code and the offer make the same promise.
Tell the agent which decisions the server makes
The browser can send a plan name such as monthly, and the API can use that name to look up the allowed price. The API also checks that the caller owns billing for the workspace, since a caller can edit a browser request to try to pay one cent or charge another team's account.
Ask the agent to link the workspace to its payment records using stable IDs. That link should still point to the right workspace if the owner changes their email address or uses the same address for several teams.
For a direct Stripe integration, hosted Checkout is a reasonable first choice. Your server creates a Session for the recurring price and sends the buyer to Stripe's payment page. You can use this flow without first building your own card form. Stripe Checkout Session API
Keep secret keys on the server. Give the agent setting names and safe sample values in its task. It can write code against those names while the account owner supplies the real values through the proper settings.
Ask for access that survives a closed tab
Suppose a Field Notes billing owner pays and closes the browser before returning to the app. The workspace should still gain exports, so the server needs a way to learn about the payment even if the return page never loads. Stripe fulfillment guide
Ask the agent to show where the app receives the notice, how the app verifies who sent it, and which row in Postgres it updates. Send the same notice again and check that the workspace still has one plan with exports enabled for the same paid period.
The same task should cover renewal failure and cancellation. The server may receive those notices while nobody is signed in. Ask the agent to turn each one into the access rule you wrote earlier. Stripe documents the later invoice and subscription events you can use. Stripe subscription webhooks
Review a buyer's journey and an outsider's request
Use two test workspaces. Pay for the first and call the export API. Check that the PDF opens and contains the expected report. Then sign in as a member of the second workspace and try to use the first workspace's payment or report ID. The API should reject the request.
This catches a different class of bug from a broken checkout. Payment can be correct while access goes to the wrong team. A hidden button won't protect the API from a caller who sends the request directly.
Ask the agent to record the release, safe test IDs, and what it expected and observed. Leave the event delivery check open until a real sandbox notice reaches the deployed route. A test that calls the handler directly can cover its logic, while the sandbox notice also shows that the provider can reach it.
Give the same task to Forte
For Field Notes on Forte, start with a Sandbox Project and createSubscription for the single monthly plan. The first charge uses Stripe Elements, and the card is saved for later renewals. A plan sold with a one-time setup fee uses createCheckout. Keep that fee out of the recurring plan lines so it doesn't renew. Forte subscriptions, Forte Checkout
Connect payment triggers to the API Service that sets export access. The handler uses Forte's trusted-header checks to verify the call and must leave access correct if the call arrives again. Forte handles the documented charge and renewal flow, while your app checks workspace ownership and decides which exports the plan allows.
Live payments require approved compliance registration. Review the current feature limits before committing to a live launch. Start with the subscription guide, then give your agent the Field Notes rules adapted to your own app.