The preview click is the cheap part
A checkout screen is one of the faster things an AI tool produces. Describe the product, the price and the button, and you get a page with a cart, a quantity field and a pay button that behaves correctly in a preview. For a small business that is real progress: the part of the project which used to absorb a developer for a fortnight now takes an afternoon.
What the preview cannot show is the moment money moves. Behind that button sits an account that has to be opened, a bank account that has to be verified, a currency that has to be chosen, a tax position that has to be right, and someone who has to notice when a payment fails at eleven at night. None of it is generated, because none of it lives on the page.
So the site launches with a convincing demonstration of a payment rather than a payment. The gap appears at the first real order, which is exactly when you can least afford to find it.
What stands between a checkout and an accepted payment
The payment account comes first, and it takes longer than the page. A provider asks “who is selling, where the business is registered, where the money should land and how refunds are handled”, then reviews the answers before it moves anything — a review measured in days. Until it is finished, every button on the site is a mock-up with a logo on it, and no generated code shortens the wait.
Selling online also makes you the seller of record. Someone decides which currency the customer sees, which currency the business is paid in, what the receipt says and how the sale is reported. Those are questions for your accountant and your jurisdiction, not for a language model, and they are far cheaper to settle before the first order than after a pile of them. The per-transaction fee belongs in the same conversation: it decides which products are worth selling at all.
Card details should never become your problem. If customers type a card number into a page your host serves, you take on the whole burden of handling that data, and the obligations grow faster than the feature does. Most small sites avoid this by sending the customer to the provider’s own page for the sensitive step. You lose some control over the appearance; you gain a part of the flow that is somebody else’s certified job.
Refunds and disputes need an owner. A payment can be returned, reversed by the bank or questioned weeks later. Somebody has to know where the money is, what the policy is and who answers within the deadline the provider sets. An unattended checkout does not fail loudly; it fails as a chargeback addressed to nobody.
Three ways to put a payment on a site
The first route is a hosted payment page or payment link. The site holds a button, the customer leaves for the provider’s page, pays and returns. It is the smallest build that can be called real, it keeps card data off your infrastructure, and it works on a static site with no backend at all. The limits are practical: the branding belongs to the provider, there is no room for a complicated basket, and the flow depends on the customer coming back to a page that recognises them.
The second route is a plugin inside your CMS. Cart, stock, tax rates and receipts are handled by something someone else maintains, so new products are added by filling in a form rather than writing code. The trade is dependency: the plugin has to suit your theme and your version, updates have to be applied, and the day it stops being maintained you own the code anyway.
The third route is a direct integration with the provider’s API. You control every step, so unusual models — deposits, instalments, splitting a payment between accounts — become possible. You also inherit everything the plugin did for you: the callbacks that confirm a payment, the retries when one arrives twice, the authentication banks require, and the reconciliation that proves the numbers agree at the end of the month.
All three routes raise the same question: who maintains this in a year? That answer decides the choice more than the initial build does. A route you can hand over with a one-page runbook is worth more than a route that is elegant and lives in one person’s head.
What breaks after the first real payment
The receipt lands in the junk folder. The money is taken, the confirmation never arrives, and the customer concludes the site charged them twice or not at all. It has nothing to do with how good the page looks, and it is the most common way a working checkout produces an unhappy buyer.
The payment succeeds and the order never appears. The site is waiting for a confirmation from the provider that never arrives — a wrong address, a timeout, credentials left in test mode. The money sits in the account, the customer waits for a delivery, and nobody in the business knows either fact until someone complains.
The test environment is still on, or the live keys are in the test site. Environments get mixed up exactly when a launch is rushed. One test payment made with a real card, or one real payment captured in an account that closes next week, is an expensive way to find out which is which.
The price and the currency disagree. The customer is shown one amount and charged another after conversion, or the business is paid in a currency it cannot spend without a fee. Neither side notices until the accounting does.
The mobile step is where the sale dies, and nobody can see where people stop. A checkout that works on a desktop and asks a phone user to type a long card number by hand loses buyers at that field. Without a record of how far customers get, the business argues about the design instead of the drop-off — the most valuable number on a new checkout is how many people reached the payment step and never finished it.
What AI is genuinely good at here
Use it for everything that is text, structure or rehearsal. Organising the catalogue so a customer finds the product, writing product pages whose claims match the actual price and stock, mapping the flow from landing page to confirmation, and generating the awkward test cases nobody writes by hand: “card declined”, “the customer closed the window halfway”, “the confirmation arrived twice”. It is also useful for the runbook — what to check, in what order, when a payment behaves strangely.
Do not let it choose the business rules. The provider, the settlement currency, the refund window, whether you sell to companies with a tax number, who answers a dispute and by when — every one has money attached and a person who must stand behind it. The machine is fast at producing; the decisions stay with whoever owns the outcome.
Then buy something cheap and give it back. One real order, paid with a real card for a small amount and refunded, proves more than any preview: the receipt reaches an inbox rather than a junk folder, the money lands where it should, the refund returns, the stock or the booking is released, and the order shows up where the team works. Run it before launch, and again after the next change.
Payments belong on the launch checklist
A website that can take money is two deliverables, and only one of them is a page. The page can be generated quickly and regenerated whenever it needs to be. The second deliverable is the promise behind it: an account that is open, a rule that is agreed, a confirmation that reaches the inbox, and a person who knows what to do when a payment behaves badly. Businesses that treat the second one as part of the build launch quietly; businesses that leave it to somebody else find out during their first busy week.
Related service: Website and web application development