Most guides to WordPress payment gateways read like a shopping list: here are five plugins, pick one. The actual decision has more moving parts than that, PCI compliance, how a declined card is handled, what happens when a customer’s bank flags a transaction as suspicious, and getting those wrong costs real money in chargebacks and abandoned carts long after the plugin is installed and forgotten.

What a payment gateway plugin is actually doing

A payment gateway is the layer that moves card or bank data from your checkout page to a processor, Stripe, PayPal, Square, back, approved or declined, without that sensitive data ever touching your own server in most modern integrations. The plugin is the bridge between WooCommerce (or whatever cart system a site runs) and that processor’s API.

The distinction that trips people up: a payment gateway and a payment processor aren’t always the same company. Stripe is both, it processes the transaction and provides the gateway. PayPal is similar. Some setups separate the two, a gateway that routes to a different underlying processor, which matters mainly for troubleshooting: a declined transaction error might originate from the gateway, the processor, or the customer’s own bank, and knowing which layer to debug first saves real time during a checkout crisis.

PCI compliance, in plain terms

PCI DSS is the security standard every business handling card data has to meet, and the practical question for most WordPress store owners is how much of that burden the gateway removes. Modern gateway integrations, WooCommerce Payments, Stripe, PayPal, use hosted fields or a redirect flow so raw card numbers never pass through your own server, which keeps a store in a lighter PCI compliance tier (usually SAQ A or SAQ A-EP) rather than the much heavier tier required when a server directly handles card data.

Choosing a gateway that keeps card data off your server isn’t just a security best practice, it’s a meaningful reduction in the compliance paperwork and audit burden a small business has to carry. Any gateway plugin that asks you to store or directly process raw card numbers on your own server is a red flag worth taking seriously before installing it.

The major options, compared honestly

WooCommerce Payments

Built by WooCommerce itself, this handles cards, Apple Pay, Google Pay directly from the WordPress dashboard with no separate merchant account setup. Deposits land automatically, multi-currency is supported, and basic fraud protection is built in. The trade-off is availability, it’s not offered in every country, and stores outside its supported regions need a different primary gateway.

Stripe

The developer-favorite for good reason: clean APIs, strong documentation, native 3D Secure authentication for fraud-sensitive markets, and solid subscription billing support for anything recurring. Stripe’s fraud tools (Radar) are genuinely capable without requiring a separate service. The trade-off is that Stripe’s dashboard and settings assume some technical comfort, it’s not the most hand-holding option for a first-time store owner.

PayPal

Still the gateway with the broadest consumer trust, a meaningful share of shoppers specifically look for the PayPal option and abandon checkout without it. Pay Later and buy-now-pay-later options are built in, which can lift average order value on higher-priced items. The trade-off is a checkout experience that redirects off-site for some flows, adding friction some customers dislike, plus historically slower dispute resolution than card-network chargebacks handled directly.

Square

The strongest option for businesses that also sell in person, one dashboard covering both online WooCommerce orders and physical point-of-sale transactions, which matters for a retail business running both channels. Purely online-only stores get less differentiated value from Square specifically versus Stripe or WooCommerce Payments.

Why “just pick the cheapest one” is the wrong starting question

Gateway comparisons that lead with fee percentages are optimizing for the wrong variable first. A gateway charging half a percentage point less but missing PayPal support, failing to handle a target market’s required authentication rules, or offering weak subscription tooling will cost far more in lost conversions and involuntary churn than it saves on the headline rate. Fee percentage is a real cost, but it’s the smallest lever in this whole decision for most stores, smaller than availability, smaller than customer payment preferences, and often smaller than fraud and dispute handling.

What actually decides the choice

Geography first. Not every gateway operates in every country, and this alone eliminates options before any other comparison matters. Confirm actual availability in your business’s country and your customers’ countries before evaluating anything else.

Business model second. A store running subscriptions needs a gateway with genuinely solid recurring billing support, failed renewal handling, dunning emails, proration, not just “supports subscriptions” as a checkbox. A store selling internationally needs real multi-currency support, not just accepting a card issued abroad while displaying everything in one currency.

