AI Won't Connect Stripe, GoCardless or HMRC to Your Site

Here is a scene I see more and more often. A founder spends a weekend in Lovable, Bolt or v0 and ends up with a tidy little e-commerce site. The design is clean, the product pages work, the basket adds up correctly. Then comes the moment when a real customer needs to actually pay with their card or Apple Pay, when a subscriber needs to set up a Direct Debit, and when the sale needs to land in Xero so the VAT is right. And that is exactly where everything grinds to a halt.

The AI generates a checkout button that looks flawless. Only no money comes through it. It generates a "log in" form that authenticates nobody. It promises an invoice export that HMRC never sees. This is not bad luck or a weak prompt, it is a fundamental boundary where today's AI tools stop. In this article I will explain why that is, which specific UK payment, identity, tax and shipping integrations need a human, and what that genuinely means for your project's cost and timeline.

Why AI is great at the UI but not at integrations

The user interface is the one area where AI is genuinely strong. Buttons, forms, grids, animations, these are repetitive patterns with millions of examples online, and AI was trained on exactly that kind of code, so it produces a good-looking, responsive front end impressively fast. This is the famous "vibe coding" win: prompt-to-app gets you a demo by Friday.

Integrating with a real system is a completely different job. Stripe, GoCardless, HMRC and Royal Mail are not snippets the AI can "remember" and regurgitate. They are live systems that exist outside your website and that need three things the AI physically does not have: your company's contractual relationship with the provider, your live secret keys, and a secure server where that logic actually runs. AI cannot complete Stripe's account verification for you, cannot register your business for Making Tax Digital, and cannot safely store your API keys, because it simply pastes them into code every browser visitor can read.

This is the core difference between "looks like it works" and "works in production with real money". It is the same theme I cover in the real cost of a "free" AI website, integrations are the part where the most people get stuck, and where the hidden bill lands.

The UK integrations that need a human

Let's get specific. Here are the integrations a real British business project runs into, and why each one needs a person rather than a prompt.

Integration	What it's for	Why AI won't connect it
Stripe / PayPal / Apple Pay / Google Pay	Card and wallet payments at checkout	Verified merchant account, live keys, server-side webhook with signature verification, PCI-DSS handled via hosted flow
GoCardless / Stripe Billing	Direct Debit, recurring and subscription billing	Mandate setup, retry and dunning logic, failed-payment handling, customer notifications
Open Banking ("Pay by Bank")	Low-fee account-to-account payments (TrueLayer, Atoa, Yapily)	FCA-regulated provider contract, consent flow, payment status reconciliation
Auth0 / Clerk / Supabase + Onfido / Yoti	Login, passkeys, KYC and AML identity checks	Secure server flow, session handling, UK GDPR for personal data, document verification logic
Xero / QuickBooks + HMRC Making Tax Digital	Accounting sync and VAT submission	OAuth to the accounting platform, MTD-compatible submission, strict data format, error handling
Royal Mail / DPD / Evri APIs	Labels, tracking, Click & Collect	Carrier contract, account keys, pickup-point lists, label generation through their system

Payments: Stripe, PayPal and the digital wallets

In the UK, Stripe is the default for most new sites, PayPal is expected at any consumer checkout because roughly two thirds of shoppers already have it, and Apple Pay and Google Pay now drive around 40% of online purchases, so they have to be enabled too. For any of this to work you need a verified merchant account, your live keys, and the invisible part that matters most: when a customer pays, the provider sends a webhook to your server, and your server must verify that event's signature before marking the order paid. Without that check, anyone can post a fake "paid" event and walk off with the goods. AI does not generate this server-side logic because it lacks your keys and the business context. Done properly with Stripe Checkout or PayPal's hosted flow, you also stay out of PCI-DSS scope, exactly where you want to be.

Subscriptions and Direct Debit: GoCardless and Stripe Billing

If you bill monthly, a card on file is only half the story, UK customers expect Direct Debit, and GoCardless is the standard for it (around 1% + 20p, capped at £4). Recurring billing is not a "subscribe" button, it is mandate setup, retries when a payment bounces, dunning emails, proration when someone upgrades, and a clean cancellation path. Each of those is an edge case the demo never shows, and each one, handled wrongly, is either lost revenue or an angry customer.

