Pay-for-Order Page Missing Billing Address Fields – Stripe Radar Compatibility

Thanks for the quick response. I will investigate more, but this still poses a problem. This assumes that the admin user that is creating the order knows the correct billing address associated with the credit card the customer is going to use. Should there not be a way for the customer to update the billing address if needed in order to use a different credit card?

Did you test when you add a Stripe Radar rule of

Block if :address_line1_check: in ('fail', 'not_provided')

Hi @saivutukuru,

Thanks for confirming the issue exists. Unfortunately, what you’ve suggested is exactly what we already attempted during our 3+ hours of debugging, and it doesn’t work due to how Stripe Elements creates payment methods.

What We Already Tried:

1. Added billing address fields to pay-for-order template  – Done this was easy

• Used woocommerce_pay_order_before_payment hook to display billing fields
• Fields successfully render and capture customer input
• Order billing address successfully updates via woocommerce_before_pay_action hook

2. Attempted to initialize Stripe Payment Element with billing details  – Failed

This is where we’re stuck. The problem is:

• Stripe Elements creates the payment method on the frontend (JavaScript) before any server-side code runs
• By the time our PHP code can access the billing details, the payment method has already been created without billing details
• The Radar rule evaluates immediately when the payment method is created, so it’s already blocked before we can update it

3. Tested with Radar rule active  Confirmed

The specific Radar rule blocking payments is:

Block if :address_line1_check: in ('fail', 'not_provided')

The Stripe API shows payment methods being created with address_line1_check: 'not_provided', which triggers the block.

The Technical Issue:

We need to pass billing details to Stripe Elements JavaScript when it creates the payment method, but we cannot find:

1. Where the Stripe Payment Element is initialized in the plugin’s JavaScript for the pay-for-order page
2. What JavaScript hooks/filters exist to pass billing details from the order to Stripe Elements
3. How to configure the Elements instance to collect billing details before calling stripe.createPaymentMethod()

Server-side filters we tested (all failed):

• wc_stripe_generate_payment_request – billing_details not valid on payment intent
• wc_stripe_generate_create_intent_request – fires during confirmation (too late), Stripe rejects customer parameter on confirm endpoint
• wc_stripe_payment_intent_data – never fires during pay-for-order flow

Can you provide specific guidance on:

1. Which JavaScript file initializes Stripe Elements on the pay-for-order page?
2. What JavaScript hooks/filters can we use to pass the order’s billing details to stripe.createPaymentMethod()?
3. Is there a proper way to extend the plugin’s JavaScript to include billing details, or does this require modifying core plugin files?

The billing fields are successfully displayed and captured – we just need to know how to pass that data to Stripe Elements before it creates the payment method on the frontend.

Thanks for your help!

The critical step that you are missing is 3.) Tested with Radar rule active you need to add the Radar rule and then test

Steps to Create a Custom Radar Rule:

1. Access Rules: Log in to Stripe and navigate to Radar > Rules.
2. Add Rule: Click “+ Add rule” to create a new rule for payments.
3. Define Logic: Input the rule syntax.
   • Block missing address _1: :address_line1_check: in ('fail', 'not_provided')
4. Action: Select the action: Block, Review, or Allow.
5. Save: Click Save to activate the rule. 

Once you have that rule in place, then if you create an order and then visit the appropriate /checkout/order-pay/{order_id}/?pay_for_order=true&key={order_key}) page, all credit cards will fail because it is not passing the address.

I still do not think you are understanding here. Let me reframe it and approach it from a different angle for you.

The plugin is not passing billing details to Stripe when creating payment methods on the pay-for-order page, which creates a security vulnerability.

Security Risk:

By omitting billing details from the payment method creation, the plugin enables card testing attacks. Fraudsters use stolen card numbers to make small test purchases to verify if cards are active. Without billing address verification:

1. No AVS (Address Verification System) checks – Stripe cannot validate if the card’s billing address matches
2. Radar rules that depend on address verification are bypassed – Rules like Block if :address_line1_check: in ('fail', 'not_provided') cannot function
3. Card testing is easier – Attackers can rapidly test stolen cards without needing valid billing addresses
4. Higher fraud rates – Merchants using manual orders are exposed to fraudulent transactions