Customer expectations third. If a meaningful share of the target audience specifically looks for PayPal at checkout, and plenty of shoppers do, not offering it costs real conversions regardless of how good the primary gateway is on paper.

Configuring gateways so checkout doesn’t quietly leak revenue

Offer at least two payment options. A checkout that accepts only one method loses every customer whose preferred or only available method isn’t supported, and that’s a permanent, invisible tax on conversion rate that never shows up as an obvious bug.

Test the full decline-and-retry flow, not just the happy path. A customer whose card gets declined needs a clear, specific error message and an easy way to try a different method, not a vague failure that reads like the site itself is broken. Many abandoned carts blamed on “bad UX” trace back to a confusing decline message rather than the product or price.

Enable 3D Secure or its regional equivalent where the gateway supports it, particularly for markets like the EU where Strong Customer Authentication is a legal requirement, not an optional fraud-prevention nicety. Skipping this in a market that requires it doesn’t just risk fraud, it risks transactions failing to process at all.

Fraud, chargebacks, and the invoice’s hidden line item

Every gateway charges a percentage plus a flat fee per transaction, and that’s the visible cost most comparisons focus on. The invisible cost is chargebacks: a disputed transaction typically costs the merchant the transaction amount plus a separate chargeback fee, and a chargeback rate that climbs too high can get a merchant account flagged or terminated by the processor entirely.

Built-in fraud tools, Stripe Radar, PayPal’s seller protection program, WooCommerce Payments’ fraud protection, all reduce that risk meaningfully. It’s worth understanding what a gateway’s fraud tooling actually catches before assuming “PCI compliant” alone covers fraud risk. PCI compliance protects card data. It doesn’t automatically stop a stolen card from being used successfully at checkout.

Understanding the actual fee structure before signing up

Most gateways quote a headline rate, 2.9% plus 30 cents is the industry-standard baseline for card-not-present transactions, but the real cost of a gateway rarely stops there. International cards typically carry an extra percentage point or more. Currency conversion, when a store sells in one currency but a customer’s card is issued in another, often adds its own fee layer on top. Chargeback fees, usually a flat charge per disputed transaction regardless of outcome, apply whether or not the merchant wins the dispute.

Before committing to a gateway based on its advertised rate, model out the actual transaction mix a store expects: domestic versus international cards, average order value, expected dispute rate for the product category (physical goods, digital downloads, subscriptions all carry meaningfully different typical chargeback rates). A gateway that looks cheaper on the headline rate can end up costing more once that full mix is priced in.

Recurring billing and subscription-specific considerations

Subscription businesses have a payment problem regular stores don’t: card failure over time. Cards expire, get replaced after fraud, or simply decline on a renewal date for reasons that have nothing to do with the original purchase decision. Involuntary churn, subscribers who didn’t choose to cancel but got dropped due to a failed renewal charge, is a measurable and often underestimated revenue loss for any subscription business.

The gateway’s dunning management, the automated process of retrying a failed charge and emailing the customer to update their payment method, is what determines how much of that involuntary churn actually gets recovered. Stripe and WooCommerce Payments both offer configurable retry schedules and automated card-updater services that quietly refresh expired card details behind the scenes for supported card networks. A gateway or plugin combination without solid dunning tooling turns every expired card into a silent, permanent lost subscriber rather than a recoverable one.

Mobile and one-click payment methods

Apple Pay, Google Pay, similar wallet-based methods have moved from novelty to expectation, particularly for mobile checkout, where typing a full card number on a phone keyboard is real, measurable friction compared to a fingerprint or face-scan confirmation. Gateways that support these natively, WooCommerce Payments and Stripe both do, let a store offer them with minimal extra setup.

The conversion impact is largest specifically on mobile traffic, which for many stores is now the majority of visits. A store that hasn’t checked whether wallet payments are actually enabled and visible on its mobile checkout is very possibly leaving a meaningful, measurable amount of mobile conversion on the table without realizing it.

Frequently asked questions

Can I run multiple payment gateways on the same WooCommerce store?

