How to Accept Payments on Your WordPress Site

This guide shows you how to take real money from visitors on your WordPress site: a one-off card payment, a donation, a booking deposit, or a recurring subscription, without turning your website into a full online shop. It explains the pieces involved (a payment processor, a checkout, and usually a small plugin), how to pick a processor that actually suits a South African or Irish business, how to keep card details off your server so the security burden stays small, and how to tell when a heavyweight store platform such as WooCommerce is more than you need. The words for this vary: a payment processor is also called a payment gateway or a merchant provider, a one-off charge is a single or single-payment transaction, and a repeating charge is a subscription, recurring payment or membership. The advice here applies whichever labels you meet, and it deliberately describes what a good setup must do rather than pushing any one plugin or provider.

One thing to clear up before you start, because it confuses people. This guide is about collecting money from your own visitors on your own WordPress site. That is a completely separate matter from paying your Noiz hosting invoice, which you do in the Noiz client area using the payment options offered there. The checkout you build on your WordPress site has nothing to do with how you pay Noiz.

Last reviewed: 27 July 2026, against WordPress 7.0.2 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress, payment-processor and PCI documentation linked below. It is general guidance on accepting payments, not legal, tax or financial-compliance advice; where those matter to your business, confirm your obligations with a qualified adviser.

Official Documentation Reference

• WordPress Plugin Directory (WordPress.org): where you find and vet the payment and payment-form plugins referred to in this guide, with ratings, active-install counts and last-updated dates.
• Stripe Checkout and Payment Links (Stripe Docs): how a hosted, processor-run checkout collects card details so they never reach your own site.
• PayPal Checkout (PayPal Developer): how PayPal's hosted buttons and checkout flow work for one-off and recurring payments.
• Strong Customer Authentication (Stripe Docs): why European cards trigger an extra verification step, and how a modern checkout handles it for you.
• PCI DSS Document Library (PCI Security Standards Council): the current card-industry security standard (PCI DSS v4.0.1) and the self-assessment questionnaires that apply to small merchants.

Prerequisites

