Column 1
Skip to content
Column 1

WooCommerce PayPal Payments Setup and PayPal Standard Migration Checklist

WooCommerce PayPal Payments setup and PayPal Standard migration checklist

PayPal Standard is a legacy WooCommerce payment path. Plan a controlled move to WooCommerce PayPal Payments rather than leaving an old gateway setup to drift. WooCommerce's June 2026 advisory explains that the maintained PayPal Payments integration is the path forward. The change is intentionally staged: updating the plugin alone does not disable PayPal Standard, while connecting a PayPal account to the modern integration begins the transition.

This guide is for store owners, agencies, and hosting teams who need to preserve checkout continuity while moving away from a legacy setup. It focuses on backups, account and subscription review, a test environment, and post-change verification. It intentionally leaves credentials, payment data, and any provider-specific secret values out of the process.

What the WooCommerce advisory means

WooCommerce removed the bundled PayPal Standard gateway from core years ago, but some older stores still retain it through legacy configuration or compatibility workarounds. The PayPal Payments plugin now provides the maintained integration.

  • Updating PayPal Payments to version 4.1.0 alone should not change a still-active PayPal Standard setup.
  • When the merchant connects a PayPal account to PayPal Payments, the plugin disables and hides PayPal Standard so checkout uses the modern integration.
  • WooCommerce says active and pending-cancel subscriptions that still rely on PayPal Standard are protected from an abrupt disablement, with an administrator notice to help identify them.

That last point is a guardrail, not a reason to skip planning. A recurring-payment store should treat subscriptions as a separate migration checkpoint and make sure the owner understands the billing impact before changing a live payment connection.

Start with a small payment inventory

Before installing or connecting anything, write down how the store currently accepts PayPal. Check the active WooCommerce payment methods, recent orders, subscription status, refund process, and the person who can approve changes to the business payment account. Note any custom checkout work, multilingual checkout, tax automation, fraud tools, or membership plugins that depend on payment completion.

Also identify the customer-facing promises that need to keep working: a normal purchase, order confirmation email, refund or cancellation handling, guest checkout if it is enabled, and a subscription renewal if the business uses recurring billing. This inventory keeps a gateway transition from becoming a vague "it should work" change.

Take a recoverable backup and use a test environment

  1. Verify a recent WordPress database and files backup, and record the restore owner before making payment changes.
  2. Make a staging copy that matches the production store's relevant plugins, theme, checkout customizations, and payment settings as closely as practical.
  3. Update WordPress, WooCommerce, and WooCommerce PayPal Payments through their supported channels. Record the versions before and after the update.
  4. Use the WooCommerce Upgrade Readiness Tool to review the current configuration before changing a live connection. WooCommerce describes the tool as read-only.
  5. Keep the production store's existing gateway configuration intact until the planned cutover and verification have succeeded.

For a deeper restore-point check, use our WordPress backup checklist. A payment change is not the time to discover that the backup is incomplete or that no one has tested recovery ownership.

Validate the maintained PayPal Payments path

Complete the PayPal Payments setup only through the approved WooCommerce and PayPal account flow. Keep credentials confined to the appropriate protected configuration surfaces. Do not put them in a ticket, chat transcript, screenshot, browser bookmark, or an exported WordPress settings file.

In a non-production test environment, use the provider's current testing guidance to confirm the user journey without relying on real shopper personal or payment details. Test the normal order lifecycle from a shopper's point of view, then check that the store records the expected order state, inventory behavior, and customer email. If the site offers refunds, cancellations, or subscriptions, test the administrative process that the business actually uses.

Keep the test focused on outcomes. You do not need to collect sensitive details or simulate unusual failure conditions to establish that the maintained gateway can create, confirm, and manage a legitimate order in the store's normal workflow.

Plan the production connection window

Choose a low-traffic period and tell the people who answer customer questions, refunds, and order issues what is changing. Confirm that the business owner can sign in to the payment account before the window opens. If a store uses WooCommerce Subscriptions or a membership plugin, include the person responsible for recurring billing in the approval step.

  • Review active and pending-cancel subscriptions before connecting the modern integration.
  • Review open carts, pending orders, and scheduled promotions so a checkout change does not collide with a sale.
  • Confirm that the store's cache and CDN team can clear checkout-related responses after the change.
  • Write down the checks that must pass before declaring the transition complete.
  • Set an owner and escalation route for any unexpected order, subscription, or customer-access issue.

Connect, clear caches, and verify normal commerce

When the approved merchant account is connected to WooCommerce PayPal Payments, WooCommerce says the legacy PayPal Standard option is disabled and hidden. Clear WordPress, host, and CDN caches afterward so the checkout reflects the current configuration consistently.

Then validate ordinary business activity with controlled, authorized test activity appropriate to the provider's current guidance. Confirm the customer view of checkout, the WooCommerce order state, the expected confirmation email, and visibility in the merchant's payment account. For subscription stores, confirm the existing subscription records remain intact and that the team knows how to handle the next expected renewal.

If a critical workflow does not behave as expected, pause the transition, preserve the facts needed for support, and follow the vendor's supported recovery guidance. Do not delete older configuration, reset payment settings broadly, or make repeated live changes while the cause is unknown.

Membership, subscriptions, and customer access

Payment completion may create more than an order. It can grant membership access, enroll a customer, or trigger a fulfillment process. After any gateway change, verify that paid access appears only when the business's normal payment-completion rules are met, and that cancellations or failed payments follow the store's policy. For WordPress sites using User Registration & Membership, pair this work with our membership security update checklist.

Keep these workflows separate from a public security advisory. The goal is reliable, auditable customer access and clean support handoffs, not a large collection of payment configuration notes scattered across teams.

Ongoing maintenance checklist

  • Review WooCommerce and payment-plugin updates in a staging copy before high-risk sales periods.
  • Monitor payment-provider notices and WooCommerce advisories for gateway changes.
  • Review a small sample of ordinary orders, refunds, and customer emails after each major checkout update.
  • Keep only the active payment integration enabled unless a documented business reason requires more than one.
  • Give staff a clear support path for checkout reports without requesting or retaining customer payment data.

For other practical maintenance work, visit the Fix I.T. Phill WordPress support hub.

Sources

Last reviewed July 13, 2026. This is a defensive setup and migration guide; it does not include credentials, customer payment data, or payment-provider test values.