Payment Security in Vibe Coding: Two Vulnerabilities AI Always Misses

A practical article on payment security in AI-built products has appeared on Habr. Its author, a vibe coder with no professional development background, breaks down two vulnerabilities that AI-generated code reproduces without fail and describes five layers of defense he arrived at through his own experience.

Why AI

Code in Payments Is More Dangerous Than an Obvious Bug

The article's key thesis: a neural network does not write bad code. It writes code that looks like it works. That distinction matters. The basic scenario runs fine: the user clicks "pay," the money arrives, the test is green. The vulnerability stays invisible until an attacker finds it, not the developer.

"The most expensive screw-up in this kind of work is not that the neural network writes bad code, but that it writes code that looks like it works," the author writes in the

Habr article.

That is why a payment module is a special risk zone: a hidden error here does not mean a crashed app, but direct financial losses, for the product or for its users.

Two Holes the Neural Network Reproduces Systematically

The author singles out two failures typical of AI-generated payment code:

• Price tampering: the server accepts the amount from the body of the client request without checking it against the real price in the database. An attacker changes the value in DevTools and pays an arbitrary amount for the product, even 1 ruble.
• No webhook verification: the server accepts payment notifications without checking the signature from the payment provider. This lets an attacker send a fake transaction confirmation and get access to the product without a real payment.
• AI assistants reproduce both patterns regularly: in training data, such checks often look like "implementation details" and get omitted.

According to the author, the neural network does not close either vulnerability automatically. You have to request the fix explicitly or check for it manually after the code is generated.

How to Test Your Product Before Release

The author describes a concrete technique: before handing off the product, open it in incognito mode, with no saved tokens, cookies, or authorization, and try to complete a payment with altered request parameters. The goal is to imitate an attacker's actions while there is still time to fix the code.

For a vibe coder with no team and no code review, this technique replaces both a security audit and testing: the only real barrier is your own view from the attacker's side.

Five Layers of Defense

The article describes five layers of payment-module defense that the author developed in practice. In his words, AI skips all five on the first generation: without an explicit request in the prompt or a manual check, they will not be in your code. Details of each layer are in the full text; according to the article, they cover server-side validation of incoming data, protection against repeated requests, and auditing of payment events.

What This Means

Vibe coding has lowered the barrier to entry in development, but it has not changed the security requirements the real world places on products that handle payments. AI confidently generates the basic flow logic but systematically skips protection at the boundary between client and server. Anyone building products with neural networks needs an explicit checklist for critical points, or an expensive lesson in production.

Frequently Asked Questions

Which vulnerabilities does a neural network miss in payment code?

According to the Habr article's author, two patterns are missed systematically: client-side tampering with the payment amount (the server takes the price from the request without checking it against the database) and missing signature verification of the payment provider's webhook. Both allow a transaction to go through without real payment.

How can a vibe coder check payment security before release?

The author recommends the clean-session technique: open the product in incognito mode without authorization and try to complete a payment with altered parameters. This imitates an attacker's actions and exposes the vulnerability before the product reaches production, with no team and no code review.