Payflow Fraud Protection Services User's Guide

This document describes Fraud Protection Services and explains how you can use the Payflow SDK to perform transactions that will be screened by Fraud Protection Services filters.

Table of Contents

• Revisions
• Overview
  • The growing problem of fraud
  • Reducing the cost of fraud
• How fraud protection services protect you
  • The threats
  • Fraud filters provide protection against threats
  • Special considerations
• Configuring the fraud protection services filters
  • Phase 1: Run test transactions against filter settings on test transaction security servers
  • Phase 2: Run live transactions on live transaction servers in observe mode
  • Phase 3: Run all transactions through the live transaction security servers using active mode
• Assessing transactions that triggered filters
  • Reviewing suspicious transactions
  • Acting on transactions that triggered filters
  • Rejecting transactions
  • Fine-tuning filter settings using the filter scorecard
• Screening transactions using the Payflow SDK
  • Downloading the Payflow SDK (Including APIs and API documentation)
  • Transaction data required by filters
  • Transaction parameters unique to the filters
  • Existing Payflow parameters used by the filters
  • Response strings for transactions that trigger filters
  • RESULT values specific to fraud protection services
  • Changing the verbosity setting
  • Accepting or rejecting transactions that trigger filters
  • Logging transaction information
• Responses to credit card transaction requests
  • An example response string
  • Contents of a response to a credit card transaction request
  • PNREF value
  • RESULT codes and RESPMSG values
  • RESULT values for communications errors
• Fraud filter reference
  • Filters included with the fraud protection services
  • About the fraud risk lists
  • Unusual order filters
  • High-risk payment filters
  • High-risk customer filters
  • International order filters
  • Accept filters
  • Custom filters
• Testing the transaction security filters
  • Testing the good and bad lists
  • Testing the AVS failure filter
  • Testing the BIN risk list match filter
  • Testing the Country risk list match filter
  • Testing the Email service provider risk list match filter
  • Testing the Geo-location failure filter
  • Testing the International AVS filter
  • Testing the International IP address filter
  • Testing the International shipping/billing address filter
  • Testing the IP address match filter
  • Testing the shipping/billing mismatch filter
  • Testing the total item ceiling filter
  • Testing the total purchase price ceiling filter
  • Testing the total purchase price floor filter
  • Testing the USPS address validation failure filter
  • Testing the ZIP risk list match filter
• Deactivating fraud protection services
• Customer Service

Revisions

• May 7, 2020
  • Clarified VERBOSITY and added recommendation to set it to HIGH.
  • Updated the description regarding RESULT=127 to better define that transactions where not processed by the Fraud Protection Services, but could have been processed by your processor and that they need to be re-run through the fraud service to release them.
  • Clarified that a Sale type transaction should not be used with certain processors, see Special considerations.
  • Changed COUNTRYCODE to SHIPTOCOUNTRY and updated reference that should be a 3-digit numeric ISO code.

Overview

This section discusses how fraud can affect you, the merchant, and provides an overview of Fraud Protection Services.

The growing problem of fraud

Online fraud is a serious and growing problem. While liability for fraudulent card-present or in-store transactions lies with the credit card issuer, liability for card-not-present transactions, including transactions conducted online, falls to the merchant. As you probably know, this means that a merchant who accepts a fraudulent online transaction (even if the transaction is approved by the issuer) does not receive payment for the transaction and additionally must often pay penalty fees and higher transaction rates.

Reducing the cost of fraud

Fraud Protection Services, in conjunction with your Payflow service’s standard security tools, can help you to significantly reduce these costs and the resulting damage to your business.

Merchants must meet the following eligibility requirements to enroll in and use the Fraud Protection Services products:

• Merchant must have a current, paid-in-full Payflow service account.
• Merchant Payflow service account must be activated (in Live mode).
• Merchant must be integrated using Payflow API (USER, VENDOR, PARTNER, PWD) or must use Virtual Terminal within the PayPal Manager.
• Merchant must have its business operations physically based in the United States of America.

How fraud protection services protect you

This section describes the security tools that make up the Fraud Protection Services.

The threats

There are two major types of fraud—hacking and credit card fraud.

Hacking

Fraudsters hack when they illegally access your customer database to steal card information or to take over your Payflow account to run unauthorized transactions (purchases and credits).

Fraud Protection software filters minimize the risk of hacking by enabling you to place powerful constraints on access to and use of your PayPal Manager and Payflow accounts.

Credit card fraud

Fraudsters can use stolen or false credit card information to perform purchases at your website, masking their identity to make recovery of your goods or services impossible. To protect you against credit card fraud, the Fraud Protection filters identify potentially fraudulent activity and let you decide whether to accept or reject the suspicious transactions.

Fraud filters provide protection against threats

Configurable filters screen each transaction for evidence of potentially fraudulent activity. When a filter identifies a suspicious transaction, the transaction is marked for review.

Fraud Protection Services offers two levels of filters: Basic and Advanced. The filters are described in Fraud filter reference.

Example filter

The Total Purchase Price Ceiling filter compares the total amount of the transaction to a maximum purchase amount (the ceiling) that you specify. Any transaction amount exceeding the specified ceiling triggers the filter.

Configuring the filters

Through PayPal Manager, you configure each filter by specifying the action to take whenever the filter identifies a suspicious transaction (either set the transaction aside for review or reject it). See PayPal Manager online help for detailed filter configuration procedures.

Typically, you specify setting the transaction aside for review. For transactions that you deem extremely risky (for example, a known bad email address), you might specify rejecting the transaction outright. You can turn off any filter so that it does not screen transactions.

For some filters, you also set the value that triggers the filter—for example the dollar amount of the ceiling price in the Total Purchase Price Ceiling filter.

Reviewing suspicious transactions

As part of the task of minimizing the risk of fraud, you review each transaction that triggered a filter through PayPal Manager to determine whether to accept or reject the transaction. See PayPal Manager online help for details.

Special considerations

Merchants with an instant fulfillment model

For businesses with instant fulfillment business models (for example, software or digital goods businesses), the Review option does not apply to your business—you do not have a period of delay to review transactions before fulfillment to customers. Only the Reject and Accept options are applicable to your business model.

In the event of server outage, Fraud Protection Services is designed to queue transactions for online processing. This feature also complicates an instant fulfillment business model.

Unsupported transaction types

Fraud Protection Services do not screen the following transaction types:

• Reference transactions
• Recurring billing transactions
• Transactions in which the merchant passes in RECURRING=Y
• Voice authorizations
• PayPal Express Checkout transactions

Recurring billing transactions

To avoid charging you to filter recurring transactions that you know are reliable, Fraud Protection Services filters do not screen recurring transactions.

To screen a prospective recurring billing customer, submit the transaction data using PayPal Manager’s Virtual Terminal. The filters screen the transaction in the normal manner. If the transaction triggers a filter, then you can follow the normal process to review the filter results.

Configuring the fraud protection services filters

This section describes how to configure the Fraud Filters for your Payflow account, covering a phased approach to implementing transactional security. Though you are not required to use this approach, it enables you to fine-tune your filters before you deploying them in a live environment.

