Payments for WooCommerce: Gateways, Testing, Fraud Basics, and Payout Reconciliation

How Payment Gateways Work (High Level)

What a gateway actually does

A payment gateway is the service that securely collects payment details, requests authorization from the customer’s bank (or wallet), and returns a success/failure result to your store. In practice there are usually multiple parties involved:

• Customer enters payment details.
• Gateway/processor (e.g., WooPayments/Stripe-like) tokenizes and routes the transaction.
• Card network (Visa/Mastercard/AmEx) passes the request to the bank.
• Issuing bank approves/declines and may request extra authentication (3D Secure).

Redirect vs on-site checkout

• Redirect: the customer is sent to a hosted payment page (common with some PayPal flows and local methods). Pros: less PCI burden and often simpler compliance. Cons: extra step can reduce conversion; return/cancel handling must be correct.
• On-site (embedded): payment fields appear on your checkout (often via an iframe or JS component). Pros: smoother checkout. Cons: more moving parts; must ensure scripts, caching, and security headers don’t break the payment form.

Tokenization (why you rarely “store cards”)

Modern gateways replace raw card data with a token (a reference ID). Your store saves the token (if you enable saved payment methods) and uses it for future charges (subscriptions, pre-orders, or one-click payments) without storing card numbers. Tokenization reduces risk and compliance scope.

Webhooks (how the gateway talks back)

A webhook is a server-to-server callback from the gateway to your site. It’s used for events that happen after the customer leaves checkout or after an asynchronous step, such as:

• Payment succeeded/failed after a delay
• 3D Secure authentication completed
• Dispute/chargeback opened
• Refund succeeded

Because webhooks are asynchronous, your site must be reachable from the internet and able to process webhook requests reliably. If webhooks fail, orders can remain in the wrong status even though money moved.

How WooCommerce Handles Orders and Payment Statuses

Key order statuses you’ll see

• Pending payment: order created, awaiting payment confirmation (common for card payments before the gateway confirms).
• On hold: payment method chosen but requires manual confirmation (often bank transfer) or you intentionally hold for review.
• Processing: payment received and stock reduced; typical for physical goods that still need fulfillment.
• Completed: order fulfilled (often used for virtual/downloadable products, or after shipping is done).
• Failed: payment failed or was declined.
• Cancelled: customer abandoned or you cancelled before payment.
• Refunded: full refund issued (partial refunds are shown in order notes and totals, but status may remain Processing/Completed depending on setup).

Typical status transitions for card payments

Most card gateways follow this pattern:

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Customer places order → Pending payment
• Gateway authorizes/captures payment → Processing (or Completed for virtual-only orders)
• You fulfill → optionally set to Completed

Some gateways support authorization only (reserve funds) and later capture (take funds). If you use this, you’ll see orders held until capture occurs.

Stock reduction and emails depend on status

WooCommerce triggers key actions based on status changes (inventory reduction, “New order” emails, “Processing order” emails, etc.). When testing a gateway, always verify that the expected emails and stock changes occur when the order moves from Pending → Processing/Completed.

Selecting a Payment Method Mix (What Customers Expect)

Card processing (WooPayments / Stripe-like gateways)

Card payments are the default expectation in many regions and usually provide the best conversion. When selecting a card gateway, evaluate:

• Regional availability: some processors are limited by country, business type, or currency.
• Fees: typically a percentage + fixed amount per successful charge; additional fees may apply for international cards or currency conversion.
• Payout timing: daily/weekly payouts; rolling reserves for new accounts; delays for high-risk categories.
• 3D Secure support: reduces fraud and can shift liability in some cases.
• Dispute handling: how evidence is submitted and how quickly you’re notified.

PayPal

PayPal can be a strong trust signal, especially for customers who prefer not to enter card details. Consider:

• Checkout flow: often redirect or popup; ensure return URL works and webhooks/IPN are configured.
• Fees: similar to card processing but can vary by country and transaction type.
• Customer expectations: some customers prefer PayPal balance; others use PayPal as a card wallet.

