Not every payment happens on a phone call. Send a secure payment link by SMS, email or chat, embed a hosted checkout on your own site, store a card for repeat billing, or let a returning customer pay in a single tap with click-to-pay — all without bringing PCI scope onto your own systems. Customers enter card details on Paytia's form, not yours, so you move from SAQ D (329 controls) to SAQ A (22 controls). Same platform, same gateway, same reporting as your phone payments.
Recurring billing — scheduled charges from a stored token
On this page
TL;DR
Four ways to take online card payments without your site touching card data — payment links, hosted checkout, click-to-pay, and recurring billing. All four sit on Paytia's PCI DSS Level 1 platform with 3DS2 by default, so you move from SAQ D (329 controls) to SAQ A (22 controls). UK-built, processing £400M+ since 2016 across Stripe, Worldpay, Adyen, Barclaycard, Tyl by NatWest, Ryft, and Braintree.
Online payments, honestly
Last updated: 27 May 2026
We've been building card-capture infrastructure for UK businesses since 2016, and the online-payments brief is usually the same shape.
A finance team wants to email an invoice with a pay button on it. A subscription business wants to charge the same card on the same day every month without their support team rekeying digits. A retailer wants a checkout that looks like the rest of their site but doesn't put the rest of their site in PCI scope. A B2B operation wants to send a secure link in chat when a deal closes on a Friday afternoon.
All routine, all reasonable, all the kind of thing the obvious-looking integration handles by putting your developers in the middle of the card data — which is where the PCI bill starts. The form posts to your server. Your server forwards to the gateway. Your logs capture the payload because logs capture everything by default. Your error tracking grabs the failed-validation strings. Six months later an auditor asks where the card numbers live, and the answer is "everywhere we didn't mean."
The fix isn't to stop taking online payments. It's to stop the card data ever reaching a system you own. Customers enter the digits on a form we host, on infrastructure we've had certified at PCI DSS Level 1 since 2016. Your site redirects, embeds, or sends a link. The token we hand back is what your CRM stores — enough to charge again, useless to anyone who steals it.
That single architectural choice is what moves you from SAQ D (329 controls, annual QSA assessment) to SAQ A (22 controls, finance director signs it). Same customer, same gateway, same money landing in your bank account. The rest of this page is how the four common methods work and which one fits which kind of business.
Four ways to take a payment without a phone call. Each one suits a different shape of customer interaction, and most businesses end up running at least two together. The architecture underneath is identical — card capture happens on our infrastructure, your systems hold a token.
Payment links
A one-off URL tied to a specific amount and reference, sent by SMS, email, or chat. The customer taps the link, lands on our hosted page, pays, and gets a receipt. Your CRM gets a webhook with the result. The whole thing takes them under a minute. Best for invoice payments, ad-hoc collections, B2B sales where deals close in conversation, and any time you need to charge a customer who isn't in front of a checkout.
When to pick a payment link over the alternatives.If the amount changes per customer (an invoice, a quoted job, a deposit on a bespoke order), a link is faster than building a full checkout flow around the variation. If the customer's already on a call or a chat with one of your people, a link is the lowest-friction handover — they don't have to navigate your site, find the right product page, or remember the reference number. If volumes are still small (a few dozen payments a week), the design work for a hosted checkout doesn't pay back. Pick a hosted checkout instead when the same customer journey runs repeatedly and you want it visually integrated into your site. Pick click-to-pay when the customer is going to come back regularly and you want to remove the re-entry friction.
What integration looks like.Easiest path: send links manually from the Paytia dashboard — type the amount, the reference, the customer's mobile or email, hit send. Most finance teams start there and never move past it. Next step up: trigger links from your CRM with one API call when an invoice is raised, a deal closes, or a renewal falls due. Webhook payload back to your CRM updates the record when the payment lands. No card data ever crosses your network. Most teams have the API integration shipped inside a week.
Common pitfall. Teams set up the link send but forget to set up the chase. A customer who didn't pay on day one rarely pays on day two without a nudge. Build the reminder into your workflow from day one — either let our payment chase automation do it, or set CRM triggers that re-send after 48 and 96 hours. Detail on the payment links page, and the longer read at the benefits of secure payment links.
Hosted web checkout
A branded payment page on your domain that any customer can reach. Looks like the rest of your site, behaves like the rest of your site, but the form fields themselves are served from our infrastructure inside an iframe or full-page redirect. Customers don't notice. Auditors do — your codebase doesn't touch card data, so the checkout is out of PCI scope. Best for retailers, subscription sign-ups, donation flows, and anywhere you need a repeatable customer journey rather than a one-off link.
When to pick a hosted checkout over the alternatives. Pick a hosted checkout when the same payment flow happens many times and the design needs to feel like part of your site — a charity donation form, a product page that converts to a buy button, a subscription sign-up. Pick a payment link instead when the amount or reference is bespoke and the customer is already in a one-to-one conversation with you. Pick click-to-pay when the same customer returns repeatedly and you want a one-tap repeat purchase. Pick recurring billing when the schedule is the point.
What integration looks like. Two patterns. The iframe pattern embeds our form inside your page — your CSS controls the surrounding layout, the form fields are served from us. The full-page redirect pattern sends the customer to a Paytia-hosted page branded to match your site, then back to a thank-you URL when payment completes. The redirect is the simplest and the cleanest from a PCI perspective; the iframe gives you more control over the visual integration. Both keep the card capture on our infrastructure. Most teams are live in 2-3 weeks once design assets and the gateway connection are in place.
Common pitfall. The iframe pattern only protects PCI scope if the iframe is loaded directly from a Paytia URL. Teams sometimes proxy the iframe content through their own server to fix a same-origin issue or pass a session cookie — the moment that happens, the card data routes through your server again and you're back in SAQ D scope. If you need cross-origin coordination, use postMessage between the parent page and the iframe rather than proxying the form. Walk-through on the customised web checkout page, with the side-by-side comparison at pay-by-link vs hosted checkout.
Click-to-pay (saved card)
For returning customers who'd rather not re-enter their card every time. On the first purchase we tokenise the card; on subsequent purchases the customer authorises the charge with a single tap. Your site never sees the number — it sees the token, which is useless to anyone who steals it. Best for repeat retail, top-ups, and any flow where the friction of re-entering card details is costing you conversions.
When to pick click-to-pay over the alternatives.Pick click-to-pay when the same customer is likely to pay you again within months and the value of removing the form fields outweighs the work of setting up a saved-card flow. Cart abandonment data across UK retail suggests roughly 18-25% of mobile checkout drop-off happens at the card-entry step — for a returning customer base, this is usually the single highest-yield conversion lever. Pick recurring billing instead when the cadence is predictable and you don't need the customer to consent each time. Pick a hosted checkout if most of your purchases are first-time visitors who won't come back.
What integration looks like.First purchase runs through the hosted checkout exactly the same as any other. We tokenise on success and hand you back a token tied to that customer. On the next visit, you look up the token from your customer record and present a one-tap confirmation page — "Pay £24.99 with card ending 4242?" — which the customer approves with a single click or biometric. The charge runs server-to-server against the token. 3DS2 may step up depending on the issuer's risk score, but for low-value repeat purchases against a recognised customer the issuer usually waives it under PSD2's low-risk transaction exemption.
Common pitfall. Teams enable click-to-pay but forget to handle the token-update flow. When a customer's card gets reissued (lost, expired, fraud-flagged), the original token stops working unless you've enabled network tokens. The first time it bites is usually a churn spike that nobody can explain — customers who were quietly returning every month stop coming back because the saved-card payment failed silently. Enable network tokens at sign-up, not after the first failed-payment wave. More detail on the click-to-pay page, the what is click-to-pay explainer, and the network-token mechanics at network vs PSP tokenisation.
Recurring billing
Scheduled charges from a stored token — same day each month, weekly, annually, or on whatever cadence the contract says. Network tokens keep working when the customer's card expires or gets reissued, so your churn isn't driven by payment failures the customer never knew about. Best for subscriptions, memberships, instalment plans, and ongoing service retainers.
When to pick recurring billing over the alternatives.Pick recurring billing when the cadence is contractual and predictable — a SaaS subscription, a gym membership, an instalment plan, a maintenance retainer. Pick click-to-pay instead when the customer should authorise each charge (top-ups, repeat retail, irregular usage). Pick payment links when the amount or timing varies enough that a schedule doesn't fit. Pick a hosted checkout when the customer is signing up for the first time — recurring billing runs after the initial card capture, not instead of it.
What integration looks like. Customer signs up through a hosted checkout — same architecture as a one-off online payment, but with consent flagged for recurring use. We tokenise the card and store the token on our PCI platform. Your billing system holds the token and the schedule. On the due date, your billing job hits our API with the token and the amount; we run the charge against the gateway and webhook the result back. Network tokens handle reissues silently. Failed charges (insufficient funds, blocked card) trigger a retry sequence and a customer notification — usually three retries over a week, then a dunning email.
Common pitfall. PSD2 SCA requires the customer to authenticate the first charge (the "mandate setup") properly, and that means 3DS2 with explicit consent for future merchant-initiated charges. Teams sometimes capture the card via a one-off 3DS2 flow without the recurring flag, then start charging on a schedule — the issuer can decline subsequent charges as missing-mandate. Flag the original authorisation as the start of a recurring sequence at the point of capture, not retroactively. Full picture on the recurring payments page.
Methods compared, at a glance
Same architecture, different customer journey. The choice is about how the customer arrives at the payment, not how the payment itself works.
All four methods sit on the same Paytia platform and the same merchant account. You can mix and match without a second integration.
PCI scope and why SAQ A matters
Every system that can see, store, or process a card number is part of your cardholder data environment. The card schemes don't care whether you stored a number deliberately — they care whether your architecture made it possible.
For an online checkout, that question turns on one thing: does your server ever touch the card number, even in transit? If your form posts to your backend and your backend forwards to the gateway, the answer is yes. Your web tier is in scope. Your application logs are in scope. Your error-tracking service is in scope. Your CI logs are in scope (because someone, somewhere, will replay a failed transaction to debug it). Your load balancer is in scope. The bill scales fast.
That's the SAQ D world — 329 requirements, an annual QSA-led assessment, quarterly ASV scans, penetration testing, hardened builds, segregated network zones, documented evidence for every place card data could land. Doable, expensive, and almost never the right answer for an online checkout when the architecture has a cheaper alternative.
SAQ Ais what you land on when the card capture lives somewhere else. 22 controls, focused on your contractual relationship with a certified provider and the integrity of your redirect/embed. Your finance director can sign it in an afternoon. The card number never reaches a system you own, so the question of who's patched the database server doesn't arise.
Tokenisationis what makes the saved-card and recurring flows work without bringing scope back in. The processor returns a token your CRM stores in place of the card number, which means refunds, re-charges, and subscription billing all run server-side without you holding the digits. Network tokens go further: when the customer's card gets reissued, the token updates automatically so the subscription doesn't lapse and you don't need a payment-retry process driving away customers who never knew their card had expired.
On the fraud side, online card payments are card-not-present, which means chargeback liability sits with you unless you authenticate the customer. We run 3DS2 on every transaction — the customer approves the payment in their banking app, the issuer takes liability for fraud chargebacks, and your dispute exposure drops sharply. PSD2 strong customer authentication is the regulatory backbone of this in the UK and Europe, and 3DS2 is how acquirers expect you to satisfy it.
Two costs to think about, and they pull in different directions.
The first is your acquirer's transaction fee. Card-not-present interchange is roughly 0.1–0.3% higher than card-present, because the fraud risk is higher. Your acquirer (Barclaycard, Worldpay, Tyl by NatWest, Elavon, whoever) sets this, not us. 3DS2-authenticated transactions usually qualify for lower interchange tiers — another reason the authentication step pays for itself before you count the chargeback savings.
The second is what you pay for the technology that keeps the card off your systems. Per-transaction pricing scales linearly with volume — predictable for a business with steady throughput, painful in a big sales month, watch the minimum monthly commitment. Per-seat pricing charges for each named user authorised to send links or refunds — predictable to budget, gets expensive if you have a big finance team but most of them never touch a payment.
Things to watch for in the proposal: setup fees that don't include integration, "card brand fees" with margin added on top, gateway charges hidden under a different line, recurring-billing surcharges that only show up at the year-end. None of these are unreasonable on their own; together they're often the gap between the headline price and the year-one total. Get a vendor to model your real annual volume before you sign. The longer walk-through is in merchant services fees explained.
The honest comparison isn't Paytia versus the cheapest gateway alone — it's the masking cost against the cost of staying in full PCI DSS SAQ D scope on your own checkout. A typical UK SAQ D programme for a mid-sized online business runs £15,000–£30,000 a year on QSA fees and ASV scans alone, before you count the infrastructure controls (hardened builds, segregated zones, locked-down logging) or the staff overhead (training, attestation, access reviews). The all-in compliance bill for keeping the card data in your own checkout is usually £40,000–£80,000 a year.
Moving the capture to a certified provider typically cuts compliance-related spend by 60–75% in the first year, with bigger swings in years two and three as you stop maintaining controls you no longer need. The full breakdown is at how much does PCI compliance cost. We'll quote you a real number against your real volume — book a 20-minute calland we'll model it.
Strong Customer Authentication (SCA) and 3DS2
Strong Customer Authentication is the FCA's name for the rule that says an online card payment in the UK or EU has to be authenticated by the cardholder, not just authorised by their card. It came in under PSD2 (the second Payment Services Directive) and the UK kept it after Brexit. 3DS2 is how almost every UK merchant satisfies it in practice.
What SCA actually requires.Two factors out of three: something the customer knows (a password, a PIN), something they have (a phone, a hardware token), or something they are (a fingerprint, face match). In 2026 the dominant pattern is biometric approval inside the customer's banking app — they get a push notification, tap to confirm with Face ID or a fingerprint, and the payment goes through. The merchant doesn't see any of this. The issuer's app handles it.
How 3DS2 implementation works. When a customer submits a card on a Paytia-hosted form, we send a 3DS2 authentication request to the issuer through your gateway. The request includes around 150 data points — device fingerprint, IP, billing address, prior purchase history, transaction amount, merchant category. The issuer's risk engine looks at those and decides one of three things. Frictionless approval: the data is enough to trust the transaction, no customer action needed — about 60-70% of UK online card payments fall here in 2026. Step-up challenge: the issuer asks the customer to authenticate in their banking app — usually a biometric approval. Decline:the issuer rejects authentication, the transaction can't proceed.
The liability shift. The reason this matters beyond compliance is that 3DS2-authenticated transactions push fraud chargeback liability from the merchant to the issuer. If a customer disputes a charge as fraud and the transaction was 3DS2-authenticated, the issuer absorbs the loss, not you. This is the single biggest financial reason to run 3DS2 on every online payment — for a UK retailer doing £2M a year online, the chargeback liability shift typically saves £8,000-£20,000 a year on its own. Full mechanics in 3DS2 and the liability shift.
SCA exemptions.A handful of transactions are exempt. Low-value transactions under €30 (about £25) qualify for the low-value exemption, but only if the merchant hasn't hit five consecutive exempt transactions or €100 cumulative without authentication for the same card. Transaction Risk Analysis exemptions let the issuer skip the challenge if their risk model is confident — this is what powers most of the frictionless 60-70% in practice. Merchant Initiated Transactions (recurring billing on a stored mandate) are exempt because the initial mandate setup was authenticated. Trusted Beneficiary (whitelisting) lets a customer mark a merchant as trusted and skip future challenges. Our platform handles all of these automatically — you don't need to track exemption flags in your code.
What this means in practice. 3DS2 is on by default on every Paytia online payment. You don't need to opt in, you don't need to add a separate authentication step. The exemption logic runs in the background. Your customer either pays without noticing (frictionless) or gets a biometric prompt from their bank (step-up). Your fraud chargeback exposure drops in both cases. The Compliance walk-through at PCI compliance for payments and the strong customer authentication glossary entry cover the rest.
What good looks like — typical implementation timeline
Most UK businesses go from kick-off to first live payment in 4-8 weeks. The variation is mostly about how clean your existing gateway and CRM setup is — the masking integration itself is a few days. Here's the shape we see most often.
Week 1 — discovery and gateway confirmation
A 20-minute call to confirm your acquirer (Barclaycard, Worldpay, Tyl by NatWest, Stripe, Adyen, Ryft, Braintree), your gateway, and the payment methods you actually need. We map your existing flows — which customer journeys take cards today, which channels you want covered (web, SMS, email, chat), how your CRM holds customer records. Output: a one-page integration brief and a quote against your real volume.
Week 2 — contracts, gateway setup, sandbox access
Master Services Agreement signed. We provision your sandbox account on our platform. If you don't already have a tokenisation-enabled merchant account at your acquirer, we coordinate with them to enable it — usually a 2-3 day turnaround. Sandbox credentials handed to your dev team. By end of week 2 your team can fire test transactions through to a sandbox version of your real gateway.
Weeks 3-4 — first method live in sandbox
We'd normally start with whichever method has the highest near-term value. For most B2B teams that's payment links — they go live fastest and start collecting straightaway. For retail it's often the hosted checkout. Your dev team integrates the API or drops in the embed; we provide reference implementations in Node, Python, PHP, and .NET. Webhook handlers wired into your CRM. Test transactions run all the way through sandbox with 3DS2.
Week 5 — production switch-over, first live payments
Sandbox credentials swapped for production. First real payment run with a small internal transaction (usually a £1 charge to a team member's card) to verify the flow and the webhook. Once that lands clean, the new method goes live to customers. We monitor the first 48 hours alongside your team and tune any 3DS2 challenge rates that look off.
Weeks 6-8 — second method, training, SAQ A attestation
Most teams add a second method by week 7 — usually whichever wasn't first. Recurring billing typically comes in last because the dunning logic and the mandate-setup consent flow need careful design. Finance team trained on the dashboard for refunds, reporting, and ad-hoc link sends. Your SAQ Aattestation drafted and signed — we provide the template and the vendor section is pre-filled with our PCI attestation details. By week 8 you're running fully on the new infrastructure, the old card-handling flow can be decommissioned, and your compliance scope has shrunk.
What pushes the timeline out
Two things slip projects past the 8-week mark. Acquirer paperwork. If your merchant account needs to be reconfigured for tokenisation or recurring billing, the acquirer's turnaround can be 2-4 weeks of waiting for forms to clear. We can't accelerate this — get the paperwork moving in week 1. Internal sign-off cycles. If the integration needs security review, legal review, and architecture review before any code ships, factor in 2-3 weeks of internal time. The technical work itself is rarely the bottleneck.
Common mistakes to avoid
The same five mistakes show up across most of the projects we're asked to rescue. They're all avoidable if someone flags them at the design stage. None of them need a re-platform to fix once you spot them.
1. Proxying card data through your own server to "fix" a same-origin issue
The pattern: your hosted checkout iframe needs to share a session cookie with the parent page, so a developer routes the iframe's form submission through your server before forwarding it to the gateway. It looks like a clean fix and it pulls every part of your stack — web tier, logs, monitoring, database — back into PCI scope. The right fix is postMessage between the parent and the iframe, or a redirect-based checkout, or letting the iframe use its own session entirely. Never proxy the card data.
2. Logging the request payload "for debugging"
The pattern: an engineer adds a debug log line to the checkout flow during a release, capturing the full request body so they can replay failures in staging. The release ships, the log line stays. Six months later the security team finds card numbers in a CloudWatch group with 90-day retention and you've got an incident. Even if the card capture lives on Paytia's infrastructure, your webhook handler still receives metadata — log what you need (transaction ID, amount, status), never the full payload, and review log retention quarterly.
3. Skipping the 3DS2 mandate flag on recurring sign-ups
The pattern: a subscription business captures the card on first sign-up through a normal 3DS2 challenge, then starts charging monthly against the stored token. The issuer flags the second charge as missing-mandate and declines. The customer doesn't know, the merchant doesn't know, and the churn shows up as "payment failed" in the dunning report a month later. Always flag the initial authorisation as the start of a recurring sequence at the point of capture — the gateway has a specific field for this. Retrofitting it after the fact doesn't work.
4. Treating click-to-pay as a one-off feature instead of an architecture choice
The pattern: a retailer enables click-to-pay for the "buy again" button on their order history page but forgets the token-update flow. Customers come back, their old card has been reissued by the bank, the tokenised charge fails. Without network tokens enabled, you're running a saved-card feature that quietly breaks every 18-36 months as cards rotate. Enable network tokens at sign-up — the cost is negligible, the customer experience is invisibly better, and your retention metrics stop dropping for reasons nobody can explain.
5. Building the checkout before talking to the acquirer
The pattern: a team builds a fully working hosted checkout against a Stripe test account, then discovers their actual merchant account is at a different acquirer that doesn't support the same tokenisation flow, the same MCC, or the same 3DS2 exemption logic. Two weeks of work to refactor. Confirm the acquirer first, the gateway second, the integration last. We do this on the discovery call — it's the single highest-value 20 minutes in the project. If your acquirer's tokenisation flow has quirks (some UK acquirers do), we surface them in week 1, not week 6.
How the pattern shifts by sector
The architecture is the same across industries — card capture on Paytia, tokens on you — but which of the four methods is the primary one varies a lot. Worth knowing before you start designing, because the wrong primary method costs you conversion rate from the first week.
Retail and ecommerce
Hosted checkout is the primary — it has to live inside the product experience, not in a separate window. Click-to-pay is the secondary for repeat customers. Payment links come into play for customer service recoveries (an abandoned cart, a sized-out-of-stock substitution, a custom order). Recurring billing usually irrelevant unless you run a subscription box. 3DS2 challenge rates matter more here than anywhere else — every step-up costs you conversion, so the platform tuning the exemption logic well is what separates a good integration from a poor one. More on the retail and ecommerce page.
Financial and professional services
Payment links are the primary — invoiced work, retainer top-ups, deposit collections, ad-hoc client charges. Most firms send a few dozen links a week from the CRM, never need a hosted checkout. Recurring billing for retainer fees. Hosted checkout only matters if you sell productised services with a buy button. Detail on the financial and professional services page.
Healthcare
Mixed pattern. Hosted checkout for self-pay bookings (private GP appointments, dental consultations, physio sessions). Payment links for invoiced treatments and outstanding balances. Recurring billing for treatment plans. Click-to-pay rarely used — patients don't come back often enough for the saved-card pattern to pay back. The PCI scope reduction matters more here because of GDPR overlap — patient identifiers and card data in the same database is a regulatory headache nobody wants. More on the healthcare page.
Insurance
Recurring billing is the primary — premiums on a monthly or annual schedule. Hosted checkout for first-time policy purchase. Payment links for ad-hoc charges (mid-term adjustments, additional cover, excess waivers). Click-to-pay rare. The 3DS2 mandate flag at sign-up is critical here because the recurring relationship lasts years — a missing-mandate decline in year two of a policy is a renewal you didn't get. Detail on the insurance page.
Public sector and non-profit
Hosted checkout for donations and one-off payments (parking, licences, fines, school fees). Recurring billing for monthly giving. Payment links for invoiced services and outstanding balances. Click-to-pay can lift recurring donation conversion if the donor base returns regularly. PCI scope reduction matters disproportionately here because public-sector budgets struggle to absorb a full SAQ D programme — the SAQ A path is often what makes online card payments viable at all. More on the public sector and non-profit page.
Travel
Hosted checkout for booking. Payment links for balance payments on deposit bookings (a 20% deposit at booking, the 80% balance link sent 8 weeks before travel). Recurring billing for instalment plans on high-value trips. Click-to-pay for repeat bookers, especially business travel. Chargeback exposure is high in travel, which makes 3DS2 even more valuable than usual. Detail on the travel page.
Why take payments online with Paytia
Every online payment route on this page shares one property: the card entry lives on Paytia's infrastructure, not yours. Your site can redirect, embed, or send a link, but the numbers never land in your database, logs, or analytics tools. That's what makes the PCI scope reduction real — SAQ A instead of SAQ D, with nothing to audit on your side.
We're a UK company, PCI DSS Level 1 certified since 2015, and we integrate with most payment gateways. You keep your merchant account. We just take the card data out of your business.
Most customers start with payment links because they're the fastest to go live. If you need recurring billing, subscriptions, or a fully branded checkout later, you're already on the right platform — no second contract, no second integration.
Frequently asked questions
What's the difference between a payment link and a hosted checkout?
A payment link is a one-off URL you send to a single customer, usually by SMS or email, for a specific amount. A hosted checkout is a branded page on your site where any customer can pay you. Both keep the card entry on Paytia's infrastructure so it never touches yours — the difference is just how the customer gets to it. Most businesses start with links because they go live in an afternoon, then add a hosted checkout once the volume justifies the design work.
Can we store cards for repeat billing?
Yes. We tokenise the card on first use and store the token on our PCI-certified platform, not in your systems. You can charge the stored card on a schedule (recurring payments) or on demand (click-to-pay) without ever seeing the number again. If the customer's card expires or gets reissued, network tokens update automatically so the subscription doesn't lapse.
Do we need developers to add this to our site?
For payment links, no — you send them from the Paytia dashboard or trigger them from your CRM. For hosted checkout or click-to-pay, it's one embed code or a redirect, which your web team can drop in in under an hour. Nothing on your side touches card data, so there's no PCI work for the developers to do either.
Does this reduce our PCI scope?
Yes. Because customers enter card details on Paytia's pages — not yours — you typically move from SAQ D (329 requirements) to SAQ A (22 requirements). Your site, your database, your logs, and your analytics tools are all out of scope for card data. The SAQ A attestation is something your finance director can sign off in an afternoon rather than a project that needs a QSA.
What about 3D Secure and chargebacks?
Online card payments are card-not-present, so the chargeback liability sits with you unless you authenticate the customer. We run 3DS2 on every transaction by default — the customer approves the payment in their banking app, the issuer takes liability for fraud chargebacks, and your dispute exposure drops sharply. The customer experience is the same gesture they make on Amazon or Apple Pay.
Will it work with our existing payment gateway?
Almost certainly. We integrate with most UK and European gateways — you keep your acquirer, your merchant account, and your existing pricing. We just take the card data out of the path between your customer and your gateway. Tell us who your acquirer is in the demo and we'll confirm before you sign anything.
How much does it cost?
Two costs. Your acquirer's transaction fee (set by Barclaycard, Worldpay, Tyl, Elavon or whoever you use, not us — card-not-present interchange is roughly 0.1–0.3% higher than card-present) and the masking technology itself, which we charge per transaction or per seat depending on your call shape. Both together are almost always cheaper than running a full PCI DSS SAQ D programme on your own site, which is where you land if your checkout takes the card directly.
Which card schemes do you support?
Visa, Mastercard, American Express, Discover, and JCB across all four methods. Whether a specific card is accepted on a transaction depends on what your merchant account is enabled for — most UK acquirers cover Visa and Mastercard by default, with Amex usually requiring a separate agreement and Discover/JCB enabled on request. We don't add or remove scheme support; we route to whatever your acquirer accepts.
How long does implementation actually take?
Most UK businesses go live within 4-8 weeks. The masking integration is days; the variation is in acquirer paperwork and your internal sign-off cycles. Payment links can be sending from the dashboard inside an afternoon. Hosted checkout and recurring billing usually take 2-3 weeks of dev work plus testing. If your merchant account needs reconfiguring for tokenisation, that's typically the bottleneck — get the acquirer paperwork moving in week 1.
Do you handle dunning and failed-payment retries for recurring billing?
Yes. Our recurring billing service runs a configurable retry sequence on failed charges — usually three attempts over a week — and sends customer notifications between each attempt. You set the schedule and the messaging, we run the engine. Network tokens handle the silent reissue case (where the customer's card was replaced by the bank), so most 'failed payments' that used to be churn just resolve themselves before anyone notices.
What happens if Paytia has an outage during a payment?
Two layers of protection. Our platform runs PCI DSS Level 1 infrastructure with redundancy across regions — we haven't had a payment-affecting outage longer than a few minutes since launch in 2016. If a payment fails to complete (network error mid-transaction, gateway timeout), the customer gets a clear error and is invited to retry; nothing partial gets committed. For payment links, the link itself remains valid even if our dashboard is briefly slow — the hosted payment page is served from a different infrastructure path. We publish status at status.paytia.com.
Can I run Paytia alongside my existing checkout while we migrate?
Yes, this is how most teams switch over. Stand up the Paytia flow alongside your current checkout, route a percentage of traffic to it, monitor for a week or two, then move the rest. You keep your existing acquirer the whole time, so there's no merchant account migration or interruption to settlement. The SAQ A reduction kicks in once your existing card-handling code is retired, not before — so plan the retirement step into the project timeline, not as something that happens by accident later.
More on online payments
Everything across the site that goes deeper on a specific piece of this — methods, compliance, gateway integration, industries. Read the bits relevant to where you are.
“Paytia's solution has transformed our telephone ordering process. We've dramatically improved efficiency while ensuring the highest levels of payment security. Our team now spends less time processing payments and more time delivering the exceptional customer experience that defines our brand.”
Used by British American Tobacco · Howard Kennedy · CITB · Clinical Partners · Trinity Hall College
Since 2016
Building secure payments
PCI DSS Level 1
Highest certification
99.99%
Platform uptime
£400M+
Transactions processed
Online payments, without your site being in scope
Tell us how you bill customers today and we'll show you the fastest route to take card data off your systems. Most UK customers are live within a few weeks on the gateway and acquirer they already use.