You first set and fine-tune filter settings in a test environment. Then you move to a live transaction environment to fine-tune operation in an Observe-only mode. Finally, when you are fully satisfied with your settings, you move to live Active mode to begin screening all live transactions for fraud.

Filter operation is fully described in Fraud filter reference.

• Phase 1: Run test transactions in Test mode using test transaction servers. In the test phase, configure fraud filter settings for test servers that do not affect the normal flow of transactions, then run test transactions against the filters and review the results offline to determine whether the integration was successful. Once you are happy with the filter settings, you move to the next phase and the optimized settings from the test phase are transferred to the live servers.
• Phase 2: Run live transactions on live transaction security servers using Observe mode. When deploying to Observe mode, the settings established in the test phase are automatically transferred to the live servers. In Observe mode, the filters examine each live transaction and mark the transaction with each triggered filter’s action. You can then review the actions that would have been taken on the live transactions had the filters been active. Regardless of the filter actions, all transactions are submitted for processing in the normal fashion.
• Phase 3: Run live transactions on live transaction security servers using Active mode. Once you have set all filters to the optimum settings, deploy the filters to Active mode. In Active mode, filters on the live servers examine each live transaction and take the specified action when triggered.

Remember that you can test a new filter setting using the test servers at any time (even if your account is in Active mode), then, if desired, adjust the live filter settings.

Phase 1: Run test transactions against filter settings on test transaction security servers

In this phase of implementation, you configure filter settings for test servers that do not affect the normal flow of live transactions, then run test transactions against the filters and review the results offline to determine whether the integration was successful. Continue modifying and testing filters as required.

There is no per-transaction fee when you use the test servers.

1. In the Service Summary section of the PayPal Manager home page, click the Basic or Advanced Fraud Protection link. Click Service Settings > Fraud Protection >Test Setup.

2. Click Edit Standard Filters. The Edit Standard Filters page appears.

3. For each filter, do the following:

   Note: If you have not enrolled for the Buyer Authentication Service, then the Buyer Authentication Failure filter is grayed-out and you cannot configure it. Items that you enter in the Test Good, Bad, or Product Watch lists are not carried over to your configuration for the live servers, so do not spend time entering a complete list for the test configuration. For details on the Good, Bad, or Product Watch, see Fraud filter reference.

   • Click the filter check box to enable it and click-to-clear the check box to disable it.
   • Select the filter action that should take place when the filter is triggered. For some filters, you set a trigger value. For example, the Total Purchase Price Ceiling filter trigger value is the transaction amount that causes the filter to set a transaction aside. To make decisions about how the filters work, see Fraud filter reference.

4. After editing the settings, click Deploy.

   Important: If you do not deploy the filters, then your settings are not saved.

5. All filters are now configured, and you can begin testing the settings by running test transactions. Follow the guidelines outlined in Testing the transaction security filters. To run test transactions, you can use PayPal Manager’s Virtual Terminal. See PayPal Manager for online help instructions.

6. Review the filter results by following the instructions in Assessing transactions that triggered filters.

7. Based on your results, you may want to change filter settings. Return to the Edit Filters page, change settings, and redeploy them. After you are happy with your filter settings, move to Phase 2.

Phase 2: Run live transactions on live transaction servers in observe mode

In this phase, you configure filters on live servers to the settings that you had fine-tuned on the test servers. In Observe mode, filters examine each live transaction and mark the transaction with the filter results. The important difference between Observe and Active mode is that, regardless of the filter actions, all Observe mode transactions are submitted for processing in the normal fashion. Observe mode enables you to view filter actions offline to assess their impact (given current settings) on your actual transaction stream.

1. Click Service Settings > Fraud Protection >Test Setup. Click Move Test Filter Settings to Live. The Move Test Filter Setting to Live page appears. Remember that in this phase, you are configuring the live servers.

2. Click Move Test Filter Settings to Live. On the page that appears, click Move Test Filter Settings to Live again.

3. The Move Test Filter Settings to Live page prompts whether to deploy the filters in Observe mode or in Active mode. Click Deploy to Observe Mode. After you deploy the filters, all transactions are sent to the live servers for screening by the live filters. In Observe mode, each transaction is marked with the filter action that would have occurred (Review, Reject, or Accept) had you set the filters to Active mode. This enables you to monitor (without disturbing the flow of transactions) how actual customer transactions would have been affected by active filters.

   Important: Deployed filter setting changes are updated hourly (roughly on the hour), so you might have to wait up to an hour for your changes to take effect. This waiting period only occurs when you move from one mode to the next.
   

4. Test the filters. Follow the procedures outlined in Testing the transaction security filters.

5. Review the filter results as per Assessing transactions that triggered filters. The Filter Scorecard will be particularly helpful in isolating filter performance that you should monitor closely and to ensure that a filter setting is not set so strictly so as to disrupt normal business.

6. After you are happy with your filter settings, move to Phase 3.

Phase 3: Run all transactions through the live transaction security servers using active mode

After you have configured all filters to optimum settings, convert to Active mode. Filters on the live servers examine each live transaction and take the specified action.

7. Click Move Test Filter Settings to Live. After that page appears, click Move Test Filter Settings to Live again.
8. On the Move Test Filter Settings to Live page, click Deploy to Active Mode. At the top of the next hour, all live transactions will be inspected by the filters.
9. Use the instructions in Assessing transactions that triggered filters, to detect and fight fraud.

Assessing transactions that triggered filters

As part of the task of minimizing fraud risk, review each transaction that triggered a filter and decide, based on the transaction’s risk profile, whether to accept or reject the transaction. This section describes how to review transactions that triggered filters, and provides guidance on deciding acceptable risk.

Reviewing suspicious transactions

Transactions that trigger filters might or might not represent attempted fraud. It is your responsibility to analyze the transaction data and then to decide whether to accept or reject the transaction.

Accepting a transaction requires no further action. To reject a transaction, a separate void of the transaction is required.

The first step in reviewing filtered transactions is to list the transactions.

1. Click Reports > Fraud Protection > Fraud Transactions. The Fraud Transactions Report page appears.
2. Specify the date range of the transactions to review.
3. Specify a Transaction Type, as shown in the following table.

4. Specify the Transaction Mode, and click Run Report. The Fraud Transactions Report page displays all transactions that meet your search criteria.

The following information appears in the Transactions Report:

The following transaction status values can appear in the report:

Click the Transaction ID of the transaction of interest. The Fraud Details page appears, as discussed in the next section.

Acting on transactions that triggered filters

The Fraud Details page displays the data submitted for a single transaction. The data is organized to help you to assess the risk types and to take action (accept, reject, or continue in the review state).

Reasons for transactions appearing here can include:

• Triggered filters.
• The transaction was not screened by any of the filters in the Skipped Filters section because the data required by these filters did not appear in the transaction data.
• The transaction data was badly formatted.
• In special cases, all filters appear here.

See Re-running transactions that were not screened.

For each transaction on the Fraud Details page, you can take the following actions:

• Specify the action to take on the transaction:

  • Review: Take no action. You can return to this page at any time or reject or accept the transaction. The transaction remains unsettleable.
  • Reject: Do not submit the transaction for processing. See Rejecting transactions.
  • Accept: Submit the transaction for normal processing.

