Payflow Pro Fraud Protection Services User’s Guide For Professional Use Only Currently only available in English. A usage Professional Uniquement Disponible en Anglais uniquement pour l’instant.
Payflow Pro Fraud Protection Services User’s Guide Document Number: 200011.en_US-200806 © 2008 PayPal, Inc. All rights reserved. PayPal is a registered trademark of PayPal, Inc. The PayPal logo is a trademark of PayPal, Inc. Other trademarks and brands are the property of their respective owners. The information in this document belongs to PayPal, Inc. It may not be used, reproduced or disclosed without the written approval of PayPal, Inc. Copyright © PayPal. All rights reserved. PayPal S.à r.l. et Cie, S.
Content Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Revision History . . . . . . . . . . . .
Content Acting on Transactions that Triggered Filters . . . . . . . . . . . . . . . . . . . . . . 22 Rejecting Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Fine-tuning Filter Settings—Using the Filter Scorecard . . . . . . . . . . . . . . . . . . . 22 Ensuring Meaningful Data on the Filter Scorecard . . . . . . . . . . . . . . . . . . . 23 Re-running Transactions That Were Not Screened . . . . . . . . . . . . . . . . . . . . .
Content Logging Transaction Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Audit Trail and Transaction Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Chapter 7 Screening Transactions Using the Payflow SDK . . . . . . 49 Downloading the Payflow SDK (Including APIs and API Documentation) . . . . . . . . . . 49 Transaction Data Required by Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Transaction Parameters Unique to the Filters . . . . .
Content Product Watch List Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 High-risk Payment Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 AVS Failure Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Card Security Code Failure Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Buyer Authentication Failure Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 BIN Risk List Match Filter . .
Content IP Address Match Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Shipping/Billing Mismatch Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Total Item Ceiling Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 Total Purchase Price Ceiling Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 Total Purchase Price Floor Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Content 8
Preface 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. For details on how to configure and use Fraud Protection Services and to generate Buyer Authentication reports through PayPal Manager, see PayPal Manager online help. Intended Audience This document is intended for Payflow Pro merchants who subscribe to any Fraud Protection Services options.
Preface Customer Service z z z z Appendix A, “Fraud Filter Reference,” describes the Transaction filters that make up part of the Fraud Protection Services. Appendix B, “Testing the Transaction Security Filters,” provides Payflow SDK transactions that you can use to test the filters. Appendix C, “Testing Buyer Authentication Transactions Using the Payflow SDK, provides examples of testing Buyer Authentication transactions.
1 Overview This chapter discusses how fraud can affect you the merchant and provides an overview of Fraud Protection Services. In This Chapter z “Growing Problem of Fraud” on page 11 z “Reducing the Cost of Fraud” on page 11 Growing Problem of Fraud Online fraud is a serious and growing problem.
1 12 Overview Reducing the Cost of Fraud Fraud Protection Services User’s Guide
2 How Fraud Protection Services Protect You This chapter describes the security tools that make up the Fraud Protection Services. In This Chapter z “The Threats” on page 13 z “Protection Against the Threats—Fraud Filters” on page 13 z “Special Considerations” on page 14 The Threats There are two major types of fraud—hacking and credit card fraud.
2 How Fraud Protection Services Protect You Special Considerations 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 that exceeds the specified ceiling triggers the filter.
3 Configuring the Fraud Protection Services Filters This chapter describes how to configure the Fraud Filters for your Payflow Pro account. The chapter explains a phased approach to implementing the security of transactions. You are not required to use the approach described in this chapter. However it enables you to fine tune your use of filters before you actually deploy them in a live environment. You first make and fine-tune filter settings in a test environment.
3 Configuring the Fraud Protection Services Filters Phase 1: Run Test Transactions Against Filter Settings on Test Transaction Security Servers 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. You then run test transactions against the filters and review the results offline to determine whether the integration was successful.
Configuring the Fraud Protection Services Filters Phase 2: Run Live Transactions on Live Transaction Servers in Observe Mode 3 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.
3 Configuring the Fraud Protection Services Filters Phase 3: Run All Transactions Through the Live Transaction Security Servers Using Active Mode Phase 3: Run All Transactions Through the Live Transaction Security Servers Using Active Mode Once you have configured all filters to optimum settings, you 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.
4 Assessing Transactions that Triggered Filters As part of the task of minimizing the risk of fraud, you review each transaction that triggered a filter. You decide, based on the transaction’s risk profile, whether to accept or reject the transaction. This chapter describes how to review transactions that triggered filters, and provides guidance on deciding on risk.
4 Assessing Transactions that Triggered Filters Reviewing Suspicious Transactions FIGURE 4.1 Fraud Transactions Report page 2. Specify the date range of the transactions to review. 3. Specify a Transaction Type: TABLE 4.1 Transaction types Transaction Type Description Reject Transactions that the filters rejected. These transactions cannot be settled. The type of filter that took this action is called a Reject filter. Review Transactions that the filters set aside for your review.
Assessing Transactions that Triggered Filters Reviewing Suspicious Transactions 4 N O T E : If filters are deployed in Observe mode, then all transactions have been submitted for processing and are ready to settle. Transactions are marked with the action that the filter would have taken had the filters been deployed in Active mode. The following information appears in the report: TABLE 4.2 Transactions Report field descriptions Heading Description Report Type The type of report created.
4 Assessing Transactions that Triggered Filters Fine-tuning Filter Settings—Using the Filter Scorecard 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).
Assessing Transactions that Triggered Filters Fine-tuning Filter Settings—Using the Filter Scorecard 4 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.
4 Assessing Transactions that Triggered Filters Re-running Transactions That Were Not Screened 31, three different price ceiling settings caused the filter to trigger, yet the Scorecard would not indicate this fact. To ensure meaningful results in the Filter Scorecard, specify a time period during which the filter settings did not change.
5 Activating and Configuring the Buyer Authentication Service This chapter describes how to enroll, configure, test, and activate the Buyer Authentication Service.
5 Activating and Configuring the Buyer Authentication Service Configuring Buyer Authentication IMPO RTANT: Full API documentation is included with each SDK. Configuring Buyer Authentication To enable Buyer Authentication processing on your site, you will need to construct two transaction requests (messages) and construct a frameset. You can accomplish the tasks in a few hours.
Activating and Configuring the Buyer Authentication Service Configuring Buyer Authentication 5 Generate Transaction Request Software 1. Submit a Verify Enrollment transaction request (type E) to determine whether the cardholder is enrolled in either the Verified by Visa or MasterCard SecureCode service. See the example on page 38. 2. The response is either Enrolled or Not Enrolled. See the example responses on page 38. 3.
5 Activating and Configuring the Buyer Authentication Service Testing and Activating the Service 5. When the customer enters their password and clicks Submit, the ACS verifies the password and posts a response to the TermURL (the page on your site that is configured to receive ACS responses). 6.
Activating and Configuring the Buyer Authentication Service Testing and Activating the Service 5 Failure messaging. The example text in the red box handles cases where customers cannot successfully authenticate themselves. The text requests another form of payment.
5 Activating and Configuring the Buyer Authentication Service Testing and Activating the Service Consumer Messaging for Failed Authentication: Please submit new form of payment. 2. Perform a last round of test transactions as described in Appendix C, “Testing Buyer Authentication Transactions Using the Payflow SDK,” to ensure the flow and screen presentation is correct. 3.
6 Performing Buyer Authentication Transactions Using the SDK This chapter describes the process of performing Buyer Authentication transactions using the Payflow SDK. For information on using the SDK and on transaction syntax see Payflow Pro Developer’s Guide. The content and format of responses to transaction requests are described in “Buyer Authentication Transaction Parameters and Return Values” on page 40. Standard Payflow Pro response values are described in Payflow Pro Developer’s Guide.
6 Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Terminology issuing bank authenticates the customer’s identity by returning a payer authentication response value to your program. 3. Your program then validates the authentication response. 4. If the authentication data is valid, then your program submits a standard Payflow authorization or sale transaction that includes the buyer authentication data.
Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Server URLs 6 Buyer Authentication Server URLs IMPO RTANT: URLs listed here are used only for buyer authentication transactions: Verify Enrollment (TRXNTYPE=E) and Validate Authentication (TRXNTYPE=Z). z The production Buyer Authentication server URL is buyerauth.verisign.com z The test Buyer Authentication server URL is pilot-buyerauth.verisign.
6 Performing Buyer Authentication Transactions Using the SDK Detailed Buyer Authentication Transaction Flow Generate the data for the intended transaction Merchant Web Store 510551055105 $42.02 Transaction Data AMT=42.02 DESCRIPTION=case ACCT=5105510551055555 EXPDATE=0306 NAME=johnson BUY "Is this cardholder enrolled?" TRXTYPE=E ACCT=5105510551055555 EXPDATE=0308 1 Verify Enrollment call RESULT=0 AUTH_STATUS=E AUTH_ID=1A3D4G PAREQ=J84H+To4vv6K ACSURL=www.issuer.
Performing Buyer Authentication Transactions Using the SDK Detailed Buyer Authentication Transaction Flow "Please authenticate this customer." 2 HTTP method="POST" PaReq=J84H+To4vv6K TermUrl=http://merchantpage.
6 Performing Buyer Authentication Transactions Using the SDK Detailed Buyer Authentication Transaction Flow
Click Submit to continue processing your 3-D Secure transaction.
Performing Buyer Authentication Transactions Using the SDK Example Buyer Authentication Transactions 6 the standard sale or authorization transaction data, you include buyer authentication data, as follows: (Standard values:) "Here's a Sale transaction, and I've included Buyer Authentication data" TRXTYPE=S TENDER=C AMT=42.
6 Performing Buyer Authentication Transactions Using the SDK Example Buyer Authentication Transactions Example Verify Enrollment Transaction Use TRXTYPE=E to submit a Verify Enrollment request transaction. The following is an example name-value pair parameter string. "TRXTYPE=E&ACCT=5105105105105100&AMT=19.
Performing Buyer Authentication Transactions Using the SDK Example Buyer Authentication Transactions 6 Example Validate Authentication Response RESULT[1]=0&RESPMSG[2]=OK&AUTHENTICATION_ID[20]=8d4d5ed66ac6e6faac6d&AUTHEN TICATION_STATUS[1]=Y&CAVV[28]=OTJlMzViODhiOTllMjBhYmVkMGU=&ECI[1]=5&XID[28] =YjM0YTkwNGFkZTI5YmZmZWE1ZmY Displaying the ACS Form The Issuer ACS page presents transaction information to the cardholder.
6 Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Transaction Parameters and Return Values z CAVV Is Valid RESULT=0&PNREF=VXYZ01234567&RESPMSG=APPROVED&AUTHCODE=123456&AVSADDR=Y&A VSZIP=N&IAVS=Y&CVV2MATCH=Y&CARDSECURE=Y z CAVV Is Invalid RESULT=0&PNREF=VXYZ01234567&RESPMSG=APPROVED&AUTHCODE=123456&AVSADDR=Y&A VSZIP=N&IAVS=Y&CVV2MATCH=Y&CARDSECURE=N Buyer Authentication Transaction Parameters and Return Values The Buyer Authentication server accepts the parameters listed
Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Transaction Parameters and Return Values 6 TABLE 6.2 Verify enrollment parameters Name Description CURRENCY Required ISO 3-number Currency Code (The code for US dollars is 840) PUR_DESC Optional purchase description Type Max. Length Verify Enrollment Return Values TABLE 6.3 Verify Enrollment response values Name Description Type Max. Length RESULT 0: successful transaction, otherwise error.
6 Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Transaction Parameters and Return Values Validate Authentication Transaction Name-Value Pairs TABLE 6.4 Validate Authentication parameters Name Description Type Max. Length TRXTYPE Z alpha 1 VENDOR Vendor name USER User name PARTNER Partner name PWD Merchant’s password PARES The complete XML PARES message generated by the ACS Validate Authentication Return Values TABLE 6.
Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Transaction Parameters and Return Values 6 TABLE 6.
6 Performing Buyer Authentication Transactions Using the SDK Buyer Authentication Transaction Parameters and Return Values Sale or Authorization Response Value Visa only: In addition to the return values described in Payflow Pro Developer’s Guide, the following value is returned: TABLE 6.7 Buyer Authentication Visa response values 44 Name Value CARDSECURE Visa only. CAVV validity.
Performing Buyer Authentication Transactions Using the SDK ECI Values 6 ECI Values TABLE 6.
6 Performing Buyer Authentication Transactions Using the SDK ECI Values RESULT Values for Transaction Declines or Errors 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. TABLE 6.
Performing Buyer Authentication Transactions Using the SDK Logging Transaction Information 6 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. N O T E : This record is not the official bank statement. The activity on your account is the official record.
6 48 Performing Buyer Authentication Transactions Using the SDK Logging Transaction Information Fraud Protection Services User’s Guide
7 Screening Transactions Using the Payflow SDK This chapter describes the process of 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 Payflow Pro Developer’s Guide. IMPO RTANT: Recurring Billing transactions are not screened by Fraud Protection Services filters. Response Values. Payflow response values are described in “RESULT Codes and RESPMSG Values” on page 45. Testing Filters.
7 Screening Transactions Using the Payflow SDK Transaction Data Required by Filters TABLE 7.
Screening Transactions Using the Payflow SDK Transaction Data Required by Filters 7 TABLE 7.
7 Screening Transactions Using the Payflow SDK Transaction Parameters Unique to the Filters TABLE 7.
Screening Transactions Using the Payflow SDK Existing Payflow Parameters Used by the Filters 7 TABLE 7.2 Parameters accepted by the Payflow server Max. Length Example String formatted as an email address 40 abc@xyz.com Alphanumeric String 3 US, USA, 840 Name Description Type SHIPTOEMAIL Optional. E-mail Address for the shipping contact COUNTRYCODE Optional. Country code of the shipping country. The country code depends on the processor.
7 Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters Shipping Information SHIPTOFIRSTNAME SHIPTOLASTNAME SHIPTOMIDDLENAME SHIPTOSTREET SHIPTOSTREET2 SHIPTOCITY SHIPTOSTATE SHIPTOZIP COUNTRYCODE 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_
Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters z 7 VERBOSITY=LOW: This is the default setting for Payflow Pro accounts. The following values (described in Payflow Pro Developer’s Guide) are returned: {RESULT, PNREF, RESPMSG, AUTHCODE, AVSADDR, AVSZIP, CVV2MATCH, IAVS, CARDSECURE} The following values are specific to Fraud Protection Services: TABLE 7.
7 Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters TABLE 7.4 Medium VERBOSITY parameters 56 Parameter Type Length Description TRANSSTATE Integer 10 State of the transaction.
Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters 7 TABLE 7.4 Medium VERBOSITY parameters Parameter Type Length Description BATCHID Integer 10 Value available only after settlement has assigned a Batch ID. SETTLE_DATE Date format YYYY-MMDD HH:MM:SS 19 Value available only after settlement has completed. N O T E : If you use Nashville, TeleCheck, or Paymentech, then you must use a client version newer than 2.
7 Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters TABLE 7.6 Transaction RESULTs/RESPMSGs(Continued) RESULT RESPMSG and Explanation 128 Fraud Protection Services Filter — Declined by merchant after being flagged for review by filters 131 Version 1 Payflow client no longer supported. Upgrade to the most recent version of the Payflow client.
Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters 7 ption>Total ItemCeilingR16 items were ordered, which is over the maximum allowed quantity of 15Value15(Remove text completely7BillShipMismatch
7 Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters is from: CZ41Hig hRiskFreightCheckFreight Forwarder MatchRHigh riskg freight forwarder(Remove text completely&POSTFPSMSG=Review:More than one rule was triggered for Review&FPS_POSTXMLDATA[682]=
Screening Transactions Using the Payflow SDK Response Strings for Transactions that Trigger Filters 7 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]=2CeilingAmountTotal Purchase Price CeilingR
7 Screening Transactions Using the Payflow SDK Accepting or Rejecting Transactions That Trigger Filters num="10">41HighRiskFreightCheckFreight Forwarder MatchRHigh risk freight forwarder&POSTFPSMSG=Review: More than one rule was triggered for Review&FPS_POSTXMLDATA[682]=1AVS
Screening Transactions Using the Payflow SDK Logging Transaction Information 7 N O T E : This record is not the official bank statement. The activity on your account is the official record. In addition, it is strongly recommends that you log all transaction results (except for check information) on your own system.
7 64 Screening Transactions Using the Payflow SDK Logging Transaction Information Fraud Protection Services User’s Guide
8 Responses to Credit Card Transaction Requests This chapter describes the contents of a response to a credit card transaction request. In This Chapter z “An Example Response String” on page 65 z “Contents of a Response to a Credit Card Transaction Request” on page 66 z “PNREF Value” on page 67 z “RESULT Codes and RESPMSG Values” on page 68 An Example Response String When a transaction finishes, the server returns a response string made up of name-value pairs.
8 Responses to Credit Card Transaction Requests Contents of a Response to a Credit Card Transaction Request 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). Table 8.1 describes the values returned in a response string. TABLE 8.
Responses to Credit Card Transaction Requests PNREF Value 8 TABLE 8.1 Transaction response values (Continued) Field Description Type Length AVSZIP AVS ZIP code responses are for advice only. This process does not affect the outcome of the authorization. Alpha Y, N, X, or no response 1 IAVS International AVS address responses are for advice only. This value does not affect the outcome of the transaction. Indicates whether AVS response is international (Y), US (N), or cannot be determined (X).
8 Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values 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. z z z 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.
Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values 8 TABLE 8.2 Payflow transaction RESULT values and RESPMSG text (Continued) RESULT RESPMSG and Explanation 5 Invalid merchant information. Processor does not recognize your merchant account information. Contact your bank account acquirer to resolve this problem. 6 Invalid or unsupported currency code 7 Field format error. Invalid information entered. See RESPMSG.
8 Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values TABLE 8.
Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values 8 TABLE 8.2 Payflow transaction RESULT values and RESPMSG text (Continued) RESULT RESPMSG and Explanation 113 Merchant sale total will exceed the sales cap with current transaction. ACH transactions only. 114 Card Security Code (CSC) Mismatch. An authorization may still exist on the cardholder’s account. 115 System busy, try again later 116 VPS Internal error.
8 Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values TABLE 8.2 Payflow transaction RESULT values and RESPMSG text (Continued) 72 RESULT RESPMSG and Explanation 133 Data mismatch in HTTP retry request 150 Issuing bank timed out 151 Issuing bank unavailable 200 Reauth error 201 Order error 402 PIM Adapter Unavailable 403 PIM Adapter stream error 404 PIM Adapter Timeout 600 Cybercash Batch Error 601 Cybercash Query Error 1000 Generic host error.
Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values 8 TABLE 8.
8 Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values TABLE 8.
Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values 8 TABLE 8.
8 76 Responses to Credit Card Transaction Requests RESULT Codes and RESPMSG Values Fraud Protection Services User’s Guide
A Fraud Filter Reference This appendix 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).
A Fraud Filter Reference About the Fraud Risk Lists z “Freight Forwarder Risk List Match Filter” on page 87 z “IP Address Velocity Filter” on page 90 Filters Included with the Advanced Fraud Protection Services Option All Basic filters plus: z “Buyer Authentication Failure Filter” on page 84 z “USPS Address Validation Failure Filter” on page 87 z “Email Service Provider Risk List Match Filter” on page 88 z “IP Address Match Filter” on page 88 z “Account Number Velocity Filter” on page 86 z
Fraud Filter Reference Unusual Order Filters A Filters Applied After Processing Most filters are applied to the transaction request before forwarding the request to the processor.
A Fraud Filter Reference Unusual Order Filters Total Item Ceiling Filter What does the filter do? 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. How does the filter protect me? An unusually high item count (compared to the average for your business) can indicate potential fraudulent activity.
Fraud Filter Reference High-risk Payment Filters A 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.
A Fraud Filter Reference High-risk Payment Filters If AVS information is not submitted with the transaction, then the response is NN. TABLE A.1 AVS responses Result Meaning Y The submitted information matches information on file with the account holder's bank. N The submitted information does not match information on file with the account holder's bank. X The account holder's bank does not support AVS checking for this information. (Null) In some cases banks return no value at all.
Fraud Filter Reference High-risk Payment Filters A How does the filter protect me? 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.
A Fraud Filter Reference High-risk Payment Filters TABLE A.3 Card security code responses Result Meaning X Account holder's bank does not support this service. (Null) In some cases banks return no value at all. Card Security Code Failure Filter Action The specified action is taken whenever the card security code response is the value that you specified. The Best Practices action is to review all transactions with responses other than Y.
Fraud Filter Reference High-risk Payment Filters A Buyer Authentication returns one of the following responses in the AUTHENTICATION_STATUS name-value pair (values are for Visa USA region): TABLE A.4 Responses in the AUTHENTICATION_STATUS name-value pair Result Description Liability Impact (Subject to Change) Y Successful authentication—the password was correct. Both Visa and MasterCard shift liability for fraud from the merchant.
A Fraud Filter Reference High-risk Address Filters BIN Risk List Match Filter What does the filter do? The Bank Identification Number (BIN) makes up the first six digits of a credit card number. The BIN 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.
Fraud Filter Reference High-risk Address Filters A ZIP Risk List Match Filter What does the filter do? 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. N O T E : Fraud tends to correlate to densely populated areas like major cities.
A Fraud Filter Reference High-risk Address Filters The specified action is taken whenever the address cannot be validated (it does not exist or is incorrect in some way). N O T E : The filter does not validate that the person named in the transaction data lives at that address or even that the address is currently occupied—only that the address exists in the database. How does the filter protect me? To trick a merchant’s filters, fraudsters sometimes deliberately misspell or make up street names.
Fraud Filter Reference High-risk Address Filters A N O T E : Fraudsters most often use free services at which they do not need to provide traceable billing information. (Free services are also popular among legitimate shoppers— because they are free.) It is therefore a good practice to check whether the billing name appears in some form in the e-mail address. For example, Tina Johnson should have an e-mail address of TinaJohnson@hotmail.com or Johnson42@hotmail.com, or some similar variant.
A Fraud Filter Reference High-risk Customer Filters 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.
Fraud Filter Reference International Order Filters N O T E : Unlike A the Risk lists managed by PayPal, you, solely, manage and update the Bad Lists. 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.
A Fraud Filter Reference International Order Filters States of America, America, and so on) in the country fields. Any other country name triggers the filter. 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 and the difficulty of cross-border legal enforcement against fraudulent activities.
Fraud Filter Reference Accept Filters A Special Requirements z z You must use Payflow Pro client version 3.06 or newer to use the IAVS filter. International AVS is not currently widely supported by processors. Check to see if your processor supports international AVS. – FDMS Nashville and NOVA return IAVS responses for all card types. – EDS Aurora and FDMS South return IAVS responses for VISA cards only. – All other processors always return N or X.
A Fraud Filter Reference Custom Filters IMPO RTANT: The 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. How does the filter protect me? 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.
B Testing the Transaction Security Filters Each example transaction shown in this chapter 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 Details page. In the examples, the critical transaction data is shown in bold red type.
B Testing the Transaction Security Filters AVS Failure Filter AVS Failure Filter "TRXTYPE=A&ACCT=5105105105105100&AMT[4]=1.02&BILLTOPHONE2=650-5550123&BROWSERCOUNTRYCODE=203&BROWSERTIME[22]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=Campbell&COMMENT1=Automated testing from AdminTester&COUNTRY=US&CUSTIP=194.213.32.220&CUSTREF=CUSTREF&DESC=DESC&DL=CA111111&DO B=CA123456&EMAIL[17]=Admin@merchant.com&EXPDATE=1209&FIRSTNAME=John&FREIGHTAMT=1.11&L ASTNAME=Johnson&L_COST0=11.
Testing the Transaction Security Filters Country Risk List Match Filter B "TRXTYPE=A&ACCT=4610251000010168&AMT[8]=$1000.00&BILLTOPHONE2=650-5550123&BILLTOSTREET2=123 BILLTOSTREET&BROWSERCOUNTRYCODE=203&BROWSERTIME[22]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Automated testing from AdminTester&COUNTRY=203&CUSTIP=66.218.71.93&CUSTREF=CUSTREF&DESC=DESC&DL=CA111111&DOB =CA123456&EMAIL[20]=admin@merchant.com&EXPDATE=1209&FIRSTNAME=John&FREIGHTAMT=1.
B Testing the Transaction Security Filters Email Service Provider Risk List Match Filter Email Service Provider Risk List Match Filter Pass in the specified e-mail address. "TRXTYPE=A&ACCT=5105105105105100&AMT[8]=$1000.00&BROWSERCOUNTRYCODE=203&BROWSERTIME[2 2]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Automated testing from AdminTester&COUNTRY=AD&COUNTRYCODE=AD&CUSTIP=172.131.193.25&CUSTREF=CUSTREF&DESC=DESC &DL=CA111111&DOB=CA123456&EMAIL[18]=fraud@asiamail.
Testing the Transaction Security Filters Geo-location Failure Filter B Expected Response Message resp mesg=RESULT=125&PNREF=VB0A25087954&RESPMSG=Declined by Fraud Service&PREFPSMSG=Reject HighRiskFreightCheck !!ERROR 15:43:53 result=125 TRXTYPE=A!! Geo-location Failure Filter Pass in the specified Shipping address, billing address, and IP address. "TRXTYPE=A&ACCT=5105105105105100&AMT[8]=$1000.
B Testing the Transaction Security Filters International IP Address Filter "TRXTYPE=A&ACCT=5105105105105100&AMT[8]=$1000.00&BROWSERCOUNTRYCODE=203&BROWSERTIME[2 2]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Automated testing from AdminTester&COUNTRY=US&COUNTRYCODE=USA&CUSTIP=66.218.71.93&CUSTREF=CUSTREF&DESC=DESC& DL=CA111111&DOB=CA123456&EMAIL[20]=admin@merchant.com&EXPDATE=1209&FIRSTNAME=John&FRE IGHTAMT=1.11&LASTNAME=Johnson&L_COST0=11.
Testing the Transaction Security Filters International Shipping/Billing Address Filter B Expected Response Message resp mesg=RESULT=125&PNREF=VB0A25032282&RESPMSG=Declined by Fraud Service&PREFPSMSG=Reject NonUSIPAddress !!ERROR 14:49:23 result=125 TRXTYPE=A!! International Shipping/Billing Address Filter Pass in a non-US Country code to either the billing or shipping address. "TRXTYPE=A&ACCT=5105105105105100&AMT[8]=$1000.
B Testing the Transaction Security Filters IP Address Match Filter IP Address Match Filter "TRXTYPE=A&ACCT=5105105105105100&AMT[6]=$75.00&BILLTOPHONE2=650-5551234&BILLTOSTREET2=&BROWSERCOUNTRYCODE=203&BROWSERTIME[22]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Test to trigger rules&COUNTRY=US&CUSTIP=172.131.193.25&CUSTREF=CUSTREF&DESC=DESC&DL=CA111111&DOB=CA12 3456&EMAIL[21]=lastName@paypal.com&EXPDATE=1209&FIRSTNAME=FirstName&FREIGHTAMT=1.
Testing the Transaction Security Filters Total Item Ceiling Filter B Total Item Ceiling Filter First, set the filter to trigger on 5 or fewer items. For testing, pass in more than 5 items, as shown here. "TRXTYPE=A&ACCT=3528000000000015&AMT[4]=1000&BROWSERCOUNTRYCODE=203&BROWSERTIME[22]=J uly 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Automated testing from AdminTester&COUNTRY=203&COUNTRYCODE=203&CUSTIP=255.255.255.
B Testing the Transaction Security Filters Total Purchase Price Floor Filter Expected Response Message resp mesg=RESULT=125&PNREF=VB0A25030756&RESPMSG=Declined by Fraud Service&PREFPSMSG=Reject CeilingAmount !!ERROR 13:11:4 result=125 TRXTYPE=A!! Total Purchase Price Floor Filter To test the Total Purchase Price Floor filter, submit a transaction with an amount lower than the trigger amount. USPS Address Validation Failure Filter "TRXTYPE=A&ACCT=5105105105105100&AMT[8]=$1000.
Testing the Transaction Security Filters ZIP Risk List Match Filter B ZIP Risk List Match Filter Pass in the specified ZIP codes. "TRXTYPE=A&ACCT=5105105105105100&AMT[8]=$1000.00&BROWSERCOUNTRYCODE=203&BROWSERTIME[2 2]=July 11, 2002 12:12:12&BROWSERUSERAGENT=BROWSERUSERAGENT&CITY=No City&COMMENT1=Automated testing from AdminTester&COUNTRY=203&COUNTRYCODE=203&CUSTIP=172.131.193.25&CUSTREF=CUSTREF&DESC=DE SC&DL=CA111111&DOB=CA123456&EMAIL[20]=admin@merchant.com&EXPDATE=1209&FIRSTNAME=John& FREIGHTAMT=1.
B 106 Testing the Transaction Security Filters ZIP Risk List Match Filter Fraud Protection Services User’s Guide
C Testing Buyer Authentication Transactions Using the Payflow SDK This chapter describes the process of testing Buyer Authentication transactions using the Payflow SDK. For complete information on using the SDK, see Payflow Pro Developer’s Guide. The content and format of responses to transaction requests are described in “Buyer Authentication Transaction Parameters and Return Values” on page 40.
C Testing Buyer Authentication Transactions Using the Payflow SDK Test Case Descriptions and Account Numbers Account numbers starting with 5 are MasterCard. Numbers starting with 4 are Visa. In the table, VE stands for the Verify Enrollment transaction and VA stands for the Validate Authentication transaction. Test Cases TABLE C.
Testing Buyer Authentication Transactions Using the Payflow SDK Expected Result Codes for Buyer Authentication C Expected Result Codes for Buyer Authentication IMPO RTANT: All returned name-value pairs for transactions with the Buyer Authentication Server include length tags. Length tags specify the exact number of characters and spaces that appear in the value. For example, RESPMSG[2]=OK. The following Result Codes (RESULT return values) are associated with the Buyer Authentication Service.
C Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures TABLE C.
Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures C Verify Enrollment Transaction Test Cases TABLE C.3 Verify Enrollment test cases AUTH_STATUS of Verify Enrollment Transaction Test Case E (Card Eligible for authentication) 1, 2, 3, 6, 7, 8 O (Attempt not available) 4 X (Unable to fulfill request) 5 Example Return Values N O T E : AUTHENTICATION_ID, AUTHENTICATION_STATUS, and ECI should be returned in all cases.
C Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures 1. Construct an HTML page with a form that performs a POST to the ACS Simulator (http://pilot-buyerauth-post.verisign.com/DDDSecure/Acs3DSecureSim/start) The form must contain the following fields (fieldnames are case-sensitive): PAREQ — Copy and paste the PAREQ value from the previous step. TermUrl — The merchant URL to which the reply must be posted. For testing, use: https://pilot-buyerauth-post.
Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures C Step 2 Validate Authentication Transaction Validate Authentication Transaction Test Cases TABLE C.4 Validate Authentication test cases AUTHENTICATION_STATUS of Validate Authentication Transaction Test Case Y 1 N 2 A (Visa only) 3 U 7 F 8 Procedure Direct the Validate Authentication transaction (TRXTYPE=Z) to the test buyer authentication server: pilot-buyerauth.verisign.com.
C Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures Example PARES Value PARES[3648]=eJzdWFmTokoW/isdPW9T0c3iUnLDNiKTXQUrWYU3NllEUUBAfv0kWl1l91TPXeb hTowRBpmHkyfPfr5gbiRlFHF6FFzKaDFXoqry4uhTGn77PAvH4SQKp1MvmEbTnYcf4efF/AVoUX Vj2HD7XjWCzskU0slkGr9sorJKi+OC+kp+pebE9y2RF3F6xNLLIPGO9WLuBWcoqwtq+M2J1938E JUydyfe6Pf9nHg/93IZVhXWtEvDxe1iY9+qorB3DXniHNyDa/OUe3C+zYmBYx56dbSgSXJE0tT4 EzX+bTT6jSTnxI0+Pw3iwKG4YNkUQ0/mxCNljn1SRsfgupiN8ZG33TzqTsUxwhz0nHhbz4l35U7 ecfHP
Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures C Example Return Values The result should look like the following: RESULT[1]=0&RESPMSG[2]=OK&AUTHENTICATION_ID[20]=8d4d5ed66ac6e6faac6d&AUTHEN TICATION_STATUS[1]=Y&CAVV[28]=OTJlMzViODhiOTllMjBhYmVkMGU=&ECI[2]=05&XID[28 ]=YjM0YTkwNGFkZTI5YmZmZWE1ZmY= N O T E : The = character at the end of the XID value is correct (it is the 28th character).
C 116 Testing Buyer Authentication Transactions Using the Payflow SDK Buyer Authentication Testing Procedures Fraud Protection Services User’s Guide
D Deactivating Fraud Protection Services This appendix describes the process of deactivating Fraud Protection Services. Deactivating Fraud Protection Services removes the Security menu and Transaction Review functions (making it impossible to settle transactions). Therefore, before deactivating the service, you must first perform the following steps: 1. Turn off filters so that no new transactions are sent to the Fraud review queue. 2.
D 118 Deactivating Fraud Protection Services Fraud Protection Services User’s Guide
Index Index A E Accepted transactions 20 Account Number Velocity Filter 86 Active mode 15 APIs documentation 49 downloading 49 AUTHCODE 66 authentication status 32 AVS Failure Filter 81 AVSADDR 66 AVSZIP 67 ECI 32 ECI values 45 E-mail Service Provider Risk List Match Filter 88 enrollment requirements 11 B BIN Risk List Match Filter 86 Buyer Authentication examples 37 logging results 47 parameters 40 testing transactions 107 Buyer Authentication Failure Filter 78, 84 Buyer Authentication server 33 Buyer
Index H hacking 13 High-risk Address Filters 86 High-risk Payment Filters 81 I instant fulfillment 14 IP Address Match Filter 88 IP Address Velocity Filter 90 S L T libraries, .
Index Z ZIP Risk List Match Filter 87 Fraud Protection Services User’s Guide 121
Index 122 Fraud Protection Services User’s Guide
