Protecting payment workflows

Stay organized with collections Save and categorize content based on your preferences.

This page describes how to effectively protect payment workflows against attacks such as carding and Card-Not-Present fraud using reCAPTCHA Enterprise.

Fraudsters take advantage of any website that accepts payments to test stolen card details, brute force missing information, and make fraudulent purchases. These types of attacks are critical to protect against because they adversely affect both your users and your revenue.

Whether attacks are carried out manually by humans or with automation at scale, reCAPTCHA Enterprise helps identify and block them in your payment workflows. reCAPTCHA Enterprise is particularly effective at detecting fraud because of its visibility of attacks across millions of sites on the web - fraudsters rarely stop at one site, so you benefit from early warning signals based on the full network.

Before you begin

Choose the best method for setting up reCAPTCHA Enterprise in your environment and complete the setup.

Install reCAPTCHA for your payment workflow

To start detecting attacks, install a score-based site key on each page in your payment workflow. This should include the interface where a user selects their payment method, such as by entering card details or selecting a saved payment method. After the user has made their selection, call grecaptcha.enterprise.execute() to generate a token. To learn more about calling execute(), see Installing score-based site keys.

reCAPTCHA Enterprise automatically detects the payment event and builds a customized fraud model to improve the quality of risk analysis for these sessions.

The following example shows how to integrate a score-based site key on a credit card transaction event.

function submitForm() {
  grecaptcha.enterprise.ready(function() {
    grecaptcha.enterprise.execute(
      'reCAPTCHA_site_key', {action: 'purchase'}).then(function(token) {
       document.getElementById("token").value = token;
       document.getElementByID("paymentForm").submit();
    });
  });
}
<form id="paymentForm" action="?" method="POST">
  Total: $1.99
  Credit Card Number: <input name="cc-number" id="cc-number" autocomplete="cc-number"><br/>
  <input type="hidden" id="token" name="recaptcha_token"/>
  <button onclick="submitForm()">Purchase</button>
</form>
<script src="https://www.google.com/recaptcha/enterprise.js" async defer></script>

You can experiment with this code in JSFiddle by clicking the <> icon in the top-right corner of the code window.

<html>
  <head>
    <title>Protected Payment</title>
    <script src="https://www.google.com/recaptcha/enterprise.js" async defer></script>
    <script>
    function submitForm() {
      grecaptcha.enterprise.ready(function() {
        grecaptcha.enterprise.execute(
          'reCAPTCHA_site_key', {action: 'purchase'}).then(function(token) {
           document.getElementById("token").value = token;
           document.getElementByID("paymentForm").submit();
        });
      });
    }
    </script>
  </head>
  <body>
    <form id="paymentForm" action="?" method="POST">
      Total: $1.99
      Credit Card Number: <input name="cc-number" id="cc-number" autocomplete="cc-number"><br/>
      <input type="hidden" id="token" name="recaptcha_token"/>
      <button onclick="submitForm()">Purchase</button>
    </form>
  </body>
</html>

Send annotations

For best performance, reCAPTCHA Enterprise needs visibility into the status of events after scoring, such as the transaction being accepted or declined, a refund issued, or a chargeback filed. These signals can be extremely valuable to the risk analysis model, so the second step to integrating correctly is sending annotations for these events.

TRANSACTION_ACCEPTED and TRANSACTION_DECLINED annotations complete the initial step of the transaction lifecycle. These further improve card testing detection and label clusters of sessions with unusual success rates.

CHARGEBACK_FRAUD and REFUND_FRAUD annotations help target examples of previous successful attacks explicitly and label the behavior associated as potentially suspicious.

The following table specifies the full list of labels that you can use to annotate assessments:

Annotation reason Description
TRANSACTION_ACCEPTED Indicates that the payment transaction was accepted, and the user was charged.
TRANSACTION_DECLINED Indicates that the payment transaction was declined, for example due to invalid card details.
CHARGEBACK_FRAUD Represents chargebacks related to an alleged unauthorized transaction from the perspective of the cardholder (for example, the card number was stolen).
CHARGEBACK_DISPUTE Represents chargebacks related to the cardholder having provided their card but allegedly not being satisfied with the purchase (for example, misrepresentation, attempted cancellation).
CHARGEBACK Represents chargebacks either uncategorized or when specific details are unknown.
REFUND_FRAUD Indicates that the completed payment transaction was determined to be fraudulent by the seller, and was cancelled and refunded as a result.
REFUND Indicates that the completed payment transaction was refunded by the seller.
PAYMENT_HEURISTICS Indicates the transaction associated with the assessment is suspected of being fraudulent based on the payment method, billing details, shipping address or other transaction information.

The following example shows an example annotation payload. For more details, see the Annotating an assessment.

POST https://recaptchaenterprise.googleapis.com/v1/ASSESSMENT_ID:annotate
{
  "reasons": ["CHARGEBACK_FRAUD"]
}