Payment Gateways

WordPress E-Commerce with WooCommerce

Chapter 5 · Payment Gateways

Chapter 4 named a payment gateway as the piece that "takes over to actually collect payment" once an order is created, without saying how. This chapter covers that mechanism in real detail — and, more importantly, the single distinction that determines whether a store takes on a light or a genuinely heavy compliance burden.

What a Payment Gateway Plugin Actually Does

A payment gateway is its own separate plugin — WooCommerce Stripe Gateway, WooCommerce PayPal Payments, and similar — built against WooCommerce's own Payment Gateways API. Once activated and configured with API credentials, it adds itself as a selectable payment method at checkout and takes responsibility for one specific job: actually collecting payment for the order Chapter 4 already described being created.

Hosted & Tokenized Processing — The Distinction That Matters Most in This Chapter

Every reputable modern gateway is built around the same principle: the store's own server never sees the customer's raw card number. Two common ways this is achieved:

  • Fully hosted / redirect — the customer is sent to PayPal's own site (or a fully-hosted Stripe Checkout page) to enter payment details, then returned to the store once payment completes. Card data never touches any page the store itself serves.
  • Embedded, tokenized fields (Stripe Elements) — card input fields appear directly on the store's own checkout page, but they're rendered inside an isolated frame served by Stripe itself, not the store's own code. Stripe's own JavaScript (Stripe.js) converts the entered card details into a one-time token before anything is sent to the store's server at all.
<?php // conceptual server-side flow — the store's server only ever // receives a token, never a raw card number $payment_method_id = $_POST['stripe_payment_method_id']; // e.g. "pm_1N..." $intent = $stripe->paymentIntents->create( array( 'amount' => $order->get_total() * 100, 'currency' => 'usd', 'payment_method' => $payment_method_id, 'confirm' => true, ) ); ?>

Notice what's missing entirely: at no point does this code — or anything else running on the store's own server — ever read, log, or store an actual card number. The token stands in for it.

Why This Distinction Sets the Store's Own PCI-DSS Compliance Burden

PCI-DSS (the Payment Card Industry Data Security Standard) applies to any system that stores, processes, or transmits cardholder data. Compliance is self-assessed against one of several Self-Assessment Questionnaires (SAQs), and which one applies depends directly on how much a merchant's own systems are actually exposed to raw card data.

Why the hosted/tokenized approach keeps compliance genuinely light
A store that fully outsources card handling this way — never having raw cardholder data touch its own server or database at any point — qualifies for one of the lightest available SAQ tiers (commonly SAQ A, or a closely related variant depending on exactly how the fields are embedded). This is the direct, practical payoff of the architecture described above: the store's own compliance burden is small specifically because it never becomes a system that stores, processes, or transmits cardholder data in the first place.
The mistake this chapter exists to head off
A developer who builds a fully custom checkout form — plain HTML fields for card number, expiry, and CVV, posted directly to the store's own server before ever being sent to a processor — has just built a system that genuinely processes and transmits raw cardholder data. That store no longer qualifies for a light SAQ tier at all; it falls under a far more demanding assessment (such as SAQ D), with real infrastructure-level security requirements most WordPress hosting was never designed to satisfy. This isn't a purely theoretical risk — it's the single most common way a well-meaning custom checkout accidentally creates a serious compliance liability, and it's exactly the mistake Chapter 7's own security chapter assumes has already been avoided.

Test Mode — Never Skip It

Every major gateway provides a sandbox environment with separate test API keys and dedicated test card numbers (Stripe's own 4242 4242 4242 4242 is the best-known example) that simulate a full, realistic checkout with no real money ever moving. WooCommerce's own gateway plugins expose a Test mode toggle that swaps live API keys for sandbox ones.

Two mirror-image real mistakes, both worth checking for before launch
Leaving Test mode enabled after launch means real customers' checkout attempts silently fail to charge anything — the store looks broken to a paying customer. Disabling it too early, during active development, means genuine live card numbers can be submitted against a site still being actively debugged. Confirming which mode is active, deliberately, before every deploy is a small habit worth building early.

Multiple Gateways, One Checkout

A store isn't limited to one gateway — Stripe and PayPal can both be enabled simultaneously, letting the customer choose at checkout. WooCommerce records which gateway processed a given order, along with that gateway's own transaction ID, as order meta — the same underlying mechanism Chapter 2 already covered for storing a product's price or SKU, applied here to an order instead of a product.

Hands-On Exercises

Exercise 1

A junior developer proposes building a custom checkout page with plain HTML fields for card number and CVV, posted directly to the store's own PHP backend, arguing it will look more "on-brand" than Stripe's embedded fields. Explain the real, concrete consequence of this choice using this chapter's own material.

📄 View solution
Exercise 2

Explain what a "token" actually represents in the Stripe payment flow this chapter describes, and why the store's server receiving only a token — rather than a raw card number — is the specific detail that keeps the store's own compliance burden light.

📄 View solution
Exercise 3

A store launches with Test mode still enabled on its Stripe gateway. Describe what a real customer would actually experience trying to check out, based on this chapter's own explanation of what Test mode does.

📄 View solution

Chapter 5 Quick Reference

  • A payment gateway is its own plugin, built against WooCommerce's Payment Gateways API, responsible for actually collecting the payment Chapter 4's checkout flow creates an order for
  • Hosted/redirect and tokenized embedded fields (Stripe Elements) both keep raw card data off the store's own server entirely
  • This is why hosted/tokenized processing qualifies a store for a light PCI-DSS self-assessment tier (commonly SAQ A or a close variant) — a custom form posting raw card data to the store's own server does not, and lands in a far heavier tier instead
  • Test mode swaps live API keys for a gateway's sandbox environment — verify deliberately which mode is active before every launch and every development session
  • Multiple gateways can be enabled at once; WooCommerce records which one processed each order, and its transaction ID, as order meta
  • Next chapter: Shipping & Tax Configuration