• Enter notes regarding the disposition of the transaction or the reasons for taking a particular action. Do not use the & < > or = characters.

• Click Submit to save the notes, apply the action, and move to the next transaction.

Rejecting transactions

If you decide to reject a transaction, you should notify the customer that you could not fulfill the order. Do not be explicit in describing the difficulty with the transaction because this provides clues for performing successful fraudulent transactions in the future. Rejected transactions are never settled.

Fine-tuning filter settings using the filter scorecard

The Filter Scorecard displays the number of times that each filter was triggered and the percentage of all transactions that triggered each filter during a specified time period. This information is especially helpful in fine-tuning your risk assessment workflow. For example, if you find that you are reviewing too many transactions, then use the Filter Scorecard to determine which filters are most active. You can reduce your review burden by relaxing the settings on those filters (for example, by setting a higher amount for the Purchase Price Ceiling filter).

1. Click Reports > Filter Scorecard. The Filter Scorecard Report page appears.
2. Specify the date range of the transactions to review.
3. In the Transaction Mode field, specify transactions screened by the live or the test servers.
4. Click Run Report. The Filter Scorecard Report page displays the number of times that each filter was triggered and the percentage of all transactions that triggered each filter during the time span that you specified.

Ensuring meaningful data on the filter scorecard

The Scorecard shows the total number of triggered transactions for the time period that you specify, so if you had changed a filter setting during that period, the Scorecard result for the filter might reflect transactions that triggered the filter at several different settings.

Say, for example, you changed the total purchase price ceiling on August 1 and again on August 7. You then run a filter scorecard for July 1 to August 31. Between July 1 to August 31, three different price ceiling settings caused the filter to trigger, yet the scorecard would not indicate this.

To ensure meaningful results in the filter scorecard, specify a time period during which the filter settings did not change.

Re-running transactions that were not screened

Perform the following steps if you wish to re-run a transaction that was not screened by filters (transactions with result code 127):

1. Navigate to Reports > Fraud Protection > Fraud Transaction Report. The Fraud Transaction Report page appears.
2. Select the appropriate time period for the search, and select the Not Screened by Filters option for Transaction Type.
3. Click Run View Report. The Fraud Transaction Report Results page appears. It contains all the transactions that were not screened by filters.
4. Click on the Transaction ID of the transaction you would like to re-run. The Confirm Rerun page appears.
5. Click Yes to re-run that transaction. The Success page appears if your transaction was successful.

Screening transactions using the Payflow SDK

This section describes using the Payflow SDK to perform transactions that will be screened by the Fraud Protection Services filters. For information on using the SDK, and on transaction syntax, see the Payflow Gateway Developer’s Guide and Reference.

Downloading the Payflow SDK (Including APIs and API documentation)

The Payflow SDK is available either as a standalone client that can you can integrate with your Web store using CGI scripts or as a set of APIs for direct integration with your application.

The Payflow Gateway Developer’s Guide and Reference provides instructions for downloading the SDK appropriate to your platform.

Full API documentation is included with each SDK.

Transaction data required by filters

This table lists each filter and the Payflow parameter values that are required by the filters.

Transaction parameters unique to the filters

The Payflow server accepts the parameters listed in this section.

Standard Payflow parameters, parameters that you can pass for reporting purposes, and return values are described in Payflow Gateway Developer’s Guide and Reference

Existing Payflow parameters used by the filters

The following existing Payflow parameters (described in the Payflow Gateway Developer’s Guide and Reference) are also used by the filters (if they are provided in the transaction request or response):

User Authentication

• PARTNER
• VENDOR
• USER
• PWD

Transaction Information

• TRXTYPE
• TENDER
• ACCT
• EXPDATE
• AMT

Billing Information

• BILLTOFIRSTNAME
• BILLTOMIDDLENAME
• BILLTOLASTNAME
• BILLTOSTREET
• BILLTOSTREET2
• BILLTOCITY
• BILLTOSTATE
• BILLTOZIP
• BILLTOCOUNTRY
• BILLTOPHONENUM
• BILLTOPHONE2
• BILLTOEMAIL

Shipping Information

• SHIPTOFIRSTNAME
• SHIPTOLASTNAME
• SHIPTOMIDDLENAME
• SHIPTOSTREET
• SHIPTOSTREET2
• SHIPTOCITY
• SHIPTOSTATE
• SHIPTOZIP
• SHIPTOCOUNTRY
• SHIPTOPHONE
• SHIPTOPHONE2
• SHIPTOEMAIL

Order Information

• DOB
• DL
• SS
• CUSTIP
• BROWSERUSERAGENT
• BROWSERTIME
• BROWSERCOUNTRYCODE
• FREIGHTAMT
• TAXAMT
• COMMENT1
• DESC
• CUSTREF
• PONUM

Line Item (each item is appended with the line item number)

• L_COST0
• L_UPC0
• L_QTY0
• L_DESC0
• L_SKU0
• L_TYPE0

Response strings for transactions that trigger filters

In the response string to a transaction that triggered filters, you have the option to view either a summary statement or a detailed list of each triggered filter’s response. The response depends on your setting for the VERBOSITY parameter in the transaction request.

VERBOSITY=LOW: This is the default setting for Payflow accounts. The following values (described in the Payflow Gateway Developer’s Guide and Reference) are returned: {RESULT, PNREF, RESPMSG, AUTHCODE, AVSADDR, AVSZIP, CVV2MATCH, IAVS, CARDSECURE}.

The following values are specific to Fraud Protection Services:

VERBOSITY=MEDIUM: Returns all of the values returned for a LOW setting, plus the following values:

The table below shows the increments that are possible on basic TRANSSTATE values.

VERBOSITY=HIGH: Returns all of the values returned for a LOW and MEDIUM setting, plus all additional items returned by your processor. PayPal recommends all transactions be sent with VERBOSITY=HIGH.

RESULT values specific to Fraud Protection Services

A RESULT value greater than zero indicates a decline or error. For this type of error, a RESPMSG name-value pair is included. The exact wording of the RESPMSG may vary. Sometimes a colon appears after the initial RESPMSG followed by more detailed information, as shown in the following table:

Changing the verbosity setting

You may wish to change the verbosity level to alter the detail level of data received back for screened transactions.

Setting the default verbosity level for all transactions

PayPal suggests you contact Customer Service to set your account’s verbosity setting to HIGHfor all transaction requests.

Setting the verbosity level on a per-transaction basis

To specify a setting for verbosity that differs from your account’s current setting, include the VERBOSITY=<value> name-value pair in the transaction request, where <value> is LOW, MEDIUM or HIGH. PayPal suggests that verbosity be set to HIGH always.

Example response for an authentication transaction with Verbosity=Low

1RESULT=126&PNREF=VFHA28926593&RESPMSG=Under review by Fraud
2Service&AUTHCODE=041PNI&AVSADDR=Y&AVSZIP=N&CVV2MATCH=X&HOSTCODE=A&PROCAVS=
3A&PROCCVV2=X&IAVS=N&PREFPSMSG=Review: More than one rule was triggered for
4Review&POSTFPSMSG=Review: More than one rule was triggered for Review

Example response for an authentication transaction with Verbosity=Medium

