For a small online shop, payment methods affect both the customer experience and the work behind each order. You do not need every available option: you need methods you can manage reliably. Planning WooCommerce payments starts with three questions: how do customers prefer to pay, when do funds actually reach your business, and how will you check the integration before launch?
1. Cards, bank transfers and cash on delivery: practical differences
Card payments
A card payment goes through a specialist provider connected to your shop through a compatible integration. Customers enter their details in a secure payment form or on the provider's page and may need to complete an additional authentication step. Payment confirmation and settlement into your business bank account are separate events.
The practical advantage is that confirmation can arrive without someone manually checking a bank statement. However, you still need to manage fees, settlements, refunds and possible disputes. Never collect card details through email or ordinary checkout fields.
Bank transfers
With a bank transfer, the customer receives payment instructions and sends the money from their account. In its standard configuration, this method does not automatically confirm receipt: you check your business account and match the payment to the order. Integrations offering automation also exist, but need separate assessment.
Display the account holder, IBAN, currency and payment reference clearly. Decide how long you will wait for payment and how stock should be handled in the meantime. A customer's payment receipt may help your investigation, but does not replace confirmation that the funds have arrived.
Cash on delivery
With cash on delivery, payment is collected when the parcel arrives, under the courier's service terms. Check collection charges, settlement times and the process for refused or uncollected parcels. Do not assume customers can pay by card at the door: check the service covered by your courier agreement.
You can combine methods according to your products, delivery area and working processes. Cash on delivery is generally unsuitable for digital products or services that do not involve a physical delivery.
2. What to check when choosing a payment provider
Do not choose a payment provider based only on its headline transaction fee. Consider the overall cost and how the integration fits your shop:
- Eligibility: does it support your business, country, product category and required currencies?
- Charges and settlements: which fees apply, when are funds transferred, and are there conditions concerning reserves or currency conversion?
- Compatibility: is the extension maintained and compatible with your WordPress and WooCommerce versions and your type of checkout?
- Mobile experience: are the form, redirects and authentication steps straightforward on a phone?
- After-payment tasks: how do you issue full or partial refunds and handle disputes?
- Troubleshooting: are documentation, transaction identifiers, logs and integration assistance available?
- Testing facilities: is there a sandbox with test credentials and documented ways to simulate different outcomes?
Review security and personal data requirements too. A provider-hosted payment integration can reduce your shop's exposure to card details, but it does not remove every merchant responsibility. If you sell subscriptions, explicitly confirm support for recurring payments.
3. Prepare your shop before connecting payments
Set up your currency, taxes, delivery options and business details before testing. Customers should see the final amount before confirming payment. Each payment method's description should explain what happens next without unnecessary technical language.
Check that HTTPS works correctly and review the extension's requirements. If you are choosing infrastructure for your shop, you can explore WordPress hosting and then check the technical requirements of your chosen integration. Hosting does not replace a payment provider agreement or payment configuration.
- Install the extension from an official source and read the documentation for the version you use.
- Keep test and live credentials separate, and do not expose them in screenshots.
- Configure the notification addresses required by the provider, often called webhooks or callbacks.
- Exclude dynamic pages from caching as directed by WooCommerce and the integration's documentation.
If you use a staging copy, make sure it cannot send messages to real customers or trigger fulfilment, invoicing or other external automations.
4. How to test payments when the integration supports it
Test mode simulates transactions without collecting real money, within the capabilities offered by the provider. Not every extension includes this option. Use only the test data and scenarios documented by the provider, rather than real card details in a sandbox.
- Select the correct environment. Enable test mode in the integration and enter its test credentials. Check the notification settings for that environment as well.
- Place a complete order. Add products, select delivery and check taxes, discounts and the total sent to the provider.
- Simulate different outcomes. Test successful payments, declines, cancellations and additional authentication where supported. Review the messages customers see.
- Follow the confirmation. Compare the transaction identifier and amount in both systems. Check that expected notifications and emails arrive.
- Check interrupted journeys. Where the environment allows it, test what happens if the customer does not return to the shop after paying or tries again.
- Test a refund. If the sandbox supports refunds, follow the process and inspect the information recorded.
Repeat the journey on a phone and a computer, including guest checkout if your shop supports it. For bank transfers and cash on delivery, test instructions, eligibility and communications rather than card authorisation. A sandbox cannot reproduce every live condition, so carefully review the production configuration when you activate it.
5. What to investigate when payment remains unconfirmed
Separate “were the funds collected?” from “did the shop receive confirmation?”. The return page might fail to load even though the provider has recorded a payment. Equally, the customer's return to your shop does not, by itself, prove that money was collected.
- Find the transaction at the provider: use the order reference, transaction identifier, amount, currency and time.
- Inspect notifications: check webhook delivery, the server's response and any retry attempts.
- Review logs: look for authentication, signature or connectivity errors. Do not share secret keys or unnecessary personal data.
- Check configuration: confirm test versus live mode, credentials, notification addresses and possible security blocks.
Do not immediately ask the customer to pay again. First establish whether a transaction already exists to avoid a possible duplicate. For a bank transfer, look for received funds using the reference and amount. For cash on delivery, review the courier's collection report and settlement. Do not manually record payment solely on the strength of a customer screenshot.
If the issue involves communication with the server, consult the frequently asked questions or use the contact page to provide the incident time and technical error without sensitive information. The transaction itself needs to be clarified with the payment provider.
6. Conclusion: launch with a payment process you can check
Choose methods you can manage, document how payments are verified, and test both successful and interrupted journeys. Before launch, confirm the switch to live credentials and decide who investigates unclear payments. A simple, traceable process is more useful than a long list of options enabled without testing.
