No momento, esta página não está disponível em português
Point-of-sale icon

Risk management

Use our risk management solution to reduce the risk of fraud for MOTO and MKE transactions.

Risk webinars

You can also learn how to use Adyen's fraud and dispute management tools in an upcoming Risk webinar.
Sign up here.

You can use our risk management system, RevenueProtect, to minimize fraud by applying risk rules before processing a transaction. For most point-of-sale transactions, you do not need RevenueProtect because the risk for in-person payments is significantly lower than for ecommerce and most risk rules do not apply.

However, for riskier point-of-sale transactions like Mail Order/Telephone Order (MOTO) and Manual Key Entry (MKE), you can enable risk rules in your Customer Area. Based on your risk settings, every transaction gets a risk score ranging from 0 to 100. When the risk score reaches 100, the transaction is declined and the terminal shows Card blocked.

MOTO and MKE payments are considered insecure. There is no liability shift and you are fully liable for fraud chargebacks when accepting MOTO and MKE payments.

Step 1: Enable risk rules for point of sale

To turn on the Adyen risk management system for point of sale:

  1. Log into your Customer Area and select an account:
    • Company account: to enable risk checks by default for all point-of-sale transactions on all your merchant accounts.
    • Merchant account: to enable risk checks only for point-of-sale transactions on a specific merchant account.
  2. Go to Revenue & risk > Settings and stay on the Global settings tab.
  3. Under Enable risk, select On.
  4. Under Perform risk checks on point of sale (POS), select Enable.

    On a merchant account, you first need to select Override company setting.

  5. At the bottom, select Save configuration.

Step 2: Create a risk profile for point of sale

When you turn on the risk management system, the default risk profile of the company applies. Many rules in the default risk profile are not suitable for point-of-sale transactions. Therefore, if you only process point-of-sale transactions on your merchant account, we recommend you create a dedicated risk profile with risk rules configured specifically for point of sale.

  1. In your Customer Area, select your company account.
  2. Go to Revenue & risk > Risk profiles.
  3. In the top right, select Create new profile.
  4. Enter a name for your profile.
  5. For the template, under Based on profile, select the default company profile.
  6. Select Create, and then select Edit profile information.
  7. Under Merchant accounts, select the point-of-sale merchant accounts that you want to apply the risk rules to. Select Save changes.
  8. In the Risk rules tab, disable unnecessary risk rules. Select Save changes.
    At least, you must disable:
    • Multiple distinct IP address used
    • Shopper used shared IP address
    • Multiple distinct shopper references used
  9. Configure custom risk rules.
  10. Select Save changes.

Step 3: Disable unnecessary risk rules

Most risk rules are designed to minimize the risk of ecommerce transactions. To ensure the point-of-sale transactions are not declined unnecessarily:

  1. In your risk profile for point of sale, under Risk rules > Standard rules > ShopperDNA , disable the following risk rules:
    • Multiple distinct IP addresses used and Shopper used shared IP address: because terminals use the IP address of the store, the cards of multiple shoppers will use the same IP address. If you do not disable these rules, point-of-sale transactions will be declined.
    • Multiple distinct shopper references: the shopper reference is a unique identifier for a shopper that you send in the payment request. If you do not disable this rule, the transaction is declined if the same shopper has multiple shopper references (for example, due to using the card in different stores).
  2. Optionally, disable all other rules, except for Velocity and Consistency and rules that you want to customize.

Step 4: (Optional) Configure custom risk rules

For a MOTO transaction, you enter the card number and CVV. For an MKE transaction, shoppers enter the card number and the expiry date, and provide their signature. To enable the most important risk rules for these point-of-sale transactions:

  1. In your Customer Area, go to your risk profile for point of sale.
  2. Under Risk rules > Standard rules > Consistency , enable rules based on:
    • AVS checks (only if you send the street address and the ZIP/postal code of the shopper)
    • Card Verification Code (CVC2/CVV2/CID) does not match
  3. Under Risk rules > Standard rules > Velocity , enable rules based on the number of transactions a shopper attempts in a given time.
  4. To target specific behaviors, add Custom risk rules .
    Custom risk rules can make sense if you send additional data in your payment request, like shopperEmail.

Testing

When the transaction gets declined due to a risk rule, the PaymentResponse includes:

  • Result: Failure
  • error condition : Refusal
  • AdditionalResponse: provides more information about why the transaction was declined in the following fields:
    • refusalReason: 199 Card blocked
    • message BLOCK_CARD

Here's an example failure response for a declined payment:

{
"SaleToPOIResponse": {
      "MessageHeader": {...},
      "PaymentResponse": {
         "POIData": {...},
         "PaymentReceipt": {...},
         "PaymentResult": {...},
         "SaleData": {...},
         "Response": {
            "AdditionalResponse": "refusalReason=199%20Card%20blocked...&message=BLOCK_CARD...",
            "ErrorCondition": "Refusal",
            "Result": "Failure"
         }
      }
   }
}

To test how your integration handles refusals due to a risk rule, simulate a specific declined payment:

  1. Make a test payment for an amount with 125 as the last three digits of the RequestedAmount (for example, 101.25 or 21.25).
  2. In the response, check that the error condition is Refusal and the refusal reason is Card blocked.
  3. Make sure that your integration doesn't retry the transaction.

See also