Bank transfer (BACS)

Bank transfer is common for B2B or high-ticket orders where customers want an invoice-like flow. It is not instant and requires manual reconciliation.

• Pros: low direct fees; no chargebacks in the card sense.
• Cons: slower fulfillment; higher abandonment; manual matching required.

Cash on delivery (COD)

COD can increase conversion in some markets, but it shifts risk to delivery time.

• Pros: accessible to customers without cards.
• Cons: failed deliveries, returns, and cash handling; consider restricting COD by shipping method, location, or order value.

A practical decision checklist

Step-by-Step: Configure Common Gateways in WooCommerce

Before you start: prerequisites

• Ensure your site uses HTTPS (SSL). Many gateways refuse to run live without it.
• Confirm your store currency is supported by the gateway.
• Disable aggressive caching on checkout/account pages (caching can break payment scripts and nonce validation).

Card processing (WooPayments / Stripe-like)

The exact screens vary by provider, but the setup flow is usually consistent:

1. Install and activate the gateway plugin.
2. Connect your account (or create one) and complete identity verification if required.
3. Choose capture behavior: capture immediately (simpler) vs authorize then capture (useful if you confirm stock or customize orders).
4. Enable payment methods: cards, and optionally wallets/local methods if offered.
5. Configure webhooks: many plugins auto-register webhooks; if manual, copy the webhook URL from the plugin settings into the gateway dashboard.
6. Set fraud controls (if available): enable CVC/AVS checks, 3D Secure rules, and risk thresholds.
7. Run test transactions (see testing section) before switching to live mode.

PayPal

1. Install and activate the PayPal integration you chose.
2. Connect PayPal account (OAuth connect is common) or enter API credentials if required.
3. Confirm return/cancel URLs are correct (the plugin usually sets these automatically).
4. Enable webhooks/IPN depending on the integration. Verify PayPal can notify your site of completed payments and refunds.
5. Test using PayPal sandbox accounts (buyer + seller) and confirm status transitions.

Bank transfer (BACS)

1. Go to WooCommerce → Settings → Payments.
2. Enable Direct bank transfer.
3. Enter bank details customers must use (account name, IBAN, sort code, reference instructions).
4. Decide your workflow: orders will typically be placed On hold until you confirm receipt and manually mark them Processing or Completed.

Cash on delivery (COD)

1. Go to WooCommerce → Settings → Payments.
2. Enable Cash on delivery.
3. Optionally restrict COD to specific shipping methods (recommended) and consider minimum/maximum order values via your shipping/payment rules (if your setup supports it).
4. Define when you consider the order paid (often after delivery). Many stores keep COD orders in Processing until fulfilled, then Completed.

Sandbox and Testing Procedures (Do This Before Going Live)

1) Enable test mode

Most gateways provide a toggle for Test/Sandbox mode. In test mode:

• No real money moves.
• You use test API keys or sandbox accounts.
• Webhooks may have separate endpoints/secret keys.

2) Use test cards and scenarios

Card gateways provide test card numbers and scenario triggers (e.g., a card number that simulates a decline). Keep a small checklist of scenarios:

• Successful payment (should go Pending → Processing/Completed)
• Declined payment (should go Pending → Failed, and customer sees an error)
• 3D Secure required (should prompt authentication and then succeed/fail)
• Refund (full and partial) and verify order notes and totals

Document what you expect to happen for each scenario so you can spot misconfigurations quickly.

3) Verify webhook delivery and signature/secret

In the gateway dashboard, you can usually see a webhook delivery log. Confirm:

• Events are being sent to your site’s webhook URL.
• Your site returns a 200-level response.
• The plugin is validating the webhook signature/secret (prevents spoofed notifications).

If you see successful payments in the gateway dashboard but WooCommerce orders remain Pending, webhook delivery is one of the first things to check.

4) Confirm order status transitions and side effects

For each test order, verify:

• Status changes: Pending → Processing (or Completed for virtual-only)
• Stock reduction occurred (if you manage stock)
• Customer email sent (processing/completed)
• Payment captured vs authorized (if you use manual capture)

