Add-On Service · Payment Integration
Your customers are ready to pay. Make sure your website can actually take their money.
A checkout form pasted in from a third-party tool or a payment plugin bolted onto WordPress is not the same as a payment integration built for your specific business. ArdinGate builds payment flows directly into your site — Stripe, Square, or PayPal — matched to how your business actually collects money: one-time services, package options, deposits with a balance due later, or recurring subscriptions. Card data never touches your server. Charges are confirmed before receipts go out. Every scenario is tested before your first customer sees the checkout.
What a properly built payment integration covers
A working payment integration isn't just a form that collects a card number. Several things have to happen correctly in sequence for money to actually move, for your customer to know it worked, and for your business to have a reliable record of the transaction. Every integration ArdinGate builds covers all of the following — skipping any of them creates a gap that either creates a security problem or breaks the business logic the payment is supposed to enforce.
Card data goes to the processor, not your server
When a customer types their card number into the checkout form, it goes directly from their browser to the payment processor — Stripe, Square, or PayPal — using that processor's own secure code running on the page. Your website never sees the card number. What comes back to your site is a one-time token, a meaningless code that references the card without containing any of its details. Your server uses that token to complete the charge. This architecture keeps your customers' card data out of your systems entirely, which is what keeps both of you protected. It's not optional — it's the standard way a payment integration is supposed to be built.
A confirmation system that verifies every payment actually succeeded
A checkout that only relies on redirecting the customer to a "thank you" page after they click "Pay" has a real problem: anyone who knows the URL of that page can visit it without paying anything. The fix is a confirmation system: the payment processor sends a secure message directly to your server the instant a payment succeeds. Your server verifies that the message is genuine, then does what the payment is supposed to trigger—sends the receipt email, marks the order as paid, grants access to a subscription, logs the transaction. This confirmation system is what makes the integration trustworthy. Every integration includes this verification system built in and fully tested.
Automatic confirmation emails from your domain
The moment a payment confirms, two emails go out automatically: one to your customer with a receipt showing exactly what they paid for and the transaction amount, and one to you (or your team) letting you know a payment landed. Both come from your domain with your branding — not a generic notification from a third-party platform. For subscriptions, a renewal receipt goes out on each billing date. For deposit-plus-balance flows, each payment gets its own receipt with clear language about what was charged and what remains. These emails aren't cosmetic — they're the record your customer references if they ever need to look up what they paid, and they're what prevents "did my payment go through?" support messages.
A payment flow built for how your business collects money
Not every business collects money the same way, and the checkout should reflect yours. A single service at a flat price is a different flow from a package selector where the customer picks from three options at different prices. A deposit at booking with a balance due at project completion is different from a monthly subscription. A one-time purchase of a digital product is different from a pay-per-session model. The integration is built for your actual payment model, not bent to fit a template that was built for something else. A checkout designed for a different payment model always has edge cases that break the business logic you depend on.
Useful error messages when a card doesn't go through
When a card is declined, the checkout tells the customer something specific: "your card was declined by your bank," "your card has expired," or "insufficient funds" — not a vague "something went wrong" that leaves them guessing and clicking away. The checkout stays in place so they can update their card details and try again without starting over. For subscription renewals, a failed charge automatically triggers a retry schedule and a customer email asking them to update their payment method. Getting this right is the difference between a sale that recovers from a declined card and one that's lost because the error was confusing.
Full test run before your first real customer pays
Before the integration goes live, every scenario gets tested in the processor's test environment — a duplicate system that runs exactly like the real thing but with fake card numbers. That includes: a successful payment, a card decline, an expired card, payment confirmation delivery, the receipt email landing in an inbox with correct content, the success page loading properly, and the cancel page handling an abandoned checkout. For subscription integrations, renewal simulation gets tested too. Nothing goes live until every scenario passes. Payment flows are not something you test in production with real customers to see what happens.
What your customers are thinking the moment your checkout appears
Most business owners think the hard part is getting a customer to want to buy. But there's a second decision that happens right at the checkout: "Do I trust this specific website enough to hand over my card right now?" That decision takes about ten seconds, and it's based on signals your customer probably couldn't articulate if you asked them. Understanding what those signals are is why the checkout flow is designed the way it is.
The first thing a cautious buyer checks is the URL in the browser bar. If clicking "Pay Now" takes them to a different domain—a third-party checkout platform, a payment tool's subdomain, anything that isn't your website—a meaningful portion of customers hesitate or abandon. They clicked to pay you. Now they're on an address they don't recognize, and that mismatch registers as a warning sign even for people who can't explain why. A checkout embedded directly on your domain, where the URL stays consistent from the moment they landed on your site to the moment they complete payment, removes that hesitation entirely. It's not about aesthetics. It's about whether the customer feels like they're still on your site.
The second thing they check is what they're being asked to pay for. A checkout page that just says "$250" with a card form underneath converts worse than one that restates the service, the amount, and any relevant details — "Photography session deposit, June 14, 2:00 PM — $300." The customer wants to confirm, before entering their card number, that they're paying for the thing they agreed to. An order summary on the checkout page answers that question before they even think to ask it. Without it, some customers pause and go look for clarification. Enough of them don't come back.
The third signal is what happens immediately after. A customer who pays and lands on a blank page, a broken redirect, or a generic "thank you" with no transaction reference doesn't know whether anything happened. They check their bank app, see a pending charge, and if there's no confirmation email within a few minutes, some of them dispute the charge. Not because they want a refund — because they're not certain the payment actually processed. A confirmation page that loads instantly after payment and a receipt email that arrives within seconds close that loop. That combination is what separates a checkout people trust from one that generates confused support messages and unnecessary disputes.
None of this is about making the checkout "look nice." It's about how payment anxiety works and what a well-built checkout does to address it at each point in the decision. The security backend (card data goes to the processor, not your server; payments get verified before receipts go out) handles the actual security. The checkout design handles the perceived security—what the customer is evaluating before any of the technical layer even matters to them.
Where payment flows break — and what it costs you
The payment flow for a service business runs from "I want to pay this person" to "payment confirmed and receipt in hand." The gap between those two moments is shorter than most business owners expect. Most leaks in that gap come from specific, fixable problems in checkout design.
Vague checkout with no order summary. A customer who's ready to pay but lands on a checkout showing only a price and card form—no service name, no date, no breakdown of what they're getting—pauses. Some back out to re-read your services page. Some email you to confirm before paying. Some don't return. Adding a clear order summary to the checkout page answers the question before it becomes hesitation.
Unhelpful decline messages. A customer with a perfectly valid card who sees "Your payment could not be processed" with no further explanation tries once, maybe twice, and then either calls you or gives up. The same customer seeing "Your card was declined by your bank — try a different card or contact your bank" has something to act on. Specific error messages recover declined-card situations at a meaningfully higher rate.
No confirmation after payment. A customer who pays and lands on a blank page—or worse, an error page because the redirect broke—has no idea whether their money moved. They'll contact you. If you don't respond within hours, some will dispute the charge with their bank. A confirmation page that loads immediately and a receipt email sent within seconds together eliminate this contact entirely. The receipt is also the document your customer uses months later when they want to know what they paid for, so it should be clear and contain enough detail to answer that on its own.
Subscription renewals failing silently. For businesses with recurring billing, one of the most common revenue leaks is a subscription renewal that fails — card expired, card number changed after a bank reissue — and neither the business nor the customer finds out for weeks. The customer continues to receive service they're not paying for; the business eventually discovers the gap in revenue. With a properly wired integration, a failed renewal charge immediately triggers customer notification emails asking them to update their card, with a retry schedule and a grace period before the subscription is paused. Most customers with a failed renewal fix it within a day or two when prompted. Without the prompt, many never realize it happened until they lose access.
Why payment plugins and third-party checkout tools are not the same thing
If you're currently using a payment plugin on WordPress, a hosted checkout tool like Gumroad or ThriveCart, or a "pay me" button from a booking platform, you already have something that works well enough to take money. But "works well enough" and "built to spec for your business" are different things, and the gaps show up in exactly the situations where you need the payment flow to be airtight.
WordPress payment plugins are designed to work on every WordPress site that exists — which means they can't make any assumptions about how yours is built. The tradeoff is a checkout that's generic by design: it can't be deeply integrated into your specific page flow, it uses the plugin's receipt template instead of yours, and its webhook handling is whatever the plugin developer decided to build — not what your payment model actually needs. And when the plugin conflicts with another plugin after a WordPress update (which happens with payment plugins more than almost any other category), your checkout breaks and you're debugging someone else's code with no visibility into what went wrong.
Third-party checkout platforms (Gumroad, ThriveCart, SendOwl, and similar tools) have a different tradeoff: the checkout lives on their domain, not yours. Your customer leaves your site, pays on a platform you don't control, and either returns or doesn't. You don't own the checkout experience, the receipt emails, or the customer data that lives in their system. If that platform changes its pricing, removes a feature, or shuts down, your payment flow breaks on their schedule. Monthly platform fees compound over time on top of the processor's per-transaction rate. The customer data in their system is theirs to export on their terms.
A custom integration built directly against Stripe, Square, or PayPal eliminates all of these tradeoffs. The checkout lives on your domain. The emails come from your domain. The customer data stays in your database. The webhook handler is written for your specific payment model. There are no plugin conflicts, no platform fees, and no third party between you and your customers' transactions. When a plugin is good enough versus when a custom integration is worth building comes down to this: if your checkout is a meaningful part of how clients decide to hire you—rather than a rarely-used link buried on a pricing page—the custom integration pays for itself through lower abandonment and cleaner operations.
Pricing
Payment integration is priced as a standalone add-on when added to an existing site, or folded into the overall project cost when part of a new site build.
Standalone add-on pricing by complexity:
- Simple checkout (one product or service, flat price, receipt email): starting around $400.
- Package or multi-option selector (customer picks from 2–4 options at different prices): $500–$700.
- Deposit plus balance (pay now, pay the rest later): $600–$800.
- Subscription billing with customer self-service and failed-payment handling: $700–$1,200.
- Custom processors (Authorize.net, Braintree, others): add $100–$300 over equivalent Stripe scope — these take longer to set up.
For new site builds, payment integration is part of the overall project cost. A multi-page site with integrated checkout starts at $2,800–$5,000. Full e-commerce builds — product catalog, inventory, order management — are scoped separately as web application projects. Full pricing → · Custom e-commerce development →
Payment integration questions
Stripe is the default recommendation for most small businesses. It handles every major card type, supports subscriptions right out of the box, and has the cleanest setup process of any processor. Square is a great fit if you already use Square for in-person sales — you get one dashboard for online and offline payments, which makes bookkeeping easier. PayPal is available when your customers specifically expect it, and works well alongside Stripe rather than as a replacement.
Other processors like Authorize.net and Braintree are in scope too, though they take longer to set up because their systems are more complex. If you're not sure which one fits your business, that's part of the conversation before any work starts. Get in touch →
For a simple setup — one service, one flat price, card form, and a receipt email — it starts around $400 added to an existing site. More involved setups run higher: multiple packages at different prices ($500–$700), deposit-now-balance-later flows ($600–$800), and subscription billing with customer self-service ($700–$1,200).
For new site builds where payments are included from the start, it's part of the overall project cost. A full multi-page site with payments starts at $2,800–$5,000. See full pricing →
Your customers' card numbers never travel through your website at all. When a customer types their card info into the checkout form, it goes directly from their browser to Stripe (or whichever processor is used) before anything reaches your site. What comes back is a token—just a code that references the card, with no card details. Your server uses that token to complete the charge.
This means even if someone got into your server, there's no card data to find there. The payment processor holds the actual card data in their own secured systems. This isn't a bonus feature. It's how the integration is built from the start.
Everything needed for money to move from your customer's account to yours, with a proper paper trail. That means: a checkout form or button, secure card handling that keeps card data off your server, the backend code that confirms and processes the charge, a verification system that confirms payments went through before sending receipts, a branded confirmation email to the customer, a notification to you when a payment lands, and a success page that clearly tells the customer their payment went through.
For subscription billing, it also covers setting up the recurring charge schedule, handling failed renewals, and giving customers a way to update their payment method or cancel. Everything gets fully tested in a test environment before going live with real customers.
Most checkout tools rely on redirecting the customer to a success page after they click pay—which sounds reasonable until you realize anyone who knows that page's URL can reach it without paying. Instead, we use a confirmation system: the payment processor sends a secure message directly to your site the instant a payment goes through. Your site reads that message and knows it's genuine before doing anything else.
Only once your site receives and verifies that secure message does it send receipts, mark the order paid, activate a subscription, or trigger whatever the payment is supposed to unlock. This is how you avoid the support nightmare of customers arriving at the success page without actually having paid. Every integration includes this verification system built in and tested. It's not optional—it's standard.
Yes — adding payments to an existing site is one of the most common standalone requests. Your existing pages stay as-is; the payment form, checkout flow, and confirmation emails are built on top. You don't need a new website to get a working checkout.
How long it takes depends on how your current site is built. A straightforward PHP site is usually a one-week job. WordPress sites are in scope but take longer because payment code needs to stay separate from the plugin ecosystem to avoid breaking when WordPress or another plugin updates. If you're not sure what your site is built on, send me the URL — I'll tell you what I'm working with before quoting anything.
Yes. This is a common setup for photographers, contractors, event planners, consultants, and anyone who takes a booking deposit before starting work and collects the balance at a later date. The customer pays the deposit when they book, and their card can be saved on file securely (by Stripe — not stored on your server) so they don't have to re-enter it when the balance is due.
When you're ready to collect the remaining amount, you either trigger it manually through a simple admin view or set it to charge automatically on a specific date. Both payments generate their own receipts. The customer always knows exactly what they paid and what remains.
Yes. A customer enters their card once at signup and gets charged automatically on whatever schedule you set—weekly, monthly, quarterly, or annually—without needing to do anything again. If a renewal charge fails (card expired or replaced), the system automatically retries on a schedule you configure and sends the customer an email asking them to update their card info.
Customers can cancel or update their payment method themselves through a page on your site, without needing to contact you. If you offer multiple subscription tiers, customers can upgrade or downgrade with automatic billing adjustments. All of this runs automatically once it's set up correctly.
The checkout shows a specific, helpful error message based on what went wrong: "your card was declined," "your card has expired," or "insufficient funds"—not a vague "something went wrong" that leaves them confused. The checkout stays in place so they can correct their card details and try again without starting over.
For subscription renewals, a failed charge triggers automatic retry attempts, customer emails asking them to update their card, and a grace period before the subscription pauses. Showing the customer a clear, specific error message instead of a generic one recovers a meaningful percentage of sales that would otherwise be lost.
Yes, through Stripe. Apple Pay shows up automatically in Safari on iPhones and Macs when the customer has a card in their Apple Wallet. Google Pay appears in Chrome and on Android when they have a saved card. Both let the customer complete checkout with a single tap or Face ID confirmation instead of typing their card number—which dramatically reduces cart abandonment on mobile.
Setting this up requires a small verification file placed on your server (Stripe provides it; setup takes a few minutes) and secure HTTPS on your domain. These payment options are Stripe-specific and don't work the same way with Square or Authorize.net.
Refunds are handled through the Stripe dashboard (or whichever processor you use). You find the payment, click refund, and choose whether to refund the full amount or partial. Your site automatically sends the customer a refund confirmation email and updates the payment record. Refunds on credit cards take 5–10 business days to appear on the customer's statement—that's the card network's timeline, not something that can be sped up.
If you want to trigger refunds from your own website instead of logging into Stripe, that can be built as a custom admin panel and quoted separately. Most small service businesses don't need this feature.
Credit card companies have strict security requirements for websites that handle payments. The good news: most of that responsibility falls on the payment processor (Stripe, Square, PayPal), not on you—specifically because the integration is built so card numbers never pass through your website or server. You're not storing, processing, or transmitting card data, which means you avoid the riskiest compliance requirements.
What does apply is standard security practice: keeping your site software updated, using secure HTTPS for your domain, and not storing sensitive information you don't need. The integration accounts for all of this from the start.
Switching processors is possible but it's not a simple configuration change—it means rewriting the payment-specific code, because Stripe, Square, and Authorize.net all work differently under the hood. The checkout form, success pages, and email templates can carry over; the payment processing logic itself gets replaced. The integration is built so all payment code is clearly separated from the rest of the site, making a future switch as straightforward as possible.
If you're using subscriptions or deposit flows with saved customer cards, switching also involves moving those customer records. Choosing the right processor from the start is the better path, and that's part of what gets figured out before any work begins.
A simple single-service checkout added to an existing site: about one week from start to go-live, including full sandbox testing. A multi-option package selector: one to two weeks. Deposit plus balance: one to two weeks. Subscription billing with customer self-service: two to three weeks.
These timelines include testing every scenario before launch: successful payment, declined card, failed webhook, receipt email delivery, and subscription renewal simulation. I'll give you a specific timeline after reviewing your current site and understanding your payment model. I won't commit to a timeline I can't keep, and I won't start until the payment flow is fully defined so there are no surprises mid-build.
Related services: online booking integration · full e-commerce development · client portal development · web application development
Tell me what you're collecting payments for and how.
One-time service, deposit at booking, monthly subscription, or package selector — describe your payment model and I'll scope the integration and quote a timeline.
Get a quote