Ability to hinder "card testing"

[rob-c-baker]

For a description of "card testing": https://stripe.com/docs/card-testing.

Technically, rate limiting can be implemented at various stages of the Commerce workflow using any suitable rate limiting code within the events that Commerce raises.

However, this is not completely handled by the above approach, as with the Stripe & PayPal gateways (and probably lots of others as it's considered a good practise) the POST request holding the actual card details goes directly to a server at the gateway. There is no opportunity to inject a rate limiter as on the server-side.

This leaves preventing (or at least reducing) card testing down to front-end JavaScript, either via a CAPTCHA (reCAPTCHA maybe) which introduces friction to the checkout and another round trip to the app server, or via traditional rate limiting but implemented in JavaScript, which due to it being client-side is not as robust as would normally be desired.

I'm not sure what to suggest for this as it seems there are no perfect solutions, but the issue remains none-the-less.