1RESULT=126(0)&PNREF=VFHA28926593&RESPMSG=Under review by Fraud Service(Approved)&AUTHCODE=041PNI&AVSADDR=Y &AVSZIP=N&CVV2MATCH=X&HOSTCODE=A&PROCAVS=A&PROCCVV2=X&IAVS=N &PREFPSMSG=Review: More than one rule was triggered for Review&FPS_PREXMLDATA[2898]= <triggeredRules> <rule num="1"> <ruleId>2</ruleId> <ruleAlias>CeilingAmount</ruleAlias> <ruleDescription>Total Purchase Price Ceiling</ruleDescription> <action>R</action> <triggeredMessage>The purchase amount of 7501 is greater than the ceiling value set of 7500</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>CeilingValue</name> <value type="USD">75.00</value> </ruleParameter> </rulevendorparms> </rule> <rule num="2"> <ruleId>6</ruleId> <ruleAlias>HighOrderNumber</ruleAlias> <ruleDescription>Total ItemCeiling</ruleDescription> <action>R</action> <triggeredMessage>16 items were ordered, which is over the maximum allowed quantity of 15</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>Value</name> <value type="Integer">15</value> </ruleParameter> </rulevendorparms> </rule> <rule num="3"> <ruleId>7</ruleId> <ruleAlias>BillShipMismatch</ruleAlias> <ruleDescription>Shipping/BillingMismatch</ruleDescription> <action>R</action> <triggeredMessage>The billing and shipping addresses did not match</triggeredMessage> </rule> <rule num="4"> <ruleId>13</ruleId> <ruleAlias>HighRiskBinCheck</ruleAlias> <ruleDescription>BIN Risk List Match</ruleDescription> <action>R</action> <triggeredMessage>The card number is in a high risk bin list</triggeredMessage> </rule> <rule num="5"> <ruleId>37</ruleId> <ruleAlias>HighRiskZIPCheck</ruleAlias> <ruleDescription>Zip Risk List Match</ruleDescription> <action>R</action> <triggeredMessage>High risk shipping zip</triggeredMessage> </rule> <rule num="6"> <ruleId>16</ruleId> <ruleAlias>BillUSPostalAddressCheck</ruleAlias> <ruleDescription>USPS Address Validation Failure</ruleDescription> <action>R</action> <triggeredMessage>The billing address is not a valid US Address</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>AddressToVerify</name> <value type="String">bill</value> </ruleParameter> </rulevendorparms> </rule> <rule num="7"> <ruleId>10</ruleId> <ruleAlias>HighRiskEmailCheck</ruleAlias> <ruleDescription>Email Service Provider Risk List Match</ruleDescription> <action>R</action> <triggeredMessage>The email address fraud@asiamail.com in bill Email was found in a high risk email providerlist</triggeredMessage> </rule> <rule num="8"> <ruleId>38</ruleId> <ruleAlias>GeoLocationCheck</ruleAlias> <ruleDescription>Geo-Location Failure</ruleDescription> <action>R</action> <triggeredMessage>GeoLocation difference: Bill Address and IP, GeoLocation difference: Ship Address and IP</triggeredMessage> </rule> <rule num="9"> <ruleId>8</ruleId> <ruleAlias>NonUSIPAddress</ruleAlias> <ruleDescription>International IP Address</ruleDescription> <action>R</action> <triggeredMessage>The IP address is from: CZ</triggeredMessage> </rule> <rule num="1"> <ruleId>1</ruleId> <ruleAlias>AVS</ruleAlias> <ruleDescription>AVS Failure</ruleDescription><action>R</action> <triggeredMessage>AVS check failed: Full Security</triggeredMessage> <rulevendorparms> <ruleParameternum="1"> <name>Value</name> <value type="String">Full</value> </ruleParameter> </rulevendorparms> </rule> <rule num="2"> <ruleId>23</ruleId> <ruleAlias>CSCFailure</ruleAlias> <ruleDescription>CSC Failure</ruleDescription> <action>R</action> <triggeredMessage>CSC check failed, returned X</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>Value</name> <value type="String">Full</value> </ruleParameter> </rulevendorparms> </rule> </triggeredRules> RESULT=126&PNREF=VFHA28926593&RESPMSG=Under review by Fraud Service& AUTHCODE=041PNI&AVSADDR=Y&AVSZIP=N&CVV2MATCH=X&HOSTCODE=A& PROCAVS=A&PROCCVV2=X&IAVS=N&PREFPSMSG=Review: More than one rule was triggered for Review &FPS_PREXMLDATA[2898]= <triggeredRules> <rule num="1"> <ruleId>2</ruleId> <ruleAlias>CeilingAmount</ruleAlias> <ruleDescription>Total Purchase Price Ceiling</ruleDescription> <action>R</action> <triggeredMessage>The purchase amount of 7501 is greater than the ceiling value set of 7500</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>CeilingValue</name> <value type="USD">75.00</value> </ruleParameter> </rulevendorparms> </rule> <rule num="2"> <ruleId>6</ruleId> <ruleAlias>HighOrderNumber</ruleAlias> <ruleDescription>Total Item Ceiling</ruleDescription> <action>R</action> <triggeredMessage>16 items were ordered, which is over the maximum allowed quantity of 15</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>Value</name> <value type="Integer">15</value> </ruleParameter></rulevendorparms> </rule> <rule num="3"> <ruleId>7</ruleId> <ruleAlias>BillShipMismatch</ruleAlias> <ruleDescription>Shipping/Billing Mismatch</ruleDescription> <action>R</action> <triggeredMessage>The billing and shipping addresses did not match</triggeredMessage> </rule> <rule num="4"> <ruleId>13</ruleId> <ruleAlias>HighRiskBinCheck</ruleAlias> <ruleDescription>BIN Risk List Match</ruleDescription> <action>R</action> <triggeredMessage>The card number is in a high risk bin list</triggeredMessage> </rule> <rule num="5"> <ruleId>37</ruleId> <ruleAlias>HighRiskZIPCheck</ruleAlias> <ruleDescription>Zip Risk List Match</ruleDescription> <action>R</action> <triggeredMessage>High risk shipping zip</triggeredMessage> </rule> <rule num="6"> <ruleId>16</ruleId> <ruleAlias>BillUSPostalAddressCheck</ruleAlias> <ruleDescription>USPS Address Validation Failure</ruleDescription> <action>R</action> <triggeredMessage>The billing address is not a valid US Address</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>AddressToVerify</name> <value type="String">bill</value> </ruleParameter> </rulevendorparms> </rule> <rule num="7"> <ruleId>10</ruleId> <ruleAlias>HighRiskEmailCheck</ruleAlias> <ruleDescription>Email Service Provider Risk List Match</ruleDescription> <action>R</action> <triggeredMessage>The email address fraud@asiamail.com in billEmail was found in a high risk email provider list</ triggeredMessage> </rule> <rule num="8"> <ruleId>38</ruleId> <ruleAlias>GeoLocationCheck</ruleAlias> <ruleDescription>Geo-Location Failure</ruleDescription> <action>R</action> <triggeredMessage>GeoLocation difference: Bill Address and IP, GeoLocation difference:  Ship Address and IP</triggeredMessage> </rule> <rule num="9"> <ruleId>8</ruleId> <ruleAlias>NonUSIPAddress</ruleAlias> <ruleDescription>International IP Address</ruleDescription> <action>R</action> <triggeredMessage>The IP address is from: CZ</triggeredMessage> </rule> </triggeredRules> &POSTFPSMSG=Review:  More than one rule was triggered for Review&FPS_POSTXMLDATA[682]= <triggeredRules> <rule num="1"> <ruleId>1</ruleId> <ruleAlias>AVS</ruleAlias> <ruleDescription>AVS Failure</ruleDescription> <action>R</action><triggeredMessage>AVS check failed: Full Security</triggeredMessage> <rulevendorparms> <ruleParameter num="1"> <name>Value</name> <value type="String">Full</value> </ruleParameter> </rulevendorparms> </rule> <rule num="2"> <ruleId>23</ruleId> <ruleAlias>CSCFailure</ruleAlias> <ruleDescription>CSC Failure</ruleDescription> <action>R</action> <triggeredMessage>CSC check failed, returned X</triggeredMessage> <rulevendorparms> <ruleParameter num="1"><name>Value</name> <value type="String">Full</value> </ruleParameter> </rulevendorparms> </rule> </triggeredRules>

