{"id":19003334,"date":"2026-08-26T08:47:23","date_gmt":"2026-08-26T08:47:23","guid":{"rendered":"https:\/\/wordpress.org\/support\/topic\/missing-validate-required-css-class-breaks-stripe-payment-method-creation\/"},"modified":"2026-08-26T08:47:23","modified_gmt":"2026-08-26T08:47:23","slug":"missing-validate-required-css-class-breaks-stripe-payment-method-creation","status":"publish","type":"topic","link":"https:\/\/wordpress.org\/support\/topic\/missing-validate-required-css-class-breaks-stripe-payment-method-creation\/","title":{"rendered":"Missing validate-required CSS class breaks Stripe payment method creation"},"content":{"rendered":"\n

Custom checkout fields of type radio<\/code>, select<\/code>, multicheckbox<\/code>, multiselect<\/code> and file<\/code> rendered by this plugin are missing the validate-required<\/code> CSS class on their wrapper element when marked as required, even though the field is correctly flagged required => true<\/code> in the PHP field definition.<\/p>\n\n\n\n

The cause is in lib\/view\/frontend\/class-fields-filter.php<\/code>, method custom_field()<\/code>:<\/p>\n\n\n\n

if ( $args['required'] ) {\n    \/\/ $args['class'][] = 'validate-required';\n    $required = '&nbsp;<abbr class=\"required\" title=\"' . esc_attr__( 'required', 'woocommerce-checkout-manager' ) . '\">*<\/abbr>';\n}\n<\/code><\/pre>\n\n\n\n
The line that adds the validate-required<\/code> class to $args['class']<\/code> is commented out. As a result, the field visually shows a required asterisk, but the rendered <p class=\"form-row ...\"><\/code> wrapper never receives validate-required<\/code>.<\/p>\n\n\n\n
This class is the standard convention WooCommerce core (and other plugins) use client-side to detect empty required fields during checkout validation.<\/p>\n\n\n\n
Impact:<\/strong><\/p>\n\n\n\n
This went unnoticed for a long time because it only affected the visual “empty required field” highlighting for these field types. However, WooCommerce Gateway Stripe 10.9.0 (released 2026-08-17) added stricter client-side validation of required billing fields before creating\/confirming the Stripe payment intent (see their changelog: “Validate customer details against required billing fields from checkout before sending to Stripe”, “Prevent unnecessary Stripe payment method creation when shortcode checkout has empty required fields”).<\/p>\n\n\n\n
Because of the missing validate-required<\/code> class, this new Stripe logic gets confused for sites that have at least one required radio<\/code>\/select<\/code>\/multicheckbox<\/code>\/multiselect<\/code>\/file<\/code> field added via this plugin. The practical symptom: checkout fails on every single order paid by Stripe (card)<\/strong>, with the WooCommerce Stripe log showing:<\/p>\n\n\n\n
The information for creating and confirming the intent is missing the following data: payment_method.\n<\/code><\/pre>\n\n\n\n
i.e. the checkout form submits to the server, but the client-side Stripe payment method (pm_xxx<\/code>) was never attached before submission.<\/p>\n\n\n\n
Steps to reproduce:<\/strong><\/p>\n\n\n\n
    \n
  1. Add a required custom billing field of type “Multiple checkbox” (or radio\/select\/multiselect\/file) via WooCommerce Checkout Manager.<\/li>\n\n\n\n
  2. Enable WooCommerce Gateway Stripe 10.9.0+ with the credit card (UPE) payment method.<\/li>\n\n\n\n
  3. Go through checkout and pay by card.<\/li>\n\n\n\n
  4. Payment fails; WooCommerce > Status > Logs > woocommerce-gateway-stripe<\/code> shows the “missing payment_method” error above.<\/li>\n\n\n\n
  5. Disabling WooCommerce Checkout Manager, or removing the “required” flag from the affected field, makes checkout succeed again.<\/li>\n<\/ol>\n\n\n\n
    Suggested fix:<\/strong><\/p>\n\n\n\n
    Uncomment the line in class-fields-filter.php<\/code>:<\/p>\n\n\n\n
    if ( $args['required'] ) {\n    $args['class'][] = 'validate-required';\n    $required = '&nbsp;<abbr class=\"required\" title=\"' . esc_attr__( 'required', 'woocommerce-checkout-manager' ) . '\">*<\/abbr>';\n}\n<\/code><\/pre>\n\n\n\n
    so the rendered markup matches what the field definition already declares.<\/p>\n","protected":false},"template":"","class_list":["post-19003334","topic","type-topic","status-publish","hentry"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/19003334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic"}],"about":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/types\/topic"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/19003334\/revisions"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/media?parent=19003334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}