This is particularly problematic for manually created orders where admins may enter placeholder billing addresses, then send payment links to customers.

Evidence:

When payment methods are created on pay-for-order pages, Stripe shows address_line1_check: 'not_provided'. This proves that billing details are NOT being sent to Stripe when stripe.confirmPayment() or stripe.createPaymentMethod() is called.

The Root Issue:

From what I can see, since the JavaScript is minified, your JavaScript code is not using the customerBillingData (that you pass from PHP to JavaScript) when creating the Payment Element or confirming the payment.

According to Stripe’s Payment Element documentation, billing details should be passed like this:

const paymentElement = elements.create('payment', {
  defaultValues: {
    billingDetails: {
      name: 'John Doe',
      email: 'john@example.com',
      address: {
        line1: '123 Main St',
        city: 'New York',
        state: 'NY',
        postal_code: '10001',
        country: 'US'
      }
    }
  }
});

Your plugin is clearly NOT doing this, otherwise Stripe would receive the billing address and wouldn’t return address_line1_check: 'not_provided'.

What Needs to be Fixed:

1. JavaScript Bug (Security Issue):

Your JavaScript needs to be updated to:

• Use wc_stripe_upe_params.customerBillingData when creating the Payment Element with defaultValues.billingDetails
• OR pass billing details in the confirmPayment() call

This is a security vulnerability, not just a feature request. Without billing details, merchants cannot use Stripe’s fraud prevention tools effectively on pay-for-order pages.

2. Wrong Data Source:

The billing data being passed is from the logged-in user’s saved address (WC()->customer) instead of the order’s billing address that the admin entered. For pay-for-order pages, this needs to use the order’s billing data:

In /includes/payment-methods/class-wc-stripe-upe-payment-gateway.php at lines 554-572:

// Current code uses:
$customer = WC()->customer;

// Should be (for pay-for-order):
if ( $is_pay_for_order ) {
    $order_id = absint( get_query_var( 'order-pay' ) );
    $order = wc_get_order( $order_id );
    
    if ( $order ) {
        $stripe_params['customerBillingData'] = [
            'name'    => trim( $order->get_billing_first_name() . ' ' . $order->get_billing_last_name() ),
            'email'   => $order->get_billing_email(),
            'phone'   => $order->get_billing_phone(),
            'address' => [
                'country'     => $order->get_billing_country(),
                'line1'       => $order->get_billing_address_1(),
                'line2'       => $order->get_billing_address_2(),
                'city'        => $order->get_billing_city(),
                'state'       => $order->get_billing_state(),
                'postal_code' => $order->get_billing_postcode(),
            ],
        ];
    }
}

3. Add Filter for Extensibility (WordPress Best Practice):

Even after fixing #1 and #2, you should add a filter to allow developers to customize the billing data source. This follows WordPress plugin best practices and allows merchants to implement additional security measures.

Add this filter after line 571:

// Allow developers to customize billing data
$stripe_params['customerBillingData'] = apply_filters( 
    'wc_stripe_upe_customer_billing_data', 
    $stripe_params['customerBillingData'], 
    $customer, 
    $is_pay_for_order,
    $order ?? null
);

This would allow developers to:

• Add custom billing fields to the pay-for-order page for customers to verify/update
• Capture updated billing information from the customer before payment
• Override the billing data passed to Stripe Elements
• Implement additional fraud prevention measures

Without this filter, developers who want to let customers update their billing address on the pay-for-order page (to prevent the admin-entered address from being used with a different card) would have to fork your entire plugin.

Impact:

This affects:

1. Any merchant using Stripe Radar rules that validate billing addresses (standard fraud prevention)
2. Any merchant creating manual orders where the customer’s card billing address differs from the order billing address
3. Security-conscious merchants trying to prevent card testing attacks
4. Merchants in high-fraud industries who rely on AVS checks

Summary:

1. Fix the JavaScript to actually send billing details to Stripe (security fix)
2. Use order billing data instead of customer saved data for pay-for-order (bug fix)
3. Add a PHP filter to allow developers to customize the billing data source (WordPress best practice)

Please prioritize this as a security issue. The current implementation weakens fraud prevention on pay-for-order pages.