User's Guide
Table Of Contents
- Payflow Pro 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
- Freight Forwarder 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
- Testing Buyer Authentication Transactions Using the Payflow SDK
- Deactivating Fraud Protection Services
- Index
Testing Buyer Authentication Transactions Using the Payflow SDK
Buyer Authentication Testing Procedures
C
112 Fraud Protection Services User’s Guide
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.verisign.com/DDDSecure/Acs3DSecureSim/pares
MD — The Merchant Data field: Merchant state data that must be returned to the
merchant. This field is used to accommodate the different ways merchant systems handle
session state. If the merchant system can associate the final post with the original shopping
session without any further assistance, the MD field may be empty. If the merchant system
does not maintain state for a given shopping session, the MD can carry whatever data the
merchant needs to continue the session. Since the content of this field varies by merchant
implementation, the ACS must preserve it unchanged and without assumptions about its
content.
The MD field must contain only ASCII characters in the range 0x20 to 0x7E. If other data
is needed, then the field must be Base64-encoded. The size of the field (after Base64
encoding, if applicable) is limited to 1024 bytes.
If MD includes confidential data (such as the PAN), then it must be encrypted.
2. POST to the ACS Simulator.
(
http://pilot-buyerauth-post.verisign.com/DDDSecure/Acs3DSecureSim/start)
3. The results depend upon the test account number that you used:
– For test cases 1, 2, 6, and 8, the ACS page appears and prompts for a password. The
correct password (password) results in an authenticated user. Enter any other string to
test case 2.
– For test case 3 (attempted authentication of a card that is not enrolled—Visa only), ACS
does not display a page asking for cardholder’s password but directly generates a PAREQ
and POSTs it back to the specified TermUrl.