How the credit card verification code (the 3-digit security code printed on the back of Visa and MasterCard cards) is collected, validated, and returned across integrated, redirection, virtual terminal, Internet, and call centre (MOTO) transaction modes.
Version: v1.0 | Last updated: 2026-07-03
Contents
This code is not found on the magnetic stripe, making it impossible for the defrauder to copy the magnetic stripe or to learn the card's verification code. This code is not embossed on the credit card either (characters engraved in the card), so it is impossible to trace the card to obtain the code.
MasterCard and Visa: the code is located on the back of the card and follows the number of the card printed on the front. The code is comprised of three numbers.
This validation technique does not entirely eliminate the risk of fraud, but it can help ensure that the client making the transaction has all of the card information before proceeding.
When carrying out a transaction in which the client is not in the presence of the point-of-sale terminal operator (Internet or MOTO), the merchant follows one of the flows below depending on the integration mode.
If Accepted
The merchant must send the acknowledgement of receipt (ACK) to the payment solution. The payment solution issues a return code to the merchant once the ACK has been received. The transaction will not be cancelled.
If Declined
The merchant must send a negative acknowledgement (NACK) to the payment solution. The payment solution will issue a return code. If the NACK is successful, the payment solution will cancel the transaction and create a new status in the management tool: cancelled by the merchant.
The redirection process will not change the page, so the client will not see the redirection page on the payment solution servers. The payment page displays the verification code input field as well as the instructions to visually locate the code on the various cards.
When the transaction is being processed and if it is successful, the payment solution servers will redirect to the merchant's success page. The merchant must obtain the response by using the session identifier. During the integration process, the merchant will be able to choose who — between the PayFacto solution and the merchant — will make the decision to cancel a transaction when there is an error in the verification code validation status.
The payment solution returns a verification status to the merchant with the transaction response. The verification of the code does not influence the transaction's return code — the transaction can be accepted even when there is an error in the verification code. It is up to the merchant to determine what action to take next depending on the status returned. The merchant makes a decision using the verification status to accept or decline the transaction.
If Accepted
The merchant must send the acknowledgement of receipt to the payment solution. The payment solution issues a return code to the merchant for the ACK. The transaction will not be cancelled.
If Declined
The merchant must send a negative acknowledgement (NACK) to the payment solution. The payment solution will issue a return code. If the NACK is successful, the payment solution will cancel the transaction and create a new status in the management tool: cancelled by the merchant.
If the transaction is successful with a validation code status that is not recommended (see the equivalency table below), the PayFacto solution will cancel the transaction and issue a substantive return code corresponding to the validation code — no verification code is required from the merchant in this case. The merchant must acknowledge receipt of the transaction.
The following is the equivalency table for PayFacto solution return codes with non-recommended statuses:
If the verification code does not meet the specifications in the technical documentation, the code returned will be 9121, regardless of who makes the decision.
ACK/NACK Timeout
Currently, if the merchant does not send the acknowledgement of receipt (ACK) or the negative acknowledgement (NACK), the payment solution will cancel the transaction after three minutes have passed since the client pressed the Pay key. This cancellation is made without notifying the merchant, and the result is displayed only on the PayFacto solution management console.
The changes to be made in the user interface consist of adding an additional input field (intended for the three-digit verification code) on the payment-by-credit-card page, as well as clear instructions for the client indicating how to locate and identify the verification code on the credit card. The payment solution has no restrictions regarding the method used to indicate the position of the verification code. Depending on its business rules, the merchant can make the input field mandatory.
In Internet mode, it is preferable to require the input before processing the transaction. The PayFacto solution recommends inputting the validation code.
The merchant has the right to request the credit card's verification code to proceed with the purchase. During the conversation, the call center agent must properly guide the user so they can locate and identify the verification code on the card. The mail request form should include a space for the client to record the verification code along with clear instructions to help the client locate and identify the code.
The PayFacto solution has modified the redirection page to add this new field. Displaying the input field is optional — it is activated by the payment solution integrators when the merchant terminals have been activated to support the validation and the merchant has completed the changes in the application. When the verification code's input field is activated, the code must be entered or the transaction cannot be processed. The payment solution's redirection page will display an error window indicating to the user that the verification code must be entered.
The payment solution offers validation for Internet and MOTO merchants. Merchants in point-of-sale terminal (POS) mode are not affected by this change. Once integrated, the merchant will have the choice between a sale with or without a verification code. If the code option is selected, the page displayed will have an additional field to enter the code together with instructions to help the client locate the code on the credit card.
Important
Merchants must never, under any circumstances, store the verification code in their databases. The PayFacto solution does not store this value in its payment history. If the verification code is available, it must be provided in the payment request. Web services users must use the new WSDL. The verification code value will not be returned in the response to the merchant — a new field will be added to the payment solution's response for the validation status instead.
The following are the possible values returned by the payment solution:
Source Inconsistency Flagged
The Introduction and Advantages/Disadvantages sections above state the code is a 3-digit value found only on Visa and MasterCard, and that American Express is not supported. The return-value table, however, includes a value Y for a "4-digit code matched" result. Reproduced verbatim from source. [CONFIRM: under what circumstance does a 4-digit code apply, given Amex is stated as unsupported?]
Important
The verification code's validation status does not influence authorization of the transaction. If the transaction is not authorized, no validation status will be returned to the merchant. The card issuer can decide to deny the transaction in the event of an erroneous verification code. Some issuers authorize transactions with N, P, and U return codes; others will simply deny authorization.
The verification code entered must be provided upon sending, or when the Web service is called. When the purchase transaction is entered, there are two additional parameters. For Web services, a new WSDL is published and the parameters are taken into account in the new transaction. The merchant must add the input of the verification code into its Internet or MOTO applications — the current payment application must be modified to add the verification code to the beginning of the transaction. The sending of the transaction itself remains unchanged.
When the merchant obtains the parameters in response to the transaction, a verification code validation status will be added. Based on this status, the merchant will have to acknowledge receipt to complete the transaction, or use a new function that issues an acknowledgement of receipt to the payment solution but with a warning to cancel the transaction (the NACK transaction). The synopsis of the NACK function is similar to the ACK function; the difference is that the function's success indicates that the transaction will be cancelled at the merchant's request (statuses 10, 11, or 12 in the payment solution management console).
The payment solution provides the client with this option on the redirection page. The session creation procedure and redirection to the payment page remain unchanged. If the merchant chooses to process the verification code's validation status, the change will be on the successful transaction page (transaction authorized). When the merchant obtains the parameters in response to the transaction, a verification code validation status will be added. Based on this status, the merchant will have to acknowledge receipt to complete the transaction, or use a new function that issues an acknowledgement of receipt to the payment solution but with a warning to cancel the transaction (the NACK transaction).
The synopsis of the NACK function is similar to the ACK function; the difference is that the function's success indicates that the transaction will be cancelled at the merchant's request (status 10 in the payment solution management console).