Identity and login: Auth0, Clerk, Onfido and passkeys

The UK does not bolt a national e-ID onto private apps, GOV.UK One Login is for public services. For your own product, modern login means Auth0, Clerk, Supabase Auth or Firebase Auth, with passkeys and "Sign in with Apple, Google or Microsoft" as the expected pattern. If your service touches finance, health or anything regulated, you also need KYC and AML checks through Onfido, Yoti or Stripe Identity. A mistake here cuts two ways: either nobody can log in, or, far worse, you let the wrong person in. This is not a form, it is a security system handling personal data under UK GDPR, and it has to be built and tested by someone who understands what a failure costs.

Tax and invoicing: Xero, QuickBooks and HMRC Making Tax Digital

Sell something and you need an invoice, and your VAT records have to reach HMRC digitally under Making Tax Digital, through approved, MTD-compatible software. Here the AI promises to "export an invoice", but HMRC's system and your accounting platform accept only correctly structured data with the right fields, tax codes and formatting. There is no "nearly right", it is either accepted or rejected with an error you have to understand and fix. In practice this means an OAuth connection to Xero (dominant among UK SMEs) or QuickBooks, mapping your orders to their data model, and reliable submission. Worth flagging too: mandatory B2B and B2G e-invoicing is confirmed for around April 2029, likely on PINT UK over the Peppol network, so build with that in mind.

Shipping: Royal Mail, DPD and Evri

An online store needs the buyer to pick a delivery option, a label to generate automatically, and tracking to flow back to the customer. That requires a carrier contract, account keys, pickup-point lists for Click & Collect, and label generation through the carrier's own system, Royal Mail Click & Drop, DPD, Evri ParcelShop, InPost lockers. The AI can draw a delivery selector, but it will be empty: without a real connection to Royal Mail or DPD there are no services, no rates and no labels behind it. Because I build custom Next.js, these go in as direct REST integrations, or through an aggregator like ShipStation or Sendcloud where it makes sense.

Why this isn't "plug an API in five minutes"

I hear it often: "but there's documentation, just plug the API in." Yes, a demo where a button looks like a payment really does take five minutes. A real integration, one that must not lose money, must not accept duplicate or spoofed payments, and must survive the provider's own checks, is made of several stages, and you cannot skip any of them.

• Contract and account verification. The provider has to verify your company and grant live access. This often takes longer than the code itself.
• Sandbox testing. Every provider has a test environment where the flow is proven before real money flows. Skip it and your first real customer becomes your test.
• Signature and webhook verification. The server must confirm a payment confirmation genuinely came from the provider, not from an impostor.
• Compliance and UK GDPR. Payment and identity data is sensitive. Handling it has to satisfy UK GDPR, the Data Protection Act 2018, PCI-DSS and PECR, not just function. AI-built apps routinely ship with none of these.
• Edge cases. What happens when a payment drops halfway, when a customer double-clicks, when the provider times out, when you need to refund. These cases are exactly what separates a demo from a product.

This is the same "hard 20%" I talk about with almost every client. AI gets the project to about 80%, the polished, visible, impressive part. The remaining 20%, the integrations, security, edge cases and compliance, is the hardest and most expensive part. Not because it is "tricky to finish", but because it is the real product. If you want to understand honestly where AI is genuinely enough and where you can't avoid a developer, read when AI is enough and when you need a developer, I lay out both sides there without the hype.

What this means for cost and timeline

To be straight with you, here are realistic ballpark ranges for cleanly connecting these integrations to a UK site or store. All figures are ex-VAT, as UK B2B buyers expect, so add VAT on top. This is not "patching code", it is a system that holds up under real traffic and the provider's own audit.

Integration	Indicative price (+ VAT)	Timeline (account in place)
Single payment provider (Stripe / PayPal + wallets)	£600 - £1,500 (~€700 - €1,750)	1 - 2 weeks
Subscriptions / Direct Debit (GoCardless, Stripe Billing)	£1,000 - £2,500	1 - 3 weeks
Auth + ID verification (Auth0/Clerk + Onfido/Yoti)	£1,200 - £3,500	2 - 3 weeks
HMRC Making Tax Digital / Xero / QuickBooks sync	£1,500 - £4,000	2 - 4 weeks
Carrier shipping (Royal Mail / DPD / Evri)	£700 - £1,800 each	1 - 2 weeks

