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.
Related
I have an application that requests Credit Card information to do a payment to a third party company.
My application captures the CC, CVV, Expiration Date, etc. and then passes that information to their API that charges the customer.
I've been reading about PCI Compliance but based on the following image, I am not quite sure what level of compliance I would need to meet.
Lastly, I would like to figure out what would be the best options for me in case I have a new purchase from the same client. Since I am not charging the customer but the third party does, how would be the best way to store the payment information so user doesn't need to enter his information every single time they want to use my service? What would be the implications of storing payment information on my servers from a PCI compliance point of view? Is there a way where I don't need to store the payment information for the user but I can pass their information (if they are a returning customer) to 3rd party API and still being PCI Compliance?
Since you're building a web application (even embedded into Facebook messenger), if you're building out the form that collects card data, you're going to either fall under "Shopping Cart - Payment Page Direct Post" (which is A-EP) or "Shopping Cart - Payment Page Not Outsourced" (which is D-Merchant). You really want to be under A-EP if you can, but you may not be able to.
The difference between the two is whether or not the card data crosses through your servers. With "Direct Post", the web page itself sends the data (usually via HTTP POST) to the payment API, and you have no way to capture it. With "Not Outsourced", the data comes back to your server, which then calls the payment API and passes it along. In that case, you're going to have to go through the entire D-Merchant questionnaire (by far the longest, other than D-Service Provider), and probably have a special environment set up to prevent anything from trying to read the card data as it transits your server.
There's really no part of the card data that is worth storing to try and identify a repeat purchaser, because you won't have the payment data to actually complete a payment. Instead, you should see if your payment provider provides any type of "token", which can be used to identify that payment data later. If so, you can associate that token with the customer (however you identify a customer) and reuse it when they return.
Further reading: https://www.pcisecuritystandards.org/documents/SAQ_InstrGuidelines_v3-1.pdf
(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.
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.
I am implementing a simple server-side verification for Windows 8 IAPs and I'm slightly baffled on how to handle this. Basically what I do know is I verify the receipt using the code that was included in the example
http://msdn.microsoft.com/en-ie/library/windows/apps/jj649137.aspx
In the example, there is a AppReceipt and ProductReceipt. If I understood it correctly, having a simple IAP to buy, for example, gold in the game, I am only interested in the ProductReceipt. However, I don't understand why "AppReceipt" is included here at all. Is the initial app purchase always included in the receipt or is it an optional field?
So an unified way of making sure the user cannot "cash in" the same receipt twice would simply to save the ProductReceipt ID in the back end database? And that this would be a valid approach for both durables and consumables, of which the latter is not yet implemented?
AppReceipt is just an example that you can ignore. In most cases game will send you receipt (ProductReceipt XML) and you will have to verify it on server side.
If you look at: http://social.msdn.microsoft.com/Forums/windowsapps/en-US/8b3cf68d-897d-4a47-ace0-2c42355bf688/protecting-your-windows-store-app-from-unauthorized-use?forum=windowsstore
You will notice:
The ID of each receipt element is unique per user (and device) and you can validate it on your server to confirm that the transaction is legitimate for that user and not a fraudulent transaction. This is especially valuable when your app has its own authentication mechanism because it allows you to validate that each user that appears to have purchased your app is, in fact, a unique customer.
So if you want to, you can extract IDs from this XML.
I am in the midst of trying to find an e-commerce solution for my employer, and it is necessary that we go with a hosted payment page to minimize our PCI compliance woes. After researching several companies' solutions, it seems that they all expect you to submit the total price of the transaction to them via a hidden field or GET variables in order to generate the payment form. This seems like a sizable concern for the merchant, since a user with Firebug (or eyes, in the case of GET variables) could easily modify the transaction total, get a new hosted payment form, and continue with the checkout, thus giving themselves whatever discount they desire.
Has anyone set up a hosted payment page before and dealt with this issue? Any suggestions for a better way to do things?
There usually is a hash submitted with those forms that are generated with secret values that the user won't know (e.g. password, transaction key, etc). So if they tamper with the amount, which is also used in calculating the hash's value, then the payment gateway will reject the transaction. The user cannot bypass this by changing the hash because they do not have all of the information required to calculate it.
So using these hosted forms are safe from abuse. If they weren't they wouldn't be viable products and the gateways couldn't offer them for use.