Accepting or rejecting transactions that trigger filters

You can submit a transaction request that either accepts or rejects a transaction that triggered a filter (result code 126). This is the functional equivalent of the operations discussed in Acting on transactions that triggered filters.

• Accept: Submit the transaction for normal processing.
• Reject: Do not submit the transaction for processing. See Rejecting transactions.

To accept or reject a transaction, include the following values in the transaction request:

• TRXTYPE=U
• ORIGID=<PNREF returned for the original transaction>
• UPDATEACTION=APPROVE (to accept); OR
• UPDATEACTION=FPS_MERCHANT_DECLINE (to reject)

Logging transaction information

A record is maintained of all transactions executed on your account. Use PayPal Manager to view the record and use the information to help reconcile your accounting records.

In addition, it is strongly recommended to log all transaction results (except for check information) on your own system. At a minimum, log the following data:

• PNREF (called the Transaction ID in PayPal Manager reports)
• Transaction Date
• Transaction Amount

If you have any questions regarding a transaction, use the PNREF to identify the transaction.

Responses to credit card transaction requests

This section describes the contents of a response to a credit card transaction request.

An example response string

When a transaction finishes, the server returns a response string made up of name-value pairs. For example, this is a response to a credit card Sale transaction request:

RESULT=0&PNREF=VXYZ01234567&RESPMSG=APPROVED&AUTHCODE=123456&AVSADDR=Y&AVSZIP=N&IAVS=Y&CVV2MATCH=Y

Contents of a response to a credit card transaction request

All transaction responses include values for RESULT, PNREF, and RESPMSG. A value for AUTHCODE is included for Voice Authorization transactions. Values for AVSADDR and AVSZIP are included if you use address verification system (AVS). The table below describes the values returned in a response string. 

PNREF value

The PNREF is a unique transaction identification number issued by the server that identifies the transaction for billing, reporting, and transaction data purposes. The PNREF value appears in the transaction ID column in PayPal Manager reports.

• The PNREF value is used as the ORIGID value (original transaction ID) in delayed capture transactions (TRXTYPE=D), credits (TRXTYPE=C), inquiries (TRXTYPE=I), and voids (TRXTYPE=V).
• The PNREF value is used as the ORIGID value (original transaction ID) value in reference transactions for authorization (TRXTYPE=A) and Sale (TRXTYPE=S).

PNREF format

The PNREF is a 12-character string of printable characters, for example:

• EFHP0D426838
• ACRAF23DB3C4

Historically, the contents of a PNREF indicated a test or a live transaction. However, this is not always the case, and as a rule, you should not place any meaning on the contents of a PNREF.

RESULT codes and RESPMSG values

RESULT is the first value returned in the server response string. The value of the RESULT parameter indicates the overall status of the transaction attempt.

• A value of 0 (zero) indicates that no errors occurred and the transaction was approved.
• A value less than zero indicates that a communication error occurred. In this case, no transaction is attempted.
• A value greater than zero indicates a decline or error.

The response message (RESPMSG) provides a brief description for decline or error results.

RESULT values for transaction declines or errors

For non-zero results, the response string includes a RESPMSG name-value pair. The exact wording of the RESPMSG (shown in bold) may vary. Sometimes a colon appears after the initial RESPMSG followed by more detailed information.

1RESPMSG=Fraudulent activity detected: Excessive use of a credit
2                    card

RESULT values for communications errors

A RESULT value less than zero indicates that a communication error occurred. In this case, no transaction is attempted.

A value of -1 or -2 usually indicates a configuration error caused by an incorrect URL or by configuration issues with your firewall. A value of -1 or -2 can also be possible if the PayPal servers are unavailable, or an incorrect server/socket pair has been specified. A value of -1 can also result when there are internet connectivity errors. Contact customer support regarding any other errors.

Fraud filter reference

This section describes the filters that make up part of the Fraud Protection Services. Filters analyze transactions and act on those that show evidence of potential fraudulent activity. Filters can set such transactions aside for your review or reject them outright, depending on settings that you specify.

Filters are grouped to help you to assess the risk types and to take action (accept, reject, or continue in the review state).

Filters included with the fraud protection services

Fraud Protection Services offers Basic and Advanced options. The filters included with each option are listed here.

Filters included with the Basic fraud protection services option include:

• Total purchase price ceiling filter
• Total item ceiling filter
• Shipping-billing mismatch filter
• AVS failure filter
• Card security code failure filter
• ZIP risk list match filter
• USPS address validation Failure Filter
• IP address velocity filter

Filters included with the Advanced fraud protection services option includes all Basic filters, plus:

• Buyer authentication failure filter
• USPS address validation failure filter
• Email Service Provider Risk List Match Filter
• IP address match filter
• Account number velocity filter
• Geo-location failure filter
• Bad lists
• International shipping-billing address filter
• International AVS filter
• International IP address filter
• Country risk list match filter
• Good Lists
• Total Purchase Price Floor Filter
• Custom Filters
• Product Watch List Filter

About the fraud risk lists

Filters whose name includes "risk list" make use of lists that the Fraud Protections Services manage. Extensive statistical analysis of millions of e-commerce transactions is performed to determine transaction data elements (for example BIN numbers or ZIP codes) that are statistically more likely than average to be correlated with fraudulent transactions.

Inclusion in a risk list is not an absolute indication of fraud, only a statistical correlation that indicates that you should evaluate the transaction more closely (and in conjunction with other filter results for the transaction).

Filters applied after processing

Most filters are applied to the transaction request before forwarding the request to the processor. The following filters are applied to the transaction results that the processor returns:

• AVS failure filter
• Card security code failure filter
• International AVS filter
• Custom filters

Transaction Data Required by Filters

Downloading the Payflow SDK (including APIs and API documentation) provides the full list, for each filter, of each transaction value that you must send to Payflow. For example, to ensure that the total item ceiling filter can screen an order, you must provide the total number of items that make up the order.

Unusual Order Filters

Unusual order filters identify transactions that exceed the normal size for your business. Because fraudsters might not feel limited in their purchasing power, they sometimes place orders that are much larger than the norm.