5) Test edge cases that break real stores

• Customer closes the browser after paying: webhook should still update the order.
• Payment succeeds but return URL fails: order should still update via webhook.
• Multiple attempts: customer retries payment; ensure you don’t end up with multiple paid orders for the same cart.

Fraud Basics: Reduce Risk Without Killing Conversion

Understand the tradeoff

Fraud controls reduce losses but can also block legitimate customers. Start with strong defaults (CVC/AVS + 3D Secure where appropriate) and add stricter rules only if you see problems.

Enable CVC and AVS checks (when supported)

• CVC/CVV: verifies the security code. Decline or review transactions that fail CVC checks.
• AVS: compares billing address against the bank’s records (common in US/UK/CA). Treat AVS mismatches as a risk signal, not an automatic decline in all regions (AVS coverage varies).

Use 3D Secure (SCA) where available

3D Secure adds an authentication step (bank app approval, SMS, etc.). In many regions it’s required for compliance (e.g., Strong Customer Authentication). Even where optional, it can reduce chargebacks and may shift fraud liability depending on the transaction and rules.

Velocity rules and risk scoring (gateway-provided)

Some gateways let you set rules like:

• Block/review if too many attempts from the same card/IP/email in a short time
• Block high-risk countries or mismatched country/state combinations
• Review unusually large orders or unusually high quantity of a single SKU

When available, prefer review over block for borderline cases so you can learn what legitimate behavior looks like for your store.

Manual review workflow (simple and effective)

Create a consistent checklist for orders flagged by your gateway or your own rules:

• Check billing vs shipping mismatch (not always fraud, but a signal).
• Look for disposable email patterns and incomplete customer details.
• Check order history: first-time customer + high value + expedited shipping can be higher risk.
• Search the transaction in the gateway dashboard: AVS/CVC results, risk score, 3D Secure status.
• If unsure, contact the customer with a neutral verification request (e.g., confirm shipping address). Avoid asking for full card details.
• Decide: fulfill, cancel/refund, or hold for more info.

Operational tip: use On hold for orders under review so they don’t enter fulfillment automatically.

Payouts and Reconciliation: Matching Money to Orders

Charges, payouts, and why they don’t match 1:1

Gateways typically record:

• Charge: the customer payment for a specific order (gross amount).
• Fees: processing fees, sometimes separate line items.
• Payout: the net amount deposited to your bank, often bundling many charges and subtracting fees/refunds.

Because payouts are batched, a single bank deposit may correspond to many WooCommerce orders across one or more days.

Step-by-step: basic payout reconciliation process

1. Pick a payout in your gateway dashboard (it will show a date range and net amount).
2. Open the payout breakdown to see included charges, refunds, and fees.
3. Match each charge to a WooCommerce order using the order number/metadata (many plugins store the gateway transaction ID in the order notes or a payment field).
4. Confirm totals: sum of charges minus refunds minus fees should equal the payout net amount.
5. Investigate mismatches: currency conversion, delayed captures, disputes, or refunds processed after the payout period.

Refunds and partial refunds (what to verify)

Refunds can be initiated from WooCommerce (if the gateway supports it) or from the gateway dashboard. In either case, verify:

• The WooCommerce order shows the refund amount and updated order total.
• The gateway shows the refund status as succeeded.
• The payout breakdown reflects the refund (either deducted from a future payout or netted in the current one).

Partial refunds are common (e.g., one item returned). Ensure your internal process records:

• Which items were refunded
• Whether shipping/tax was refunded
• Any restocking fee policy (if applicable)

Recording fees for accounting

For clean bookkeeping, separate:

• Gross sales (order totals before fees)
• Gateway fees (expense)
• Refunds (contra-revenue or refunds expense, depending on your accounting approach)
• Net deposits (bank deposits)

A practical approach is to use the gateway’s payout report as the source of truth for deposits and fees, and WooCommerce orders as the source of truth for gross sales and refunds, then reconcile the two on a schedule (daily for high volume, weekly for lower volume).