We have implemented the Card Security Code check when using credit cards.
This produced a value on the attribute security_code_check of passed, failed, unknown.
Balanced state "It's strongly recommended you do not process transactions with cards that fail this check."
However the security code check is not done until an authenticated operation is performed against it the card.
So by the time the check is done we have attempted to process the card. So how do we follow the advice not to use it?
Creating a hold on the Card to do this is wrong and unnecessary. Doing so ties up a customer's available funds and causes confusion.
An authenticated request claims a tokenized funding instrument to a marketplace, which triggers Card verification at the same time. This is discussed in several places in the documentation, chiefly in https://docs.balancedpayments.com/1.1/guides/balanced-js. If you wish to check the CVV result before attempting to charge the card, you should perform an authenticated request on the Card such as a GET, or even associate the Card to a Customer resource. This will initiate the Card verification and provide the ability for you to check the verification results before attempting to charge the Card. Immediately attempting to debit the Card does not provide such an opportunity.
"However the security code check is not done until an authenticated operation is performed against it the card."
An authenticated operation includes performing a GET on the card token returned by balanced.js, which is required to store the card anyway. It is not required to debit the card first.
You would create a hold on the card first. If the CSC succeeds, capture the hold. If it fails, void the hold.
Related
As I know, for EMV cards, before transaction taking place, the terminal perform Card Authentication (using Static Data Authentication or Dynamic Data Authentication) to make sure the card is not a fake card.
(In reverse, it seem that there is no way for POS Terminal Authentication)
In Google Play, there are many applications can read EMV card data.
With a NFC-enable smartphone, we can read the sensitive card information including card number and expiration date.
(And the same for contact EMV card by using a smartcard reader)
My question is:
For EMV cards, is there any standards which specifies 'mutual authentication' protocol between cards and terminals.
And the card only send card data to terminal after performing 'mutual authentication' step.
Thanks,
Nothing to my knowledge. I believe this is so because the business use case does not justify this requirement.
Case 1. As you said there are readers who can read card data. However if at all someone take all the data from the card and replay it on a terminal, since transactions are protected by a single use cryptogram, and unpredictable number is provided by terminal, it will fail.
Case 2. A fraudster after forging a card can get some goods/services and leave, but for the terminal, it has to be registered to an acquirer/bank. There cannot be zombie terminals. Hence it is terminal who want to check the genuineness of the card and not the other way around.
You can get the track/card from chip, but so does mag stripe.
There is nothing like Mutual Authentication in EMV Payment Transaction between Terminal & Card.
Since every transaction is based on some transaction specific unique data & cryptography then cloning is not possible (here I am not talking about SDA cards).
Even though any reader is able to read the data (which is actually allowed by EMV), Since these readers application is not authorized by EMV, so they can't use the VISA/MasterCard servers for transaction processing.
(Extending existing answers with another point of view)
During online transaction card validates that terminal is able to communicate with card issuer -- i.e. that the terminal is able to deliver card-generated ARQC to the issuer and is given a valid ARPC.
As Gaurav Shukla notes in his answer fake terminals are not able to communicate with respective payment association servers.
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
Is there a way to determine if a card stored in Balanced is still valid, without creating a charge or a hold against it?
Unfortunately, there isn't any way to determine if a card is valid without initiating a transaction. Furthermore, even during tokenization while we do offer a series of methods to check a cards validity (e.g. card number, security code, expiration dates) these do not guarantee that transactions made to the card will succeed.
I have a bunch of IAPs in my iOS application, and I have implemented receipt validation for the IAPs.
I'm wondering what error handling I should be doing if the receipt validation request fails.
So, say you have a user who legitimately purchases one of the IAPs, the transaction was successful but the request to verify the receipt fails for whatever reason (e.g. no connection, Apple's server is down). I assume that the user will have been charged because the transaction was successful, but as the validation failed the user will not have been given the content.
What should I do in this situation? I know it might be a rare case but I want to account for it anyway.
I was thinking I could save the receipt to persistent storage and retry the receipt validation in the background until it succeeds. Is this a viable option? Do the receipts remain valid forever or do they expire after a certain amount of time?
I couldn't find much information on this from Apple's documentation so I'm asking you guys.
Thanks in advance
If I am setting up a site how would I go about ensuring that the person who gives me a credit card number (for instance) is the person who is authorized to use it? Maybe more generally how would I go about reducing the opportunity for fraud and stolen ID usage whether it be for a purchase or system access.
I don't work in this field (online purchases) but I would think that authentication of a user has to be a very hard/tricky endeavor.
I would say just stick with the industry standard methods.
Someone is assumed to have posession of the card if they can supply information which verifies with the card payment gateway. As part of that, for example is the Mastercard/VISA 3D auth scheme which adds a passphrase to online payments.
You could try and go further than this 2-factor authentication with fraud prevention, but the credit card companies have more of a vested interest in it so just follow their lead.
Another common method is the address verification system, used by lots of online vendors.