Total purchase price ceiling filter

This filter compares the total amount of the transaction (including tax, shipping and handling fees) to the maximum purchase amount (the ceiling) that you specify.

The specified action is taken whenever a transaction amount exceeds the specified ceiling.

An unusually high purchase amount (compared to the average for your business) can indicate potential fraudulent activity. Because fraudsters are not paying with their own money, they are not price-sensitive.

Total item ceiling filter

This filter compares the total number of items (or volume for bulk commodities) to the maximum count (the ceiling) that you specify.

The specified action is taken whenever the item count in a transaction exceeds the specified ceiling.

An unusually high item count (compared to the average for your business) can indicate potential fraudulent activity. Fraudsters frequently attempt to order large numbers of attractive items that can easily be resold.

Shipping-billing mismatch filter

What does the filter do?

This filter screens for differences between the shipping information and the billing information (street, state, ZIP code, and country).

The specified action is taken whenever the shipping information differs from the billing information.

Data normalization

The shipping/billing mismatch filter is tolerant of minor address inaccuracies that result from typographical or spelling errors. The filter checks relationships among the street address, city, state, and ZIP code and determines if a minor change is needed before screening the transaction.

Because this normalization happens during data validation by the Payflow server, the data as entered by the customer will still appear in its original form on all transaction data review pages. This means that you might see the following entries not flagged as mismatches on the Fraud Details page:

1Billing                  Shipping Steve Morrison           Steve Morrison 4390 Ramirez             4390 Ramires San Francisco, CA        San Francisco, CA 94114                    94113

How does the filter protect me?

There are legitimate reasons for a shipping/billing mismatch with a customer purchase—for example, gift purchases might fit this profile. But a mismatch could also indicate that someone is using a stolen identity to complete a purchase (and having the items sent to another address from which they can retrieve the stolen items).

To help to distinguish between legitimate and fraudulent orders, review all mismatches by cross-checking other purchase information such as AVS and card security code.

Product watch list filter

The product watch list filter compares SKUs (or other product identifiers) of the products in a transaction against a product watch list you create. Any transaction containing an SKU in the list triggers the filter. If you enable this filter, then you must set up the list of products that should be monitored.

Some products are attractive to fraudsters (especially popular products with high resale value like computers or televisions). The Product Watch List filter gives you the opportunity to review transactions involving such products to ensure that the order is legitimate.

High-risk payment filters

High-risk payment filters identify transactions that show billing/shipping discrepancies or an indication that someone other than the legitimate account holder is initiating the transaction.

AVS failure filter

This filter compares the street number and the ZIP code submitted by the customer against the data on file with the issuer.

The AVS response is composed of a Y, N, or X value for the customer’s street address and a Y, N, or X value for the ZIP code. For example, the response for a correct street number and an incorrect ZIP code is YN.

If AVS information is not submitted with the transaction, then the response is NN.

AVS checks only for a street number match, not a street name match, so 123 Main Street returns the same response as 123 Elm Street. The USPS address validation failure filter validates the address information.

Specifying the level of AVS checking

Specify one of the AVS settings:

• Full: Take action if a transaction returns any value other than YY (Y for street address and Y for ZIP code).
• Medium: Take action if a transaction returns values other than these: XX, XY, YX, and YY.
• Light: Take action only if NN is returned.

This table summarizes AVS levels:

Buyers who can provide the street number and ZIP code on file with the issuing bank are more likely to be the actual account holder. AVS matches, however, are not a guarantee. Use card security code and Buyer Authentication in addition to AVS to increase your certainty.

Card security code failure filter

The card security code is a 3- or 4-digit number (not part of the credit card number) that appears on credit card. Because the card security code appears only on the card and not on receipts or statements, the card security code provides some assurance that the physical card is in the possession of the buyer.

About the card security code

The card security code is printed on the back of most cards (usually in the signature field). All or part of the card number appears before the card security code (567 in the example). For American Express, the 4-digit number (1122 in the example) is printed on the front of the card, above and to the right of the embossed account number. Be sure to explain this to your customers.

The card security code check compares the number provided by the customer with the number on file with the issuer and returns one of the following responses:

Card security code failure filter action

The specified action is taken whenever the card security code response is the value that you specified.

Best practice is to review all transactions with responses other than Y. You set the "strength" of the filter as follows:

• Full: Take action if a value of N or X is returned.
• Medium: Take action only if a value of N is returned.

Buyer authentication failure filter

Buyer Authentication refers to the card-sponsored authentication services such as Verified by Visa and Mastercard Secure Code that make use of the 3-D Secure protocol. These authentication methods prompt buyers to provide a password to their card issuer before being allowed to execute a credit card purchase.

You must enroll for the Buyer Authentication Service in the Fraud Protection Services suite to make use of the buyer authentication failure filter. The filter is grayed out on configuration pages if you are not enrolled.

The filter is triggered when the customer’s identity is not adequately authenticated, according to criteria that you specify.

Buyer authentication results

Although Mastercard and Visa both use the underlying 3-D Secure protocol to implement buyer authentication, they have different liability rules regarding buyer authentication results. Those are covered in the following table.

Mastercard converts 3-D Secure results into UCAF fields. To simplify for the merchant, all responses are normalized into the values listed in the following table.

Buyer authentication returns one of the following responses in the AUTHENTICATION_STATUS name-value pair (values are for Visa United States region):

Actions

You set the "strength" of the filter as follows:

• Full: Trigger if a value of N, U, or F is returned.
• Medium: Trigger only if a value of N is returned.

How does the filter protect me?

Buyer authentication is the only screening tool that promises to shift fraud liability from the merchant. The password used with Verified by Visa and Mastercard Secure Code is the digital equivalent to a shopper’s handwritten signature.

Widespread account holder enrollment in buyer authentication programs may take some time and depends on the card issuers supporting and marketing the option.

BIN risk list match filter

This checks the Bank Identification Number (BIN) on a card for banks flagged as possible risks.

The BIN makes up the first six digits of a credit card number and identifies the bank that issued the card. This filter screens every credit card number for BINs on the high-risk list.

The specified action is taken whenever a BIN matches one on the list.

Certain BINs might be associated with a greater degree of fraud because the issuer uses less stringent authentication policies when issuing cards. In other cases, because some issuers have a large number of cards in circulation, the cards are more likely to fall into the hands of fraudsters.

Account number velocity filter

The account number velocity filter is triggered for excessive use of a card within a short period of time.

What does the filter do?

The account number velocity filter triggers when any credit card account number is used five times within a three-day (72-hour) period.

What is velocity?

In the risk management industry, an event’s velocity is a measure of its frequency of occurrence during a defined time period. Unusually high velocity is can be associated with repeated fraudulent attacks on a system. Legitimate customers do not typically perform multiple transactions in quick succession.

How does the filter protect me?

Fraudsters often submit multiple purchases with a single account number to try to discover the card’s valid billing address or card security code. Alternatively, the fraudster may attempt to bypass ceiling filters by making multiple small purchases with a know good account number.

High-risk address filters

High risk address filters identify transactions associated with high-risk geographical locations or poorly-matched transaction data.

ZIP risk list match filter