For context, those numbers sit at senior UK independent developer rates, day rates of roughly £400-£650 + VAT, because a payment flow that handles real money is precisely where you want someone who can actually ship to production, not a £5-an-hour marketplace gamble. Two things on timeline. First, the longest pole is usually not the code but provider account verification and getting live keys, so start that early. Second, integrations are rarely isolated: payment, invoice and shipping usually form one chain, so plan them together rather than patching them one at a time.

How I approach it

When I take on a project where the integrations don't work, I don't patch the generated code snippet by snippet. I look at what genuinely needs to connect, map out the whole chain, payment, subscription, invoice, shipping, identity, and build the server side with all the verification, sandbox testing and edge cases in place. The goal is not "make the button look right", it's that the money actually arrives, the invoice reaches Xero, HMRC accepts the VAT, and the data is handled under UK GDPR. You're left with a working product and a codebase you own, not a pretty façade with nothing behind it, and I own the outcome.

Frequently asked questions

Why can AI build a website but not connect Stripe?

AI generates the user interface brilliantly because it's repetitive and documented all over the internet. A working Stripe integration requires a verified Stripe account in your business name, your live secret keys, server-side webhook handling with signature verification, and a hosted checkout flow that keeps you out of PCI-DSS scope. AI physically cannot do these for you, it doesn't have your company details, can't complete the account verification, and can't safely hold your secret keys, it tends to paste them into front-end code every visitor can read. That's why an AI-generated pay button looks perfect but no money actually arrives.

Can I add login and ID verification to my site on my own?

Modern login in the UK means Auth0, Clerk, Supabase Auth or Firebase Auth plus passkeys and "Sign in with Apple, Google or Microsoft", and for regulated services KYC and AML checks via Onfido, Yoti or Stripe Identity. This is not a button you paste in, it's an authentication system where a mistake means either nobody can log in or you let the wrong person in. It also handles personal data, so it must comply with UK GDPR and the Data Protection Act 2018 from day one. These integrations need a human who understands the consequences to build and test them.

How much does it cost to connect payment and tax integrations in the UK?

A clean single payment integration such as Stripe or PayPal, with sandbox testing and a live go-live, typically costs from £600 to £1,500 + VAT depending on flow complexity. Auth plus ID verification with Onfido or Yoti runs roughly £1,200 to £3,500 + VAT. HMRC Making Tax Digital VAT submission or accounting sync with Xero or QuickBooks starts from around £1,500 + VAT. Carrier integrations such as Royal Mail Click & Drop or DPD are about £700 to £1,800 + VAT each. The exact figure depends on how many integrations you need and how deeply they tie into your business logic.

Why can't you just plug an API in five minutes?

Payment and identity APIs require provider registration and verification, live and test keys, sandbox testing before real money flows, webhook signature verification, error and refund handling, UK GDPR compliance and secure key storage. A demo where a button merely looks like a payment really does take five minutes. A real integration that doesn't lose money, doesn't accept duplicate or spoofed payments and survives the provider's checks takes days, and that's normal.

Is an AI-generated pay button safe?

Visually, yes, it looks like a pay button. Functionally it's almost never production-safe. The common faults I find: live secret keys left in front-end code the browser can read, the payment confirmation never verified on the server so an order can be faked, no webhook signature check so anyone can send a fake paid event, and no privacy policy, cookie or PECR consent, or ICO registration, which UK GDPR requires. I've found these gaps in more than one AI-started site. Safety here comes from server-side logic and hosted Stripe or PayPal flows, not from how the button looks.

How long will it take to connect payments and invoicing to my site?

If the provider account and verification are already in place, I deliver a clean single payment integration with sandbox testing in one to two weeks. HMRC Making Tax Digital VAT submission or accounting sync with Xero or QuickBooks takes two to four weeks because there are more edge cases and coordination with your bookkeeper. The biggest delay is usually not the code but provider account verification and getting live keys, so it's worth starting that as early as possible.