User's Guide
Table Of Contents
- Payflow Fraud Protection Services User’s Guide
- Preface
- Overview
- How Fraud Protection Services Protect You
- Configuring the Fraud Protection Services Filters
- Assessing Transactions that Triggered Filters
- Activating and Configuring the Buyer Authentication Service
- Performing Buyer Authentication Transactions Using the SDK
- Testing the Buyer Authentication Service
- Buyer Authentication Transaction Overview
- Buyer Authentication Terminology
- Buyer Authentication Server URLs
- Detailed Buyer Authentication Transaction Flow
- Call 1: Verify that the cardholder is enrolled in the 3-D Secure program
- Call 2: POST the authentication request to and redirect the customer’s browser to the ACS URL
- Call 3: Validate the PARES authentication data returned by the ACS server
- Call 4: Submit the intended transaction request to the Payflow server
- Example Buyer Authentication Transactions
- Buyer Authentication Transaction Parameters and Return Values
- ECI Values
- Logging Transaction Information
- 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
- Accepting or Rejecting Transactions That Trigger Filters
- Logging Transaction Information
- Responses to Credit Card Transaction Requests
- Fraud Filter Reference
- Testing the Transaction Security Filters
- Good and Bad Lists
- AVS Failure Filter
- BIN Risk List Match Filter
- Country Risk List Match Filter
- Email Service Provider Risk List Match Filter
- Geo-location Failure Filter
- International IP Address Filter
- International Shipping/Billing Address Filter
- IP Address Match Filter
- Shipping/Billing Mismatch Filter
- Total Item Ceiling Filter
- Total Purchase Price Ceiling Filter
- Total Purchase Price Floor Filter
- USPS Address Validation Failure Filter
- ZIP Risk List Match Filter
- Deactivating Fraud Protection Services
- Index
Fraud Protection Services User’s Guide 35
Performing Buyer Authentication Transactions Using the SDK
Buyer Authentication Server URLs
6
Buyer Authentication Server URLs
IMPORTANT:URLs listed here are used only for buyer authentication transactions: Verify
Enrollment (TRXNTYPE=E) and Validate Authentication (TRXNTYPE=Z).
The production Buyer Authentication server URL is buyerauth.verisign.com
Detailed Buyer Authentication Transaction Flow
A buyer authentication transaction involves the following four program calls. Examples of
exact syntax appear in “Example Buyer Authentication Transactions” on page 39.
NOTE: XMLPay uses the VerifyEnrollment transaction for Call 1.
Call 1: Verify that the cardholder is enrolled in the 3-D Secure program
For the Verify Enrollment call (VerifyEnrollment transaction in XMLPay), you determine
whether the cardholder is enrolled in the 3-D Secure program. Send a transaction
(TRXTYPE=E) to the Buyer Authentication server.
The server returns the AUTHENTICATION_STATUS of enrollment (E means enrolled), an
AUTHENTICATION_ID value, and an ECI value (electronic commerce indicator, defaulted
to 7 [Authentication Unsuccessful] because authentication has not yet occurred). If the
cardholder is enrolled, then the message also includes a PAREQ (payer authentication request)
value and the ACSURL—the URL of the Issuer’s ACS (access control server) page at which
buyers provide their password to authenticate themselves. The PAREQ is used in the next call
to ask the Issuing bank to authenticate the customer.
If the cardholder is not enrolled (AUTHENTICATION_STATUS=O), cannot be verified (X),
or an error occurred (I), skip to Call 4, “Call 4: Submit the intended transaction request to the
Payflow server” and submit a standard Payflow authorization or sale transaction that includes
the AUTHENTICATION_STATUS, AUTHENTICATION_ID, and ECI values.