You describe the shop you want to an AI builder. It writes the screens, the cart and the product pages, and then you type “add payments”. With one payment provider this goes better than most people expect, and a test card goes through on the first or second try.
This post is not about AI being bad at payments. It is about one specific moment that comes a little later: the checkout works, the business grows, and you ask the tool to add a second provider, then a third. That is where the work changes shape, and where a lot of vibe-coded checkouts start to wobble.
One provider is the easy case
With a single provider there is one API to learn, one webhook format, one set of statuses and one set of test cards. Popular providers have plenty of public examples, so the tool has seen the pattern many times and reproduces it well.
What you end up with has been proven for exactly that: one provider, a test card and the happy path. That is a fair thing to have after an afternoon. It also means “it works” has a narrow meaning. It works for that provider, in the cases you tried.
Why the second provider is a different kind of task
Adding a second provider is not just more of the same. You are now asking for one checkout to behave consistently on top of systems that each do the same job in their own way. The differences are small enough to look harmless and large enough to move money:
- Amounts. Some providers take the smallest currency unit, so 2000 means twenty dollars. Others take a decimal, 20.00. Currencies such as the yen have no minor unit at all, and some have three decimal places.
- Statuses. Every provider has its own words for authorised, captured, settled, waiting for the customer and failed, and they do not map one to one.
- Proof of a webhook. Some sign the exact bytes they send. Some sign a chosen set of fields. Some expect you to call back to confirm the notification is real.
- Declines. A declined card is an HTTP error with one provider and a successful response carrying a “failed” state with another.
- Retries and duplicates. How a notification is resent, and how you make a create-payment call safe to repeat, is defined per provider.
- Refunds. Full or partial, instant or only after settlement, within a window or not. We covered this in refunds across multiple payment providers.
How generated code tends to grow
Here is a pattern that is easy to recognise. You ask for a second provider. The tool copies the first provider’s handler and edits it, or adds a branch for the new provider inside the existing one. Both versions work in a demo.
Over the next few weeks the shape shows. The rule that an order must never move backwards lives in two places, and a fix made to one is not made to the other. A third provider arrives as a third copy that is slightly different again. The tests you ran covered the first provider, so the new code has not been exercised until a real customer pays through it.
There is a quieter issue too. A provider’s API changes over time, and a tool’s memory of it can be older than the provider’s current documentation. For one provider you notice quickly. For three you are relying on three separate memories.
None of this is a flaw in the tools. It is what happens to any codebase where the same job is written several times by hand, and people do it too. The difference is that when you build by prompting, nobody is reading all three copies side by side.
The other way to structure it
The alternative is to integrate once, against an API that does not change when your providers do. With PaymentHood your app makes one create-payment call, receives one kind of webhook signed one way, and reads one set of payment states. Providers are connected in the Console. Adding the second or third is a setting there, and it does not add a branch to your code.
For the AI that is a much smaller job: one contract, written once and checked once. Your checkout stays the same size however many providers sit behind it, and the failure modes in the list above stay behind the API instead of inside your project. If you want the background on why people add providers in the first place, see the limits of a single payment processor and how payment orchestration works.
Give your AI the ready-made prompt
We publish ready-made prompts for Lovable, Bolt.new, v0, Replit, Base44, and for coding agents such as Cursor, Windsurf, Claude Code and GitHub Copilot. Each one states the rules that generated payment code most often gets wrong:
- amounts are decimals in major units, computed on the server;
- the keys live in the platform’s secret store and never in the browser or the chat;
- the webhook signature is checked on the raw body, inside a time window;
- the order is updated from reading the payment back, not from the webhook body;
- the handler is safe to run twice and never moves an order backwards;
- an order is paid only when the payment is Captured.
Each prompt also says where that particular tool runs server code and how to expose a public webhook address, which is the part that changes from tool to tool.
The steps are short. Create a sandbox app in the Console and add a provider. Copy the prompt for your tool and paste it into your project. When the tool asks, add the three secrets (App ID, API key and webhook secret) through its secure form. Then pay with a test card and watch the order go from pending to paid.
A prompt gives the tool a better first draft. It does not replace a test payment, so run it in sandbox before any live money moves. The prompts are written against PaymentHood’s documented API, and the page says plainly that PaymentHood is not affiliated with any of these tools.
Whichever way you build, test it
If you have more than one provider, repeat each check once per provider, because the bugs live in the differences:
- Amount. Pay 1.00 in sandbox and confirm the dashboard shows exactly 1.00.
- Signature. Send the webhook endpoint a request with a wrong signature. It must be rejected.
- Replay. Send the same valid notification twice. The order must change once.
- Order. Send a failure after a success. The order must not go backwards.
The longer version is in test your checkout before you go live, and the reasoning behind the webhook rules is in webhook verification and reconciliation.
Where to start
Pick your tool on the AI builders page, copy its prompt, and try it in sandbox. To see which providers you could connect behind that one integration, browse the provider directory.
Frequently asked questions
Can an AI builder add a second payment provider to my app? Yes, it can write the code. The risk is not that it cannot, but that each provider has its own rules and the same logic ends up written several times. That is easy to miss when only the first provider has been tested.
Do I need a separate integration for each provider with PaymentHood? No. Your app integrates with PaymentHood once. Providers are connected in the Console, so adding another does not change your code.
Will the prompt work in my AI tool? The prompts are written for the tools listed on the AI builders page. Any tool that can run server-side code and keep a secret can follow the same contract: create a payment, send the customer to the checkout, verify the webhook, then read the payment back.
Do I still need to test the result? Yes. Run it in sandbox with a test card and the four checks above before going live. Generated payment code should never go live untested.
Create a free PaymentHood account, or go straight to the AI builders page and pick your tool.