Teacher
Professional
- Messages
- 2,669
- Reaction score
- 828
- Points
- 113
The case with the Belarusian application O! Pay, which allowed us to make payments with the wrong CVV and without 3D Secure, raised many questions - both about the operation of a particular service and, in general, about how the protection of Internet payments is arranged. A commentary on O! Pay is being prepared by the acquiring bank Belinvestbank. With theoretical questions dev.by turned to Alexander Mikhailovsky, the founder and director of business development of IComCharge LLC. His company is known in Belarus as the bePaid online payment service.
On the wrong CVV: was there a code?
Let's start with the basics: what is CVV and why do we need its validation?
This is a kind of password that confirms to the issuer that the request to write off money from his client's card really came from the client. Over time, when it became obvious that this code was no longer a sufficiently reliable guarantee of the authenticity of the cardholder, the 3D Secure technology was invented.
Is CVV / CVC validation required?
Not. The presence of this code is not required for the CNP transaction.
How does CVV / CVC validation work in general? What does it depend on - from the developer, from the acquiring bank, from the payment system?
The need to validate CVV / CVC does not depend on the developer at all: the developer does what the customer tells him. Validation of CVV / CVC depends on the specific situation in which a transaction request is formed from the acquirer to the issuer.
International Payment Systems (IPS) interested in reducing fraudulent transactions strongly recommend merchants to request CVV / CVC from their customers. And as a rule, acquirers require merchants to follow these recommendations.
However, there are situations when CVV / CVC is not requested and not transmitted - for example, with recurrent (repeated) payments. And generally speaking, if the acquirer decides not to send CVV / CVC in the request to the issuer, nothing will prevent him from doing it. If CVV / CVC was requested and transmitted, the issuer informs the acquirer in its response whether the transmitted CVV / CVC coincided with the original code or not. And it is the exclusive right of the issuer to decide whether to approve the payment if the CVV / CVC does not match.
Why don't some services check CVV? Is it expensive or difficult to develop?
CVV / CVC transmission is a standard procedure. Adding another field to the request and handling the response for that field is inexpensive and easy. It is more correct to talk not about services, but about situations or types of transactions when CVV / CVC is not required or you can do without it. Due to the security standards adopted in the payment industry, the CVV / CVC introduced by the cardholder cannot be stored on either the payment processor side or the acquirer side. Hence, situations arise when CVV / CVC may not be transferred (recurrent payments) or when it is not needed.
How else can the issuer be convinced, if not with the help of CVV / CVC and 3D Secure?
There are situations when the acquirer and the issuer are one and the same bank, which, moreover, carries out the identification of the client. For example, in O! Pay when registering a wallet, the user is identified, therefore, Belinvestbank knows that Ivan Ivanov, who registered in the application, is really Ivan Ivanov. Further, if Ivan Ivanov tries to replenish his account at O! Pay with a Belinvestbank card, the latter, even without CVV / CVC and 3D Secure, can check whether this particular card was actually issued to Ivan Ivanov.
Yes, in such a situation the lack of verification is understandable. But in the case of O!, Payments were made without checking CVV from cards of other banks. How can this be? Belarusian issuing banks do not ask for CVV / CVC?
It's hard to say, this question should be addressed to issuing banks. I can only say one thing: CVV / CVC is known only to the issuer, neither the acquirer nor the developer knows anything about it. The developer's task is to accept the code from the client and send it to the acquirer's gateway. The acquirer's task is to generate a request using the Visa and Mastercard protocols and transmit it to the MPS network. And the issuer, who knows what CVV / CVC actually is, gives the answer: did the numbers coincide or not. Why are payments with incorrect CVV / CVC going through? I have two versions. Either the issuer allowed transactions with incorrect CVV / CVC, and then it is on the issuer's conscience. Or the acquirer does not send CVV / CVC.
(Alexander's second guess turned out to be correct. Our employee contacted the issuing bank of the card participating in the testing with a question about an incorrect CVV. The following answer came: “The bank serving this platform did not give us a field containing the value of the CVV code you entered. , accordingly, there was no verification of the CVV-code on our side. According to the rules of the international payment system, we, as an issuer, can authorize the operation even without the CVV-code. For this reason, the operation was successful ").
And what is the benefit to the acquirer not to transfer CVV?
It may be a concern for the convenience of the payers. Accepting payments in e-commerce is an eternal search for a balance between information security and convenience for customers. For example, in many applications, the card can be entered by photographing - the data is recognized by the machine, but CVV / CVC in these cases is not counted, since it is indicated on the back of the card. This practice is not uncommon. For example, the Amazon store doesn't ask for CVV / CVC either - they just don't have such a field.
But there is a field here. And I enter the code anyway!
It can be assumed that in order to simplify payments, the acquirer abandoned CVV / CVC, but the developers did not manage to remove this field: it is there, but the data is not transferred anywhere. But this is just my guess. Only Belinvestbank knows the exact answer.
Why don't issuers reject transactions without CVV?
Hard to say. It is also important for issuers to find a balance between protecting their customers from fraud and the convenience of card payments for them. CVV / CVC is one of the ways to verify the cardholder. But if this code is not passed, there is nothing to verify. However, the absence of the code does not necessarily mean that the transaction is fraudulent.
Maybe it still costs extra money?
Not. At least there is no expense here that would make it economically viable to move away from CVV / CVC. These are standard protocols; specialized software is involved in the formation of requests and processing of responses, which is expensive in itself, but CVV / CVC is included in its basic functionality. Adding a field is also straightforward for developers.
Let's recap this part: Is it okay to not have CVV / CVC validation?
This differs from the generally accepted user verification approaches that are practiced by other e-wallet systems. Usually, a card with CVV / CVC validation and 3D Secure verification is first attached to the wallet, and then all subsequent payments are made as recurrent payments, without any additional checks.
How does the lack of CVV validation affect the security of payments? And at the risk of card fraud?
Of course, the absence of CVV / CVC in a CNP transaction usually increases the risk of someone paying with a card other than their own. The card number and its validity period are easy to spy, remember, and steal. It is more difficult to see the CVV / CVC located on the back of the card. This is why issuers tend to reject transactions in which the CVV / CVC does not match the original.
An exception in terms of risks - if the bank is both the issuer and the acquirer for its own cards, plus it has previously identified the user as its client - in this case, the CVV / CVC check no longer plays a role.
About cardholder name validation: not needed?
Is it normal not to validate the name of the cardholder?
Yes, it is normal.
Nobody ever checks the name?
I could be wrong, but in my opinion the holder name is usually not validated. Again, if anyone can verify it, then only the issuer.
Why then this field?
From the point of view of the processing company, I would say that this field is a kind of source of statistics. If our fraud monitoring system detects two transactions with the same card number, but with a different cardholder name, this is a signal for us that one of these transactions may be fraudulent. Or both. Usually, real cardholders write their real names. If the issuer decides to verify the submitted names and, based on the results of the verification, decides to approve or reject the transaction, this is his right.
Again, as in the case of CVV / CVC, if the issuer has some other way to verify that the transaction was actually initiated by his client, then he does not care what is written in the "cardholder name" field.
About 3D Secure: Why It's Neglected
What is the evidence of the absence of SMS with a dynamic password? That the card or service is not connected to 3D Secure?
SMS with OTP (one time password), in theory, should come to the client from the issuer every time he passes the 3D Secure check. The absence of such an SMS does not necessarily mean that the card does not participate in the 3D Secure program. The issuer may have a banal failure of the verification service. Or the mobile operator may be buggy.
The card is checked for participation in 3D Secure at the time of the payment by contacting the special server of the payment system, under the brand of which the card is issued. MPS answers whether the card participates in the 3D Secure program or not. If involved, the response specifies the URL of the ACS (access control server) of the issuer's server, where the payer is redirected to enter the OTP. If the card does not participate in the 3D Secure program or the ACS server is not available, the authorization request is sent to the issuer.
If the ACS server is available, but SMS does not come due to problems with cellular communication, then after 15 minutes the session is closed and the transaction is automatically considered unsuccessful.
And if the card participates in 3D Secure, but the SMS does not come and the payment is successful, then the payment service does not participate in the program?
Yes, it happens. This means that the acquirer of the service allowed the merchant to accept payments without verifying transactions using 3D Secure. Why did he allow it? Because the merchant somehow guaranteed him compensation for losses on fraudulent transactions. The second possible reason is that the ACS server was unavailable at the time of the payment. In this case, the payment will also be skipped.
Why are some services not connected to 3D Secure? Is it difficult, expensive? How and between whom are payments made for this service?
It is difficult to say why, in each case there is a reason. The use of 3D Secure has already become a standard in the payment industry. International payment systems have created conditions where issuers seek to include all their cards in the 3D Secure program. The fact is that if the card does not participate in this program, then the issuer is responsible for a fraudulent payment on such a card, according to the rules of the IPS. Who wants to lose money?
However, if the acquirer agrees to send the issuer an authorization request for a card participating in 3D Secure without verifying the transaction using this protocol, the responsibility for a fraudulent transaction on such a card is transferred to the acquirer. If the acquirer for some reason is ready to take on such responsibility, he will accept and process payments without 3D Secure.
Does the acquirer save money by agreeing to refuse 3D Secure? Who pays for SMS with a confirmation code?
The issuer pays for SMS, but it seems to me that the costs there are not so big. The acquirer does not save in any way due to the abandonment of 3D Secure - moreover, he risks.
It's simple, it doesn't cost anything, it removes the risks - then what is the point of giving up protection?
To make it more convenient and pleasant for the merchant's customers to make payments, so that they do not depend on SMS. As a rule, refusal is allowed for large merchants - this is not allowed for small merchants.
For the acquirer, the point is to please a large customer. Let's say there is a service that serves large merchants. If a large merchant is convinced that the volume of payments increases by 5-10% without 3D Secure, then, of course, he will want to abandon protection. He signs an additional agreement with the acquirer that guarantees coverage of all bank losses associated with fraud. If the acquiring bank refuses him, it is likely that the merchant will go to other acquiring banks and the entire turnover will go to the competitor.
Since Belinvestbank in the described case is both a merchant and an acquirer (and an issuer for some transactions), the bank's desire to make using the wallet simple and pleasant is understandable.
In a comment under material, you expressed the opinion that the lack of verification is the responsibility of the banks, not the developer. Is there no developer responsibility at all?
We are developers ourselves and have experience in integrating with hundreds of different acquiring banks around the world. The developer does what the API says he receives from the acquirer. It is said in the API to transfer the CVV / CVC value - the developer will request it from the payer and transfer it to the acquirer. But only the issuer can validate this value, and no one else. Accordingly, the developer cannot be responsible for the validation of CVV / CVC. The issuer decides whether to approve a transaction with an invalid CVV / CVC. And the decision on whether to carry out such a transaction is made by the acquirer based on the validation response from the issuer. As well as deciding whether to transfer CVV / CVC to the issuer at all. As you can see, the developer has no influence on anything here.
On the wrong CVV: was there a code?
Let's start with the basics: what is CVV and why do we need its validation?
As with the PIN, it is assumed that the CVV / CVC is known only to the cardholder.
This is a kind of password that confirms to the issuer that the request to write off money from his client's card really came from the client. Over time, when it became obvious that this code was no longer a sufficiently reliable guarantee of the authenticity of the cardholder, the 3D Secure technology was invented.
Is CVV / CVC validation required?
Not. The presence of this code is not required for the CNP transaction.
How does CVV / CVC validation work in general? What does it depend on - from the developer, from the acquiring bank, from the payment system?
The need to validate CVV / CVC does not depend on the developer at all: the developer does what the customer tells him. Validation of CVV / CVC depends on the specific situation in which a transaction request is formed from the acquirer to the issuer.
International Payment Systems (IPS) interested in reducing fraudulent transactions strongly recommend merchants to request CVV / CVC from their customers. And as a rule, acquirers require merchants to follow these recommendations.
However, there are situations when CVV / CVC is not requested and not transmitted - for example, with recurrent (repeated) payments. And generally speaking, if the acquirer decides not to send CVV / CVC in the request to the issuer, nothing will prevent him from doing it. If CVV / CVC was requested and transmitted, the issuer informs the acquirer in its response whether the transmitted CVV / CVC coincided with the original code or not. And it is the exclusive right of the issuer to decide whether to approve the payment if the CVV / CVC does not match.
Why don't some services check CVV? Is it expensive or difficult to develop?
CVV / CVC transmission is a standard procedure. Adding another field to the request and handling the response for that field is inexpensive and easy. It is more correct to talk not about services, but about situations or types of transactions when CVV / CVC is not required or you can do without it. Due to the security standards adopted in the payment industry, the CVV / CVC introduced by the cardholder cannot be stored on either the payment processor side or the acquirer side. Hence, situations arise when CVV / CVC may not be transferred (recurrent payments) or when it is not needed.
How else can the issuer be convinced, if not with the help of CVV / CVC and 3D Secure?
There are situations when the acquirer and the issuer are one and the same bank, which, moreover, carries out the identification of the client. For example, in O! Pay when registering a wallet, the user is identified, therefore, Belinvestbank knows that Ivan Ivanov, who registered in the application, is really Ivan Ivanov. Further, if Ivan Ivanov tries to replenish his account at O! Pay with a Belinvestbank card, the latter, even without CVV / CVC and 3D Secure, can check whether this particular card was actually issued to Ivan Ivanov.
Yes, in such a situation the lack of verification is understandable. But in the case of O!, Payments were made without checking CVV from cards of other banks. How can this be? Belarusian issuing banks do not ask for CVV / CVC?
It's hard to say, this question should be addressed to issuing banks. I can only say one thing: CVV / CVC is known only to the issuer, neither the acquirer nor the developer knows anything about it. The developer's task is to accept the code from the client and send it to the acquirer's gateway. The acquirer's task is to generate a request using the Visa and Mastercard protocols and transmit it to the MPS network. And the issuer, who knows what CVV / CVC actually is, gives the answer: did the numbers coincide or not. Why are payments with incorrect CVV / CVC going through? I have two versions. Either the issuer allowed transactions with incorrect CVV / CVC, and then it is on the issuer's conscience. Or the acquirer does not send CVV / CVC.
(Alexander's second guess turned out to be correct. Our employee contacted the issuing bank of the card participating in the testing with a question about an incorrect CVV. The following answer came: “The bank serving this platform did not give us a field containing the value of the CVV code you entered. , accordingly, there was no verification of the CVV-code on our side. According to the rules of the international payment system, we, as an issuer, can authorize the operation even without the CVV-code. For this reason, the operation was successful ").
And what is the benefit to the acquirer not to transfer CVV?
It may be a concern for the convenience of the payers. Accepting payments in e-commerce is an eternal search for a balance between information security and convenience for customers. For example, in many applications, the card can be entered by photographing - the data is recognized by the machine, but CVV / CVC in these cases is not counted, since it is indicated on the back of the card. This practice is not uncommon. For example, the Amazon store doesn't ask for CVV / CVC either - they just don't have such a field.
But there is a field here. And I enter the code anyway!
It can be assumed that in order to simplify payments, the acquirer abandoned CVV / CVC, but the developers did not manage to remove this field: it is there, but the data is not transferred anywhere. But this is just my guess. Only Belinvestbank knows the exact answer.
Why don't issuers reject transactions without CVV?
Hard to say. It is also important for issuers to find a balance between protecting their customers from fraud and the convenience of card payments for them. CVV / CVC is one of the ways to verify the cardholder. But if this code is not passed, there is nothing to verify. However, the absence of the code does not necessarily mean that the transaction is fraudulent.
When deciding whether or not to approve a payment transaction, the issuer looks not only at the presence or absence of CVV / CVC, but also at other parameters of the transaction.
Maybe it still costs extra money?
Not. At least there is no expense here that would make it economically viable to move away from CVV / CVC. These are standard protocols; specialized software is involved in the formation of requests and processing of responses, which is expensive in itself, but CVV / CVC is included in its basic functionality. Adding a field is also straightforward for developers.
Let's recap this part: Is it okay to not have CVV / CVC validation?
This differs from the generally accepted user verification approaches that are practiced by other e-wallet systems. Usually, a card with CVV / CVC validation and 3D Secure verification is first attached to the wallet, and then all subsequent payments are made as recurrent payments, without any additional checks.
How does the lack of CVV validation affect the security of payments? And at the risk of card fraud?
Of course, the absence of CVV / CVC in a CNP transaction usually increases the risk of someone paying with a card other than their own. The card number and its validity period are easy to spy, remember, and steal. It is more difficult to see the CVV / CVC located on the back of the card. This is why issuers tend to reject transactions in which the CVV / CVC does not match the original.
An exception in terms of risks - if the bank is both the issuer and the acquirer for its own cards, plus it has previously identified the user as its client - in this case, the CVV / CVC check no longer plays a role.
About cardholder name validation: not needed?
Is it normal not to validate the name of the cardholder?
Yes, it is normal.
Nobody ever checks the name?
I could be wrong, but in my opinion the holder name is usually not validated. Again, if anyone can verify it, then only the issuer.
Why then this field?
From the point of view of the processing company, I would say that this field is a kind of source of statistics. If our fraud monitoring system detects two transactions with the same card number, but with a different cardholder name, this is a signal for us that one of these transactions may be fraudulent. Or both. Usually, real cardholders write their real names. If the issuer decides to verify the submitted names and, based on the results of the verification, decides to approve or reject the transaction, this is his right.
Again, as in the case of CVV / CVC, if the issuer has some other way to verify that the transaction was actually initiated by his client, then he does not care what is written in the "cardholder name" field.
About 3D Secure: Why It's Neglected
What is the evidence of the absence of SMS with a dynamic password? That the card or service is not connected to 3D Secure?
SMS with OTP (one time password), in theory, should come to the client from the issuer every time he passes the 3D Secure check. The absence of such an SMS does not necessarily mean that the card does not participate in the 3D Secure program. The issuer may have a banal failure of the verification service. Or the mobile operator may be buggy.
The card is checked for participation in 3D Secure at the time of the payment by contacting the special server of the payment system, under the brand of which the card is issued. MPS answers whether the card participates in the 3D Secure program or not. If involved, the response specifies the URL of the ACS (access control server) of the issuer's server, where the payer is redirected to enter the OTP. If the card does not participate in the 3D Secure program or the ACS server is not available, the authorization request is sent to the issuer.
If the ACS server is available, but SMS does not come due to problems with cellular communication, then after 15 minutes the session is closed and the transaction is automatically considered unsuccessful.
And if the card participates in 3D Secure, but the SMS does not come and the payment is successful, then the payment service does not participate in the program?
Yes, it happens. This means that the acquirer of the service allowed the merchant to accept payments without verifying transactions using 3D Secure. Why did he allow it? Because the merchant somehow guaranteed him compensation for losses on fraudulent transactions. The second possible reason is that the ACS server was unavailable at the time of the payment. In this case, the payment will also be skipped.
Why are some services not connected to 3D Secure? Is it difficult, expensive? How and between whom are payments made for this service?
It is difficult to say why, in each case there is a reason. The use of 3D Secure has already become a standard in the payment industry. International payment systems have created conditions where issuers seek to include all their cards in the 3D Secure program. The fact is that if the card does not participate in this program, then the issuer is responsible for a fraudulent payment on such a card, according to the rules of the IPS. Who wants to lose money?
However, if the acquirer agrees to send the issuer an authorization request for a card participating in 3D Secure without verifying the transaction using this protocol, the responsibility for a fraudulent transaction on such a card is transferred to the acquirer. If the acquirer for some reason is ready to take on such responsibility, he will accept and process payments without 3D Secure.
Does the acquirer save money by agreeing to refuse 3D Secure? Who pays for SMS with a confirmation code?
The issuer pays for SMS, but it seems to me that the costs there are not so big. The acquirer does not save in any way due to the abandonment of 3D Secure - moreover, he risks.
It's simple, it doesn't cost anything, it removes the risks - then what is the point of giving up protection?
To make it more convenient and pleasant for the merchant's customers to make payments, so that they do not depend on SMS. As a rule, refusal is allowed for large merchants - this is not allowed for small merchants.
For the acquirer, the point is to please a large customer. Let's say there is a service that serves large merchants. If a large merchant is convinced that the volume of payments increases by 5-10% without 3D Secure, then, of course, he will want to abandon protection. He signs an additional agreement with the acquirer that guarantees coverage of all bank losses associated with fraud. If the acquiring bank refuses him, it is likely that the merchant will go to other acquiring banks and the entire turnover will go to the competitor.
Since Belinvestbank in the described case is both a merchant and an acquirer (and an issuer for some transactions), the bank's desire to make using the wallet simple and pleasant is understandable.
This is a common story, swindlers in Belarus are prone to strange actions: they steal cards, pay with them in cafes and restaurants, then get caught and go to jail.
In a comment under material, you expressed the opinion that the lack of verification is the responsibility of the banks, not the developer. Is there no developer responsibility at all?
We are developers ourselves and have experience in integrating with hundreds of different acquiring banks around the world. The developer does what the API says he receives from the acquirer. It is said in the API to transfer the CVV / CVC value - the developer will request it from the payer and transfer it to the acquirer. But only the issuer can validate this value, and no one else. Accordingly, the developer cannot be responsible for the validation of CVV / CVC. The issuer decides whether to approve a transaction with an invalid CVV / CVC. And the decision on whether to carry out such a transaction is made by the acquirer based on the validation response from the issuer. As well as deciding whether to transfer CVV / CVC to the issuer at all. As you can see, the developer has no influence on anything here.