This filter checks for high risk ZIP codes.

This filter compares the ship to and bill to ZIP codes (US only) against the high-risk list. High-risk ZIP codes are determined based on analysis of millions of e-commerce transactions. The specified action is taken whenever a submitted ZIP code appears in the risk list.

Matching a ZIP code on the risk list does not necessarily indicate a fraudulent purchase, but that you should evaluate these transactions more closely than other transactions.

USPS address validation failure filter

This filter screens the ship to and bill to addresses (street number, street name, state, and ZIP code) against the United States Postal Service database of existing addresses. The USPS updates the database continually.

The specified action is taken whenever the address cannot be validated (it does not exist or is incorrect in some way).

To trick a merchant’s filters, fraudsters sometimes deliberately misspell or make up street names. This enables the fraudster to spoof AVS, geo-location, and high-risk address filters. You can identify this basic form of spoofing by using the USPS address validation filter to determine whether an address really exists.

IP address match filter

This filter screens the IP address from which a transaction originates against a list of high-risk IP addresses. An IP (Internet protocol) address is a unique identifier for a computer on a TCP/IP network that can identify a particular network and a particular computer on that network.

The specified action is taken whenever a submitted IP address appears in the risk list.

A customer’s IP address identifies a country, region, state, or city. As with ZIP codes, these addresses can be associated with higher or lower likelihood of fraud. This is especially true with high-risk countries that are known to be associated with especially high rates of fraud.

Required transaction data

You must send the customer’s IP address to use this filter.

Email service provider risk list match filter

This filter compares the e-mail service provider used by the customer against a list of high-risk e-mail service providers.

The specified action is taken whenever the e-mail service provider is found in the risk list.

Online merchants rarely talk to their customers. The customer’s e-mail address is a critical communications channel between the merchant and customer. For example, e-mail is often used to confirm a purchase and to notify the customer that shipment has been made. It is therefore important for merchants to determine how reliably the e-mail address is tied to the identity of the customer. Some e-mail service providers make it especially easy to open and close e-mail accounts without ever providing personal information, enabling fraudsters to use false identities to cover their tracks. You should examine any transaction in which a high-risk e-mail service provider is involved.

Geo-location failure filter

This filter compares the IP address of the customer’s computer (captured in real-time when the transaction is submitted) and compares its geographical location to the billing and shipping addresses. IP (Internet protocol) addresses are unique identifiers for computers that can often be mapped to a specific city or area code.

The specified action is taken whenever the IP address, shipping address, and billing address do not fall within a 100 mile radius. If you provide only one physical address (billing or shipping address), then the filter triggers when the distance between the IP address and the address that you provided is greater than 100 miles.

Comparing the geographical location associated with the IP address to the submitted shipping and billing information can be an effective method for identifying identity spoofing. Fraudsters often pretend to live in one location, but live and shop from another.

All three elements should match one realistic customer profile. For example, a customer with a billing address in New York would typically shop from a computer in New York, and request delivery to a New York address. While there may be some minor inconsistencies in the overall profile, it should generally fit together. Remember, however, that gift purchases sent to another part of the country will not fit this profile.

IP address velocity filter

This filter is triggered for numerous transactions from the same IP address.

What does the filter do?

The IP address velocity filter triggers when five or more transactions within three days (72 hours) originate from any individual IP address.

What is velocity?

In the risk management industry, an event’s velocity is a measure of its frequency of occurrence during a defined time period. Unusually high velocity is can be associated with a fraudster making repeated attacks on a system. Legitimate customers do not typically perform multiple transactions in quick succession.

How does the filter protect me?

Fraudsters often submit multiple purchases using an automated script that tests unknown card numbers. Alternatively, the fraudster may attempt to bypass other filters by making multiple small purchases with multiple stolen account numbers.

High risk customer filters

These filters flag high risk customer transactions.

Bad lists

These filters trigger for information linked to fraudulent or otherwise "bad" customers.

This filter compares the customer’s e-mail address and credit card number against lists (that you create) of addresses and numbers for known bad customers.

Any transaction that is an exact match with an entry in one of your bad lists triggers the filter.

If you enable this filter, then your next step will be to set up lists of bad email addresses and bad card numbers. Be sure to type the e-mail addresses and credit card numbers accurately. Enter only numerals in the credit card number list—no spaces or dashes.

This filter enables you to block repeat fraud. In the e-commerce world, after someone successfully performs a fraudulent transaction, they are very likely to try again. For this reason, you should set up lists of cards and email addresses and configure this filter to take action on transactions with data elements appearing in the bad lists.

International order filters

International order filters identify transactions associated with risky international locations.

Country risk list match filter

This filter screens the customer’s shipping and billing address information for matches with countries on the list of high-risk countries.

The specified action is taken whenever any of the information matches a country on the risk list.

Orders from customers in foreign countries are more likely to be fraudulent than orders from domestic customers. This is due to the difficulty of authenticating foreign citizens and the difficulty of cross-border legal enforcement against fraudulent activities.

Certain countries, however, are much riskier than others. These countries have high likelihood of fraud and you should evaluate transactions from these countries closely.

International shipping-billing address filter

This filter screens the customer’s shipping and billing information for non-U.S. addresses. The filter checks for country code 840, or any derivation of "United States" (U.S., USA, United States of America, America, and so on) in the country fields. Any other country name triggers the filter.

Orders from customers in foreign countries are more likely to be fraudulent than orders from domestic customers. This is due to the difficulty of authenticating foreign citizens and the difficulty of cross-border legal enforcement against fraudulent activities.

The international shipping-billing address filter sets aside transactions from customers in foreign countries so that you can evaluate them more fully.

International IP address filter

This filter screens for international IP addresses. An IP (Internet protocol) address is a unique identifier for a computer that can identify a particular network and a particular computer on that network.

The specified action is taken whenever the IP address indicates an international computer or network.

Orders from customers in foreign countries are more likely to be fraudulent than orders from domestic customers. This is due to the difficulty of authenticating foreign citizens as well as the difficulty of cross-border legal enforcement against fraudulent activities.

The international IP address filter sets aside transactions from customers in foreign countries so that you can evaluate them more fully.

International AVS filter

This filter determines whether the card issuer is domestic or international.

What does the filter do?

International Address Verification Service (IAVS) determines whether the card number is associated with a domestic (US) or international issuer. See the following table:

The specified action is taken whenever AVS returns Y.

Special requirements

International AVS is not currently widely supported by processors. Check to see if your processor supports international AVS.

• FISERV Nashville, Elavon, and Vantiv return IAVS responses for all card types.
• All other processors always return N or X.

How does the filter protect me?

Orders from customers in foreign countries are more likely to be fraudulent than orders from domestic customers. This is due to the difficulty of authenticating foreign citizens as well as the difficulty of cross-border legal enforcement against fraudulent activities.

The international AVS filter sets aside transactions from customers with cards issued in foreign countries so that you can evaluate them more fully.

Accept filters

Accept filters immediately approve transactions that meet characteristics that you specify. If a filter in this group is triggered, then the transaction is accepted regardless of review filter results.

Good lists

This list provides a way to avoid applying fraud filters to known good customers.

This filter compares the customer’s e-mail address and credit card number against lists (that you create) of addresses and numbers for known good customers. You create the lists.

