A payment gateway decides whether card details ever touch your server. That is the most important thing about the choice, and it matters more than the transaction fee.
Let the gateway handle card data
Choose a gateway that collects card details on its own infrastructure, or in an embedded field it controls. Your site never sees a card number, and a compromise of your store does not expose card data.
The alternative: card details submitted to your server and passed on, puts you inside a compliance scope most small stores are not equipped to satisfy, and it converts any breach into a considerably more serious event.
Modern gateways offer embedded fields that look like part of your checkout while the data goes directly to them. That gives you the appearance without the liability, and it is the right default.
Setting one up
Install the gateway's official WooCommerce extension instead of a third-party integration. The official one is maintained against the gateway's API changes; a third-party one silently stops working when the API moves.
Enter the API credentials from the gateway's dashboard, and note that live and test credentials are different sets. Configuring live keys in test mode, or the reverse, produces failures that look like a broken integration.
Then set the callback or webhook URL if the gateway asks for one. This matters more than it looks: see below.
Test in sandbox, then test with a real card
Sandbox mode confirms the integration works. It does not confirm your live credentials are correct, that the callback reaches your site, or that the account is enabled for live transactions.
Place one real order with a real card and refund it. That is the only test that exercises the whole path, and it catches the failures that only appear in live mode.
The callback is what creates the order
Most gateways notify your site that a payment succeeded, and that notification is what moves the order from pending to processing.
If it does not arrive, the customer is charged and no order appears. That produces the worst support conversation a store has, and the cause is usually something on your side blocking the request. A security plugin, a firewall rule, directory protection, or a redirect that catches the callback URL.
Check the gateway's own logs when orders stay pending. They record whether the callback was attempted and what your server answered.
Offering more than one method
A card gateway plus one alternative covers most customers. Which alternative depends entirely on where you sell: the dominant method varies by country and assuming otherwise costs sales.
Do not add six. Each is another integration to keep updated, another set of credentials, and another thing running on checkout: the one page you cannot cache.
Bank transfer and cash on delivery
Both are built in and both create orders that are not paid. Make sure your fulfilment process distinguishes an order awaiting payment from one that is ready to ship, because WooCommerce will happily show both as orders.
Refunds
Configure refunds through WooCommerce rather than only in the gateway dashboard. A refund issued at the gateway alone leaves your store showing the order as paid, and the two records drift apart in a way that is unpleasant to reconcile later.
Currency and rounding
Set the store currency to what the gateway actually settles in where possible. Currency conversion at the gateway introduces rounding differences between what your store recorded and what was charged, and those differences accumulate into a reconciliation problem nobody wants to unpick.
Gateways usually notify your store of payment outcomes through a callback, and those fail silently when the receiving end is unavailable. For noticing, see WooCommerce Webhooks and Third-Party Integrations.
Keep the credentials out of the database
Gateway keys are usually stored in the site's settings, which means they sit in the database and appear in every backup and every staging copy.
Where the gateway plugin supports it, define them as constants in wp-config.php instead:
define( 'GATEWAY_LIVE_SECRET', 'sk_live_...' );
That keeps live keys out of database exports and out of any copy made for development, which is the practical risk, since a staging copy is handled more casually and by more people.
Whatever the storage, a staging site must never hold live keys. Running a staging store goes into switching them to test mode before anything else.
When the gateway changes its requirements
Payment providers deprecate API versions and tighten security requirements on their own schedule, and the notice arrives by email to whoever registered the account, frequently a developer who has moved on.
The failure is abrupt: payments that worked yesterday are refused, and nothing on your side changed.
Two precautions. Make sure the gateway account's contact address is one your business monitors, not an individual's. And keep the gateway plugin updated, since the update is usually what implements the new requirement. There is more on doing that without breaking the checkout in updating WooCommerce safely.
Reconcile against the gateway, monthly
The store's records and the gateway's records should agree. When they do not, the difference is money.
Compare the count and total of completed orders for a period against the gateway's settlements for the same period. Two discrepancies are common and both matter: a payment taken with no corresponding order: usually a callback that never arrived, and an order marked paid with no payment behind it.
Neither appears in any report until somebody looks. There is more on the first, which is the more expensive of the two in handling failed and pending payments.
Have a fallback method
Gateways have outages, and a store with one payment method has no checkout during them.
A second method (even bank transfer) means an order can still be placed. It converts a total outage into a slower checkout, and it costs nothing to have configured and disabled until needed.
Know in advance how to enable it, because the moment you need it is the moment nobody wants to be reading documentation. Preparing your store for a sales peak explains the rest of that contingency.