07.05 · Walkthrough
The Payment Code Your Agent Wrote
Audit a generated payment integration against this course, and find the missing pieces in the handler rather than in the provider call that looks correct.
Generated payment code is safest to review at the handler boundary, not at the SDK call. The critical checks are authentication, authorisation, server-owned amounts, account ownership, webhook verification, idempotent event handling, and making fulfilment or payouts depend on trusted local state rather than redirects or client flags.
What this lesson answers
- how to audit generated payment integration code
- where payment handler security bugs usually hide
- what to check before trusting payment webhooks
Notes
When an agent writes a payment integration, the provider call is often the least suspicious part. Creating a checkout session, payment intent, transfer, or payout can look perfectly valid because SDK examples make that part easy. The real audit is around the handler: who is allowed to call it, what server-side state it trusts, how it maps users to accounts, how it handles retries, and whether the final business action waits for a verified provider event instead of a browser redirect or client-supplied flag.
A good mental model is that payment code has two halves: the outgoing request to the…
Common questions
- Why can a correct payment provider call still be unsafe?
- The provider checks whether its API request is valid, not whether your product rules were enforced. It cannot know which user owns an order, whether an amount was calculated on the server, or whether a connected account is allowed. Those decisions belong in your application handler.
- What should I review first in agent-generated payment code?
- Start with every route and webhook handler. Identify what crosses the trust boundary, then check authentication, authorisation, server-side lookup of orders and amounts, account mapping, webhook signature verification, retry behaviour, and whether state changes are idempotent. The SDK call is usually the easy part.
- Should fulfilment happen after a redirect from checkout?
- No. A browser redirect is not proof that money moved successfully. Fulfilment should wait for a verified provider event, processed by a server-side webhook, and the resulting local database transition should happen once. Client-supplied success flags should not trigger business actions.
Short definition: what is Payment Code Your Agent Wrote?