Any transaction for which the e-mail address or credit card number is an exact match with an entry in one of your good lists is accepted and no other filters are applied. Enter only numerals in the credit card number list—no spaces or dashes.

Items that you enter in the test good lists are not carried over to your configuration for the live servers, so do not spend time entering a complete list for the test configuration. If you activate this filter, then you must set up lists of good email addresses and good card numbers. Be sure to type the e-mail addresses and credit card numbers accurately.

Good lists do not authenticate individuals. If a fraudster were to steal e-mail addresses or credit card account numbers from this list, then they would be able to bypass the filter.

To ensure that loyal repeat customers are not held up by your fraud review process, you may want to create lists of e-mail addresses and card numbers that should be accepted. This ensures that an abnormal shopping pattern on the part of a loyal customer (for example making a purchase while on vacation overseas) does not trigger a filter and delay the transaction.

Total purchase price floor filter

This sets a floor so that small transactions will not be run through fraud filter screening.

This filter screens the total amount of a transaction (including tax, shipping and handling fees).

If a transaction amount is below the price set for this filter, then the transaction is accepted and no other filters are applied.

Merchants with an especially high transaction volume can use this filter to reduce the number of transactions that their staff must review—transactions below the specified price level are accepted without further analysis.

Custom filters

You create custom filters by combining up to five existing filters. A well-designed custom filter can more accurately identify suspicious transactions because it is fine-tuned to the unique needs of your business (for example, you can specify a particular combination of amount, buyer location, and shipping location). For this reason, fewer legitimate transactions are unnecessarily held for review.

For example, a custom filter that triggers only when both the card security code failure and AVS failure filters trigger will set aside transactions that are especially suspicious.

See PayPal Manager online help for details on creating a custom filter.

Testing the transaction security filters

Each example transaction shown in this section is designed to test the operation of a single filter. To test a filter, disable all other filters and submit the transaction. The filter should be triggered and display its results in the Transaction Detail page.

In the examples, the critical transaction data is shown in bold type.

Testing the good and bad lists

To test the good and bad list filters, add good and bad entries to the list and then submit a transaction using a value in the list.

Testing the AVS failure filter

1TRXTYPE=A&ACCT=5105105105105100&AMT[4]=1.02&BILLTOPHONE2=650-555-0123 &BROWSERCOUNTRYCODE=203&BROWSERTIME[22]=July 11, 2002 12:12:12& BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=Campbell&COMMENT1= Automated testing from AdminTester&BILLTOCOUNTRY=840&CUSTIP=194.213.32.220&CUSTREF=CUSTREF& DESC=DESC&DL=CA111111&DOB=CA123456&BILLTOEMAIL[17]=Admin@merchant.com&EXPDATE= 1209&BILLTOFIRSTNAME=John&FREIGHTAMT=1.11&BILLTOLASTNAME=Johnson&L_COST0=11.11& L_DESC0=L_DESC0&L_QTY0=1&L_SKU0=L_SKU0&L_TYPE0=L_TYPE0&L_UPC0=L_UPC0& BILLTOMIDDLENAME=Z&ORDERTIMEZONE=1&PARTNER=PayPal&PHONENUM=650-555-0123& PONUM=PONUM&PWD=testing1&SHIPCARRIER=SHIPCARRIER&SHIPMETHOD=SHIPMETHOD&SHIPTOCITY= Mountain View&COUNTRYCODE=US&SHIPTOEMAIL[17]=Admin@merchant.com& SHIPTOFIRSTNAME=SHIPTOFIRSTNAME&SHIPTOLASTNAME=SHIPTOLASTNAME&SHIPTOMIDDLENAME= SHIPTOMIDDLENAME&SHIPTOPHONE=650-555-0124&SHIPTOPHONE2=650-555-0125& SHIPTOSTATE=CA&SHIPTOSTREET=487 East Middlefield Road&SHIPTOSTREET2=487 East Middlefield Road& SHIPTOZIP=94043&SS=565796510&BILLTOSTATE=CA&BILLTOSTREET=667 W. Rincon Ave&BILLTOSTREET2=Unit C&TAXAMT=1.02&TENDER=C&USER= TESTAVSRejectFull&VENDOR=TESTAVSRejectFull&BILLTOZIP=99999

Expected response message

1resp mesg=RESULT=125&PNREF=VBCA25034255&RESPMSG=Declined by Fraud Service &AUTHCODE=421PNI&AVSADDR=X&AVSZIP=X&IAVS=X&PREFPSMSG=No Rules Triggered&POSTFPSMSG=Reject AVS !!ERROR 16:55:6 result=125 TRXTYPE=A!!

Testing the BIN risk list match filter

Pass in the appropriate credit card number for the card brand:

• American Express: 378282246310005
• Mastercard: 5555555555554444
• Visa: 4610251000010168

1TRXTYPE=A&ACCT=4610251000010168&AMT[8]=$1000.00&BILLTOPHONE2=650-555-0123& BILLTOSTREET2=123 BILLTOSTREET&BROWSERCOUNTRYCODE=203&BROWSERTIME[22]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Automated testing from AdminTester&BILLTOCOUNTRY=203&CUSTIP=66.218.71.93&CUSTREF=CUSTREF&DESC=DESC&DL=CA111111& DOB=CA123456&BILLTOEMAIL[20]=admin@merchant.com&EXPDATE=1209&BILLTOFIRSTNAME=John&FREIGHTAMT=1.11& BILLTOLASTNAME=Johnson&L_COST0=11.11&L_DESC0=L_DESC0&L_QTY0=1&L_SKU0=L_SKU0&L_TYPE0=L_TYPE0&L_UPC0= L_UPC0&BILLTOMIDDLENAME=Z&ORDERTIMEZONE=1&PARTNER=PayPal&PHONENUM=650-555-0123&PONUM=PONUM& PWD=testing1&SHIPCARRIER=SHIPCARRIER&SHIPMETHOD=SHIPMETHOD&SHIPTOCITY=No City&SHIPTOCOUNTRY=203& SHIPTOEMAIL[20]=admin@merchant.com&SHIPTOFIRSTNAME=SHIPTOFIRSTNAME&SHIPTOLASTNAME=SHIPTOLASTNAME& SHIPTOMIDDLENAME=SHIPTOMIDDLENAME&SHIPTOPHONE=650-555-0124&SHIPTOPHONE2=650-555-0125&SHIPTOSTATE= CA&SHIPTOSTREET=123 Main St.&SHIPTOSTREET2=123 SHIPTOSTREET 2&SHIPTOZIP=11111&SS=565796510&BILLTOSTATE= CA&BILLTOSTREET=123 Main St.&BILLTOSTREET2=123 SHIPTOSTREET2&TAXAMT=1.01&TENDER=C&USER= TESTHighRiskBinCheckReject&VENDOR=TESTHighRiskBinCheckReject&BILLTOZIP=11111

Expected response message

1resp mesg=RESULT=125&PNREF=VB0A25033363&RESPMSG=Declined by Fraud Service& PREFPSMSG=Reject HighRiskBinCheck !!ERROR 15:52:54 result=125 TRXTYPE=A!!

Testing the country risk list match filter