Yes, and it’s usually the right call. Running two or three gateways side by side, a primary card processor plus PayPal, for instance, covers more customer preferences without meaningfully complicating checkout, since WooCommerce presents them as simple radio-button options at checkout regardless of how many are active.

Do I need a separate merchant account, or does the gateway plugin handle everything?

Depends on the gateway. WooCommerce Payments and Stripe bundle the merchant account into their own onboarding, no separate application needed. Some older or more specialized gateway integrations still require a traditional merchant account application through a bank or payment processor before the WordPress plugin can connect to it. Check this specifically before assuming setup is a single-step process.

How long does it actually take to get a new payment gateway live on a store?

WooCommerce Payments and Stripe can go from signup to live transactions same day for most standard businesses. Gateways requiring a separate merchant account application, or businesses in higher-risk categories, can take days to weeks for underwriting approval. Start that process well before a planned launch date if the timeline is tight.

What’s the real difference between a declined card and a failed transaction?

A decline comes from the card issuer, insufficient funds, a fraud flag, an incorrect CVV, the gateway is working correctly by rejecting it. A failed transaction is a technical error, a timeout, a misconfiguration, an API outage, where the gateway itself didn’t complete the request properly. Distinguishing the two matters for support: a decline is a customer-side issue to resolve with their bank, a failure is a site-side issue worth investigating and fixing.

Should a small store worry about PCI compliance if it’s just using WooCommerce Payments or Stripe?

The compliance burden is much lighter, but it doesn’t disappear entirely. Using a hosted-fields gateway that keeps card data off your server drops most stores into the simplest PCI self-assessment tier, a short questionnaire rather than a full audit, but that questionnaire still needs completing annually as part of maintaining a merchant account in good standing. Skipping it isn’t usually caught immediately, but it’s a real compliance gap that can surface during a dispute or an account review.

Why would a customer’s card get declined even though the same card worked fine elsewhere?

Issuing banks apply their own fraud rules per transaction, factoring in the merchant, the amount, the customer’s recent activity, and sometimes even the billing address match. A card that works fine at a familiar retailer can get flagged at a new or unfamiliar merchant purely because the bank’s fraud model hasn’t seen that pairing before. This is normal and not usually a sign of anything wrong with the store’s gateway setup, though a consistently high decline rate across many customers is worth investigating as a potential gateway configuration issue.

Is it worth adding a “buy now, pay later” option alongside a standard gateway?

For stores selling higher-priced items, often yes. Buy-now-pay-later options, offered through PayPal Pay Later, Klarna, Afterpay, similar services, have been shown to lift average order value and reduce cart abandonment specifically at higher price points, where a customer hesitates less over four smaller payments than one large one. The trade-off is an additional fee layer and another integration to maintain, worth it mainly when a meaningful share of the catalog sits above the price point where payment friction actually changes buying decisions.

Migrating gateways on a live store without breaking anything

Switching payment gateways on an operating store carries real risk that’s worth planning around rather than discovering mid-migration. Active subscriptions are the biggest one, moving recurring billing to a new gateway usually requires either a supported migration path from the old processor or, in the worst case, re-collecting payment details from every existing subscriber, which predictably costs some percentage of them who never complete the re-entry step.

Run the new gateway in parallel with the old one where possible, testing real (small) transactions before fully cutting over, and schedule the actual switch for a low-traffic window rather than mid-launch or mid-promotion. Keep the old gateway’s historical transaction records accessible for accounting and dispute purposes even after it’s no longer processing new orders, chargebacks on transactions from months earlier can still arrive after a switch is complete.

The actual decision framework

Confirm gateway availability in your country and your customers’ countries first, that alone eliminates most of the field. Match the surviving options against the business model, subscriptions, international sales, in-person plus online, and against customer payment preferences specifically. Then configure whatever’s chosen properly: multiple options, tested decline handling, fraud protection actually turned on, not just installed and left at default settings. The plugin choice matters less than most comparisons suggest. The configuration afterward matters more.

Run one real transaction through the finished checkout before calling it done, on both desktop and a phone, and read the confirmation email a customer would actually receive. That final check catches more real problems than any feature comparison ever will.