Hello @justinwyllie
Thanks for your message.
Just to clarify, this is not a “vulnerability” in the strict sense. What’s happening is that fraudsters are using the normal PayPal card processing flow (specifically hosted fields via Advanced Card Processing) to test stolen cards. This isn’t an exploit, but an abuse of the legitimate API, which is why it’s not trivial to patch without affecting real users. It has nothing to do with PayPal buttons at all.
The most effective immediate step you can take is to enforce 3D Secure (3DS) on every single card transaction. This blocks unauthorized card use by requiring an extra verification step that fraudsters usually can’t complete. Depending on your setup, you’ll find the option to enforce 3DS either:
– in the old UI under the Advanced Card Processing tab
– or in the new UI under the Settings tab
If you’d rather do it via code, here’s a one-liner that forces 3DS on all card payments:
add_filter( 'woocommerce_paypal_payments_three_d_secure_contingency', function ( string $contingency ) {
return 'SCA_ALWAYS';
} );
This doesn’t stop the fraud attempts themselves, but it will stop them from being successful. What you might still see is noise in the form of failed orders showing up in the backend. We’re already testing a solution for that.
If you’d like to be reached out to as soon as that patch is available or want to be involved in testing it, we suggest submitting a support request directly via the following link: Request Support
Please make sure to include the URL of this thread in your ticket for reference.
Kind Regards,
Krystian
Thanks @inpsydekrystian – the test ‘attacks’ (yes, not actually attacks as such) on our site were using the PayPal pop up Window – not the Advanced Card Fields (separate credit card fields rendered directly – via an iframe I imagine – into the /checkout page). I had a go at using an approach with a Google Captcha and AJAX to send the token to the back end. But, what I couldn’t do is find out where to intercept the button click which opens the Paypal Window. The button is in an iframe – which seems to be on the same domain as our site. But I couldn’t see get a handle on the button. But; even if I could, (I am not an expert in this field) I have read that because all this would use client-side JavaScript it could be, potentially, modifiable by the hacker in his emulated browser. So, reluctantly, I have gone for the option of hiding the failed orders using the pre-get-posts hook. I will send a request to be notified about the patch you mention.
Thanks
Justin
Thanks for the list of hooks you sent.
Actions and Filters · woocommerce/woocommerce-paypal-payments Wiki · GitHub
I did think about using one of these to: e.g. not render the button until the user has passed a Captcha. Or maybe disable it:
add_filter(‘woocommerce_paypal_payments_buttons_disabled’, function (?bool $is_disabled, string $context): bool { return true; }, 10, 2);
But. a) this seems rather elaborate and b) I am not convinced it would not be circumventable. (? – I don’t know that much about how these things work).
Hello @justinwyllie
Thanks for the detailed explanation.
First of all, I want to clarify that there is no JavaScript modification happening here. No hacker is altering frontend scripts. The failed orders are the result of direct calls to the standard order creation API. This API is being triggered by bots using stolen card details to mimic the behavior of real orders. There’s no vulnerable or modifiable part in this logic on the client side; the actual processing logic is handled far beyond anything exposed via JavaScript or the browser.
From my experience, the Standard Card gateway is not affected. Failed orders may still appear when automated traffic interacts with the payment flow. These requests typically hit the endpoint used to create orders, but because ACDC (hosted fields) are not enabled, the logic fails early and returns an error. That’s where you see PAYEE_NOT_ENABLED_FOR_CARD_PROCESSING or similar.
Falling back to the regular “woocommerce_paypal_payments_buttons_disabled” might not block fraud attempts. It simply switches the flow from Smart Buttons (PayPal JS SDK) to the standard WC submission process. While this changes how the payment is initiated, it doesn’t inherently solve the issue if the endpoint used to create orders is still being targeted directly.
The only consequence of current behavior, in its current form, is failed orders. These do not go into processing; they fail early with the PAYEE_NOT_ENABLED_FOR_CARD_PROCESSING error and never result in a completed transaction.
Kind Regards,
Krystian
Ok. You think he is hitting the endpoints that the plugin exposes on our site?
In which case – probably the best option would be to use IP banned list filtering perhaps?
I take the point that this is failing early and is not an attack on our site as such. I just don’t like providing services to scammers!
Hello @justinwyllie
Technically, without hosted fields enabled, this is just a blind shot from their side; you’re not actually providing any service to them. I understand it still feels wrong, but there’s no data exposure or payment risk involved.
These bots typically use rotating residential proxies, so relying on IP-based blocking is unfortunately not a reliable or long-term solution. Even if you block a few IPs, they’ll likely come back under new ones shortly after.
I responded to your query on our support board.
Kind Regards,
Krystian
