How PayFacto validates a cardholder's billing address and postal code for card-not-present transactions, the resulting AVS status and return codes, and how each integration mode surfaces the address and postal code fields.
Contents
During a transaction where the customer's card is not presented at the merchant's location (inputType: I or M), the merchant can enter the address corresponding to the cardholder's credit card statement on the payment page.
This validation technique does not eliminate all possibilities of fraud, but it helps ensure that the customer processing the transaction has all of the card's information before proceeding.
The address validation service allows a merchant who accepts orders over the Internet, by phone, or by mail to request that the cardholder provide the address corresponding to their credit card statement. Issuers verify this information in real time to help the merchant ensure that the person making the purchase is the cardholder. If the customer can only provide the 16-digit credit card number and expiration date, they may not be in possession of the card, which could indicate a fraudulent transaction.
During the integration process, the merchant will have the opportunity to choose — between the PayFacto payment solution and the merchant — who makes the decision to cancel the transaction when a verification of the cardholder's address is in error.
Acknowledgment Timing (applies to all three verification methods below)
When a transaction is approved (return code 00), the payment solution cancels the transaction if the merchant does not send the acknowledgment within a period not exceeding 3 minutes after the customer pressed the "Pay" button. This cancellation happens without the merchant's knowledge, and the result is displayed only in the PayFacto payment solution's management console.
CardHolderAddress and CardHolderPostalCode. Both parameter values are required to complete the payment if the option to validate the address is activated for the merchant.AvsStatus. Address verification does not affect the transaction's return code — the transaction can be accepted while the address verification is in error. The merchant then makes a decision using the verification status to accept or reject the transaction.In Case of MATCH Response
The merchant must send the acknowledgment to the payment solution. If the payment solution returns a "TRUE" return code, the merchant must send the acknowledgment; the transaction will not be canceled.
In Case of NO MATCH Response
The merchant must send a non-acknowledgment (NACK) to the payment solution. The payment solution will return a "TRUE" return code. If the NACK succeeds, the transaction will be canceled by the payment solution, which creates a new status in the payment manager (12): transaction canceled by the merchant.
Source Inconsistency Flagged
The source material repeatedly refers to a "TRUE" return code in this section, which doesn't match the numeric return codes (e.g. 00, 9146) used everywhere else in the document, including the "Verification Done by PayFacto" table just below. Reproduced verbatim. [CONFIRM: what does "TRUE" refer to here?]
AVS validation statuses and their associated results when the merchant makes the decision:
Source Inconsistency Flagged
This table's first column is labeled returnCode in the source, but its values are the words MATCH / NO MATCH rather than actual return codes — unlike the equivalent table in "Verification Done by PayFacto" below, which uses real numeric return codes (00, 9146, etc.). Relabeled "Result" here for clarity; original data reproduced verbatim. [CONFIRM]
If the merchant delegates the validation status decision to the payment solution: in the event of a successful transaction with an address validation status for the cardholder that is not advisable (see table below), the PayFacto payment solution will cancel the transaction and return a significant return code. The merchant will have to acknowledge receipt of the transaction.
Correspondence table of PayFacto's payment solution return codes:
The merchant must obtain the address on the client's account during the process of obtaining credit information, then send the information to the payment solution via CardHolderAddress and CardHolderPostalCode. Using partial AVS, the merchant can send only the postal code or only the address of the cardholder. The answer is returned via the response parameter AvsStatus. Address verification does not affect the transaction's return code — the transaction can be accepted while the verification of the address is in error. The merchant then makes a decision using the verification status to accept or reject the transaction.
In Case of MATCH Response
The merchant must send the acknowledgment to the payment solution. If the payment solution returns a "TRUE" return code, the merchant must send the acknowledgment; the transaction will not be canceled.
In Case of NO MATCH Response
The merchant must send a non-acknowledgment (NACK) to the payment solution. The status matches what was sent — see table below. The payment solution will return a "TRUE" return code. If the NACK succeeds, the transaction will be canceled by the payment solution, which creates a new status in the payment manager (12): transaction canceled by the merchant.
If the postal code and address are not transmitted, or do not comply with the specifications in the technical documentation, see the invalid-data return codes in the AVS Result Codes section below.
The changes to the user interface consist of adding two additional input fields (address and postal code) on the credit card payment page. The payment solution offers no restriction as to the means used to indicate the position of these fields. The merchant must make the entry of the field(s) mandatory. In Internet mode, it is preferable to force the entry before processing the transaction.
In call center mode (MOTO): the merchant is entitled to request the address and/or postal code of the customer to proceed with the purchase. The mail application form should include a place for the customer to enter their address and postal code.
PayFacto's payment solution modifies the redirection page to add this new field. In the payment form, the address and postal code entry fields are displayed with the possibility of obtaining more information via an icon. Displaying the input field is optional — it is activated by the payment solution integrators when the merchant terminals have been enabled to support validation and the merchant has completed the changes in their application. When the address and postal code input fields are activated, entering the information is required or the transaction will not be processed. The redirection page will display an error window indicating to the user that they must enter the cardholder's address and postal code.
The option to validate the cardholder's address is not available when the merchant uses the virtual terminal via PayFacto's payment manager.
PayFacto supports Address Verification (AVS) including Visa AVS, MasterCard AVS, Amex AAV, and Discover AVS. PayFacto returns both a mapped PayFacto result code that stays consistent regardless of the payment scheme, and the original payment-scheme-specific result returned from the financial institution, for reference.
If the postal code or address is not transmitted, or does not comply with the specifications in the technical documentation, the returned codes will be:
Each payment scheme returns its own raw AVS result, which PayFacto maps to a normalized PayFacto AVS code. The table below reflects the reference material provided:
Partial Reference Image
The reference image provided is a cropped table that starts at PayFacto code U — the mapping rows for PayFacto codes M, Z, A, and N are not visible in the image and are not included below. [CONFIRM: please provide the full table, or the top rows that were cropped out]
Source Inconsistency Flagged
PayFacto codes L, O, K, D, E, F, and W, shown in the reference image (all Amex-only, name-matching granularity), do not appear in the main AvsStatus table above (which only defines M, Z, A, N, U). Both are reproduced verbatim from their respective sources. [CONFIRM: are L/O/K/D/E/F/W additional valid AvsStatus values, and if so, what return codes map to them?]