Express payment buttons can behave very differently from the standard WooCommerce checkout flow, especially after a checkout redesign. In one support case, a cart-level PayPal button began skipping the normal checkout page entirely. That created two problems: required customer data such as a phone number was no longer collected, and payment authorization could happen before WooCommerce finished its own server-side validation.
Freshy compared the current site with a pre-redesign copy and confirmed that the original PayPal cart button had never been a true one-click checkout. After the buyer approved PayPal in the popup, they were redirected to the regular WooCommerce checkout page with PayPal data prefilled. The customer still had to enter any missing required fields and click Place Order. The redesign changed that behavior, which explains why the newer flow began bypassing required fields. The source task remains open, so the work documented here is diagnosis and solution planning rather than a completed production fix.
Issue background
A WooCommerce store offered a PayPal button directly on the cart page through its Braintree payment integration.
After a checkout redesign, the cart-level PayPal flow began failing in several ways:
- Required shipping phone information was missing.
- Checkout validation errors could appear on the cart page.
- An order could fail to complete in WooCommerce even though PayPal had already processed or authorized the payment.
The cart PayPal option was disabled on production while Freshy investigated.
Diagnosis
The first question was whether PayPal itself had stopped returning the customer data WooCommerce needed.
Testing showed that the Braintree-wrapped PayPal integration reliably returned the buyer’s email address, but not the phone number.
That raised an important historical question: if PayPal did not supply the phone number, why had older PayPal orders almost always contained one?
Freshy restored a copy of the site from before the checkout redesign and tested the cart PayPal button end to end.
That test established the actual previous workflow:
- The buyer clicked PayPal on the cart page.
- The PayPal popup handled account login and approval.
- The buyer was then redirected to the standard WooCommerce checkout page.
- Name, email, shipping address, and the PayPal payment choice were prefilled where available.
- The customer manually entered the phone number and any other required fields that PayPal had not supplied.
- The customer clicked Place Order to complete checkout.
In other words, the old cart button was only a different entry point into the regular checkout flow. It did not create the order directly from the cart.
The redesign changed that behavior. The cart PayPal button began trying to submit the order without the checkout-page step, which removed the place where the customer had historically entered the required phone number.
The investigation also uncovered a second risk unrelated to phone collection. With immediate payment capture, PayPal could move funds before WooCommerce finished server-side validation. A later failure involving shipping eligibility, inventory, taxes, coupons, or another validation rule could therefore create the worst possible state: payment processed, but no completed WooCommerce order.
Resolution steps
The source task documents several possible solution paths rather than a completed implementation.
- Reproduce the old checkout flow. Freshy verified that the pre-redesign cart PayPal button redirected customers to the standard checkout page rather than completing the order directly.
- Identify the missing data source. The phone number had historically come from the customer completing the WooCommerce checkout form, not from PayPal.
- Separate email from phone behavior. PayPal was returning the buyer’s email address, but the existing Braintree integration did not expose a way to force phone collection inside the PayPal popup.
- Evaluate restoring the previous flow. The most direct option was to make the cart PayPal button send buyers back through the regular checkout page so required fields could be completed before order submission.
- Evaluate a phone-follow-up workflow. Another proposed path was to allow cart PayPal orders without a phone number, automatically tag those orders with the site’s existing order-tagging system, notify customer service, and block downstream fulfillment until the phone number was collected.
- Recommend authorization before capture. Freshy recommended changing PayPal from immediate capture to authorization first, then capturing funds only after WooCommerce had successfully created and validated the order.
- Plan capture before downstream fulfillment. In the proposed safer workflow, payment would be captured programmatically immediately before the order was sent to the external fulfillment system.
- Protect failed orders from becoming charges. If validation failed or required customer information could not be obtained, the authorization could expire rather than requiring a refund for an order that never completed.
- Test a later PayPal account configuration change. The client later updated PayPal account settings that were expected to require and return a phone number for the cart flow.
- Document the remaining regression. Testing after that account change still produced a blank red checkout banner and failed to reach the normal order-confirmation screen, even though an order appeared to be created.
As of the latest task update, that final behavior still required investigation. The source thread does not document a completed production deployment of the restored checkout flow, order tagging, authorization-before-capture logic, or the newer PayPal phone-number configuration.
Final outcome
The investigation established why the PayPal cart flow broke after the WooCommerce checkout redesign.
The historical cart button relied on the standard checkout page to collect required data that PayPal did not return, especially the phone number. Once the redesign caused that button to bypass the checkout page, those fields disappeared from the flow.
Freshy also identified a broader payment-safety issue: immediate PayPal capture can expose the store to cases where the customer is charged before WooCommerce finishes order validation. An authorize-first, capture-later workflow was recommended to close that gap.
A later PayPal account change may provide the missing phone number directly, but the latest documented test still produced a checkout error banner and did not complete the customer flow normally. The task therefore remains an active troubleshooting item rather than a completed fix.
The broader lesson is that express-payment buttons must be tested again whenever the checkout architecture changes. A redesign can unintentionally remove validation steps, data collection, or order-finalization logic that an express button depended on even when the PayPal integration itself has not changed.
If a WooCommerce PayPal cart button is skipping required fields, charging before order creation, or behaving differently after a checkout redesign, contact Freshy. Our WordPress team can trace the complete payment flow and separate gateway behavior from WooCommerce validation and custom checkout logic.