• You can log in to your WordPress admin dashboard as an administrator, so you can install a plugin or add a payment block.
• Your site is served over HTTPS (its address begins https:// and shows a padlock). This is not optional for taking payments, and Noiz hosting supports free SSL certificates so every site can meet it.
• A business email address and, for most processors, some business or identity details to open a merchant account. You do not need this before reading, but you will need it before you can accept a live payment.

First Decision: Do You Actually Need a Shop?

The most expensive mistake at this stage is reaching for a full e-commerce platform when you only need to take a payment. WooCommerce and platforms like it are excellent, but they are shops: they bring a product catalogue, a cart, stock levels, shipping rules, tax tables, order management and a long tail of extensions. All of that is machinery you then have to configure, secure and keep updated. If you are not running a shop, it is weight you carry for nothing.

Ask yourself what you are really selling. If the honest answer is one of the following, you almost certainly do not need a store:

• A single product, service or digital download.
• Donations or "pay what you like" contributions.
• A booking deposit, consultation fee or invoice payment.
• A membership, course or subscription billed on a schedule.
• A handful of fixed-price items with no stock to track and nothing to ship.

For every one of those, a lighter tool does the job: a single payment button, a payment form, or a hosted payment link. Each is faster to set up, faster to load for your visitors, and far less to look after. A full store earns its keep only when you genuinely have a catalogue: many products, variations, stock to manage, shipping to calculate, coupons, and the rest. If in doubt, start light. It is easy to grow into a store later, and painful to strip one back.

How an Online Card Payment Actually Works

Understanding the shape of a payment saves you from a great deal of confusion later, and it explains why the security side is simpler than it sounds.

Three parties are involved. There is your visitor with their card, there is your WordPress site, and there is a payment processor: the company that is actually licensed to move money between the visitor's bank and yours. Your site's job is not to handle the card. Its job is to hand the visitor over to the processor at the right moment, for the right amount, and to find out afterwards whether the payment succeeded.

The card details are collected by the processor, not by you, and this is the single most important idea in the whole guide. A well-built integration does this in one of three ways:

• Hosted checkout or payment link (redirect). Your visitor clicks, and their browser goes to a secure page hosted by the processor to enter their card, then returns to your site. The card never touches your server at all. This is the simplest and safest option and often needs no plugin.
• Embedded fields (iframe). The card fields appear on your own page, but they are actually served from the processor inside a secure frame, so the numbers still go straight to the processor and bypass your server. This looks seamless while keeping the card off your site.
• Raw card handling on your own server. Your site collects and transmits the card number itself. Avoid this. It drags you into the heaviest security obligations and there is no good reason for a small site to take it on.

In the safe methods, the processor turns the card into a harmless token, a reference it uses to take the money, and that token is all your site ever sees. Because the card details never reach your WordPress install or Noiz's servers, there is nothing sensitive there for an attacker to steal, and your own security duties shrink to the lightest tier. Keep that principle in mind and most of the later advice follows naturally.

Choosing a Payment Processor

The processor is the decision that matters most, and it is one where advice written for a United States audience will actively mislead a South African or Irish business. Choose on the criteria below rather than on which name you have heard of.

The South African Reality (Read This Before You Pick)

Two things routinely trip up South African site owners:

• Stripe does not offer standalone accounts to South African businesses. Stripe is superb and widely written about, but a business registered in South Africa cannot simply open a Stripe account and settle in rand. Stripe's South African presence runs through its "extended network" via a partner processor it owns (Paystack). In practice, a South African merchant who wants Stripe-style card processing paid out in rand signs up with that local processor rather than with Stripe directly. If your business is registered in a country Stripe supports directly (Ireland among them), this does not apply to you and you can use Stripe as written.
• PayPal in South Africa is built for money coming in from abroad. You can receive PayPal payments in South Africa, but the balance is held in a foreign currency and you withdraw it to your local bank through a currency conversion. That makes PayPal excellent for selling to international customers and inefficient for selling to South Africans who just want to pay in rand, because the conversion eats into every sale.

The practical upshot: if most of your customers are South African and pay in rand, look first at processors built for the South African market, which settle directly to a local bank account in rand and offer the payment methods your customers actually use, including cards and instant bank transfer (EFT). If your customers are mostly international, a globally recognised processor at checkout is worth more. Many businesses end up offering one of each.

A Comparison You Can Actually Use

Rather than ranking brands, weigh any processor you are considering against these questions. The answers, taken together, point clearly to the right choice for your business.

• Can your business even open an account with it? Check your country is supported for a settling account, not just for paying. This is the question that eliminates Stripe direct for South African merchants, as above.
• What currency does it pay you in? If you sell in rand, a processor that settles in rand to a local bank avoids conversion losses on every transaction. A processor that settles in a foreign currency is only sensible if your customers are paying in that currency too.
• Which payment methods do your customers use? Cards are universal, but South African buyers often expect instant EFT and mobile options, and offering the method people prefer measurably reduces abandoned checkouts.
• Does it support the kind of payment you need? Some processors do one-off charges beautifully but handle recurring billing poorly, or vice versa. If you need subscriptions, confirm that up front (see the next section).
• How does it integrate? Prefer a hosted checkout, hosted payment link or embedded (iframe) fields, all of which keep card data off your site. Treat any option that wants your server to handle raw card numbers as a reason to look elsewhere.
• What does it cost, and when do you get paid? Compare the per-transaction fee, any monthly fee, and the payout delay (some pay out next day, others weekly). For low volumes, a provider with no monthly fee usually wins.
• Is it trusted at the point of payment? Visitors abandon checkouts they do not recognise or trust. A familiar, professional-looking payment step converts better than a cheaper one that looks improvised.

Whichever you choose, you will connect it to WordPress with a small plugin (the processor almost always publishes an official one, or names a recommended partner plugin). The plugin is just the bridge; the processor is doing the real work.

Setting Up One-Off Payments

For a single price, a donation or an invoice, you have two clean routes. Pick whichever fits how much you want to keep inside WordPress.

Route A: A Hosted Payment Link (Often No Plugin at All)

Most modern processors let you create a payment link from inside their own dashboard: you set an amount (or let the payer choose), and the processor gives you a web address that opens a ready-made, secure checkout page. You then simply add that link to a button on your WordPress page.

1. In your processor's dashboard, create a payment link for the amount and description you want, and copy the address it gives you.
2. Edit the WordPress page or post where you want the button. Add a Buttons block, type the label (for example Pay now or Donate), and paste the payment link as its destination.
3. Publish, then click the button yourself to confirm it opens the processor's checkout with the right amount.

This route is the lightest possible: nothing sensitive runs on your site, there is little to maintain, and it is ideal for occasional payments, invoices and donations. Its limit is that the payment happens on the processor's page rather than yours, and it offers less control over the look and over what happens next.

Route B: A Payment Form or Button Plugin

When you want the payment to feel part of your site, or you want to collect a little information alongside it, install a dedicated payment-form or payment-button plugin. This is a different tool from a full shop: it adds a single form or button, not a catalogue.

1. Choose a plugin from the WordPress Plugin Directory that officially supports your chosen processor. Favour one that is actively maintained, tested against current WordPress, well reviewed, and widely installed, then install and activate it under Plugins > Add New Plugin.
2. Connect it to your processor by pasting in the keys (sometimes called API keys or a client ID) from your processor's dashboard. Start with the test keys, not the live ones.
3. Create a payment form or button (a fixed price, a "name your amount" field, or a short form with a few extra fields), set the currency to the one you settle in, and place it on a page using the block or shortcode the plugin provides.
4. Test the whole thing in test mode before switching to live keys (covered under testing, below).

If you are on a managed Noiz plan and would rather not install and wire up a plugin yourself, the Noiz support team can do the setup for you once you have opened your merchant account with the processor. You would still hold the processor account and its keys; Noiz simply connects it to your site.

Setting Up Recurring Payments and Subscriptions

Charging the same person every month (a membership, a course, a subscription box, a retainer) is a genuinely different job from a one-off charge, and it has two traps worth knowing about before you begin.

Let the Processor Own the Schedule

The safe way to do recurring billing is to let the processor manage the subscription. You define a plan (amount, interval, any free trial) in the processor's dashboard, and a subscription-capable plugin creates and links that plan to your WordPress content, for example unlocking a members' area while the subscription is active. The processor then charges the saved card automatically on schedule, using the token it stored on the first payment. Your site never re-handles the card. Confirm, before you commit, that both your processor and your plugin explicitly support recurring billing; not all do, and retro-fitting it is painful.

European Cards and Strong Customer Authentication

If any of your customers are in Europe, their first payment will usually trigger an extra verification step (a bank prompt on their phone, or a code). This is Strong Customer Authentication, required by European rules, and it is a feature, not a fault: it cuts fraud and chargebacks. A modern hosted checkout handles it for you and sets up the subscription so that later automatic charges do not need the customer present. This is one more reason to use the processor's current checkout rather than an older, hand-rolled card form.

The Renewal Gotcha: WordPress Cron on a Quiet Site

Here is a Noiz-specific point that catches subscription sites out. Many subscription plugins lean on WordPress's built-in scheduler (often called wp-cron) to do their housekeeping: retrying a failed renewal, expiring a lapsed membership, sending a reminder. The catch is that this scheduler only runs when someone visits your site. On a busy site that is constant and fine. On a quiet membership site, hours can pass with no visitor, the scheduler does not fire, and renewals or expiries run late.

The dependable fix is to drive the scheduler from a real server cron job instead of relying on visitor traffic. On Noiz hosting you can add a scheduled task in your hosting control panel that pings your site's scheduler at a fixed interval (every fifteen minutes is a common choice), which makes renewals fire like clockwork regardless of how quiet the site is. The exact screen depends on your platform, the Plesk panel on the South African servers, DirectAdmin in Ireland, or ISPConfig, but each has a scheduled-tasks or cron section for this. If you are on a managed plan, ask the Noiz support team to set this up; it is a small change that prevents a whole class of "my subscriptions did not renew" problems.

Checkout Security and PCI Basics

Taking card payments comes with a security standard attached: PCI DSS, the Payment Card Industry Data Security Standard, currently at version 4.0.1. Every business that accepts cards is bound by it. That sounds daunting, but for a small WordPress site the burden is small provided you follow one rule, and most of this section is really just consequences of that rule.

The rule: never let card details touch your server. Use a hosted checkout, a payment link, or embedded processor fields, exactly the safe methods described earlier, so that card numbers go straight from the visitor's browser to the processor. When card data never lands on your site, you fall into the lightest compliance tier (a short self-assessment questionnaire known as SAQ A) rather than the heavy obligations that apply to anyone handling raw card numbers. This single choice is the difference between a five-minute form and a security project.

Around that rule, a handful of straightforward measures keep your checkout trustworthy:

• Serve the whole site over HTTPS. Not just the checkout page: modern browsers and processors expect the entire site encrypted, and Noiz hosting includes free SSL certificates so there is no reason not to.
• Confirm payments from the processor, not from the browser. A visitor reaching your "thank you" page does not prove they paid; they might have closed the tab, or reached it by accident. Every serious processor can send your site a webhook, a direct server-to-server message confirming the payment really succeeded. Make sure your plugin uses it, so access or fulfilment is granted on the confirmed payment, never on the redirect alone.
• Keep the payment page lean. The newer parts of PCI DSS, which became effective through 2025, focus on the scripts running on payment pages: unexpected third-party code on a checkout is exactly how card-skimming attacks work. Do not load chat widgets, analytics extras, advertising pixels or decorative scripts on the page where the payment happens. Fewer scripts on that page means less risk and one less thing to justify.
• Keep everything updated. WordPress core, your payment plugin and every other plugin. An out-of-date plugin is the most common way a site is compromised, and a compromised site around a checkout is the worst place for it to happen. This sits inside the broader routine covered in the Noiz WordPress Security Checklist, which you should treat as the companion to this guide.
• Protect the admin account. A strong, unique administrator password and, ideally, two-factor login. Whoever holds the WordPress admin can change where your money goes, so guard it accordingly.

Testing Before You Go Live

Never point a new checkout at real cards without testing it first. Every reputable processor gives you a test or sandbox mode with fake card numbers that behave like real ones without moving any money.

1. With your plugin still on the processor's test keys, run a full payment using the processor's published test card details. Confirm the amount, currency and description are all correct.
2. Check that your side reacts properly: the order or record appears, the confirmation email sends, and any members' area or download actually unlocks. This is where webhook problems show up, so test it deliberately.
3. For a subscription, force a failed renewal in test mode if the processor allows it, and confirm your site handles the failure the way you expect (a warning, a grace period, or loss of access).
4. Only when all of that works, swap the test keys for the live keys, and make one small real payment to yourself. Confirm the money reaches your account, then refund it from the processor's dashboard. That single live-and-refund test catches the mistakes that test mode cannot.

Troubleshooting

• Symptom: the payment button or checkout does nothing, or the browser warns the connection is not secure. Your site is not fully on HTTPS. Confirm the address shows a padlock; if not, ensure your SSL certificate is active for the whole site. Noiz hosting provides free SSL, and the Noiz support team can enable it if you are unsure.
• Symptom: customers are charged but the order does not appear, or a membership does not unlock. Your site is relying on the browser redirect instead of the processor's confirmation. Enable and test the processor's webhook so fulfilment happens on the confirmed payment. Also check that the webhook address the processor is calling matches your live site.
• Symptom: you cannot open a Stripe account for your South African business. This is expected; Stripe does not offer standalone South African accounts. Use a processor built for the South African market that settles in rand, or the partner route through Stripe's extended network. See "The South African Reality" above.
• Symptom: money arrives but is worth less than expected. You are likely settling in a foreign currency and losing value on conversion, common with a foreign-currency PayPal balance. If you sell mainly in rand, switch to a processor that pays out in rand to a local bank account.
• Symptom: subscription renewals fire late, or lapsed members keep their access. Your site is depending on visitor-triggered scheduling on a quiet site. Set up a real server cron job in your hosting panel to run the WordPress scheduler on a fixed interval, as described under recurring payments, or ask Noiz support to configure it.
• Symptom: European customers say the payment "asks for extra confirmation" or fails without it. That is Strong Customer Authentication working as intended. Make sure you are using the processor's current hosted checkout, which presents that step and completes the payment; an older custom card form may not handle it.

If you would like help choosing a processor that fits where your customers are and how you want to be paid, wiring a payment form into your site, setting up reliable subscription renewals, or checking that your checkout keeps card details off your server, open a support ticket with the Noiz support team. Tell them what you are selling, whether it is one-off or recurring, and where most of your customers are based, and they will point you to a setup that suits your business rather than a generic template.