The Balanced documentation (https://docs.balancedpayments.com/1.1/overview/resources/#testing-customer-identity-verification) briefly talks about the fingerprint value returned after performing an authenticated action on a user's Balanced bank account id (which has been generated using balanced.js and posted to the server). I receive the fingerprint value after calling bank_account.associate_to_customer. The fingerprint value, according to the docs, is used "to check if a card has already been tokenized."
After associating this bank account to a customer, do I need to do another check using this fingerprint to ensure this bank account hasn't already been created with Balanced? If so, how is this done?
With Balanced you can actually tokenize the same funding instrument multiple times, however, each token can only be associated to a single customer. To check for the uniqueness of a funding instrument you would simply compare the fingerprints on your end (e.g. if two fingerprints are equal they represent the same funding instrument).
Related
The company I am working at offers a web based calculation tool which has to be paid monthly (a fixed price for a license).
Normally, users go to our website and authenticate themselves with their credentials and then can use the application. When they cancel their subscription they are not able to use the tool anymore, obviously.
Now another company called us because they want to provide our application for their own clients. We have already fixed that they have to pay a license fee for every of their clients. But there is also a restriction: their users should not have to log in on any of our websites (only on the website of our client). But the web application is hosted on our server and is loaded as an iframe.
Now there is that problem that we are not sure whether our client tells us the correct number of people who use our application wherefore we would like to verify that in some way.
One of my ideas is the following:
Our client has to call an API for every users who would like to use our application in order to submit some information like name or an unique ID of that user
When the user would like to access our application, an ID parameter is appended to the iFrame URL
I think that this is not a very good solution because our client could use the same ID for every access and pretend that only one users uses the application. By saving the ip address and id of the accesses it is possible to determine fraud in some cases because ip address will not change frequently.
We even do not have to know WHICH user accesses the application but only the NUMBER of users per month.
I am interested if there is a cryptographic solution where it is hard to cheat. Something like an authentication method which does not require any interaction of the user.
Well you can't. You should require the partner to issue a token for each user so you know they came from the partner.
You could have the partner call an api you expose to issue a one time token for a user and specify user id and IP. You could alternatively have the partner digitally sign such a login request.
If you bill the partner per user, and the partner decitfull he could claim less users.
You can fingerprint the users, you can give long term coockies, you can check IP and fonts installed etc. These will allow you to detect most types of fraud.
If you give a declared userId a cookie and then see him again without it, you assign him a new cookie and then later see the first cookie again while the partner is always declaring same id that is a very strong indicator of fraud.
If I was the decietfull partner I would pair up geographicly close users and merge their IDs. it would look no different from a user with two devices. But this still limits the extent of fraud possible. Two devices per user is plausible. 10 less so.
Find business partners you trust.
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
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 plan on using a service such as Authorize.net to process user's credit cards. Which brings two questions.
Will I need SSL on the payment page even though I will be letting the third part handle most of the processing?
Will I need to get the user's address? And if so, will an apartment number be required? (If they have an apartment, of course)
Yes. The processing will most likely be done through some API that you will call. So getting the information from your users from the browser to your server will require encryption (SSL)
That depends on your set up and what Authorize.net will require.
You DO need to use SSL for your portion of the transaction - you are not PCI-DSS compliant if you do not.
If you are asking about apartment number because you intend to pass it to A.net for AVS anti-fraud checking, AVS only checks the part of the address line before the first space eg: 123 Maple St - only the 123 is checked. The zip is the only other part of the address checked, so there is no reason to worry about apt number. Collect it for your own complete records of course, but it will not affect and AVS check which is the only reeason to give it to A.net in the auth transaction.
It depends on which API you use. If you use any of the hosted APIs (SIM, hosted CIM) you will not need an SSL certificate as you will never be handling any sensitive information on your website.
If you use AIM, ARB, CIM, or DPM you will need an SSL certificate as you will be collecting sensitive information which is covered by the PCI DSS standard.
Yes and no. You are not required to collect it as it is not needed to process a credit card. However, without it you cannot perform Address Verification (AVS) which is a good tool for helping to reduce fraud. It also means your transactions will be processed at a higher rate which is not a good thing.
When a user purchases a subscription, I store the receipt on completed transaction on the server alongside a key to identify the user the receipt belongs to. When the app needs to check if the subscription is still active, it queries the server, the server validates the receipt with Apple and returns info to my app wether the subscription is expired or not.
Now the question is:
When the response returns a latest_receipt/_info field, the server should take that receipt and replace the old receipt for future verifications. What happens if there is a gap in the subscription period (e.g. the user subscribed for 1 month, then cancelled, then subscribed again) or the user changed the subscription type (e.g. from 1 month to 3 moths)?
Will the original receipt still validate, and return a latest_receipt/_info field, or do I need to store a new receipt from the new transaction?
I'm really confused on this auto-renewal thing right now, so I'm not even sure if my validation process is right.
I'm not sure about all possibilities you have to verify receipts and maybe it works your way, but we did slightly different and by that don't face your problem.
We store all the receipts on device-side (note that auto-renews result in new receipts as well). Whenever verification is necessary we post the latest device-stored receipt to server where it is verified by calling iTunes. After that the server responds to device about user's rights.
I think that's the way Apple recommends it (or at least this is how I understood Apple's docs).