I'm a Freelance developer creating a site for a start-up company.
Getting PCI compliant at this time is going to be tough, since the site is still in major development and the funds are quite short.
The situation is this: They want to accept payments on demand in a fast and easy way. This is going to involve punching an id followed by a PIN into a virtual pinpad. This should process the transaction, charge the card, and be done. Because we are not currently PCI compliant, I would like the security to be as follows:
User, in Account Management, can click a link to redirect to the third-party payment processor (We are currently using Authorize.Net). On this page, the user enters their card information followed by email/some form of ID. Their card is saved through this third-party, and the third-party sends us their ID for the user as long as the user email (Or whichever identification used on our end). Now, when the user wants to create a transaction, we send the User ID, our API Key, and the transaction Key used by the third-party as well as the amount to charge. They charge the account and all is good.
Anybody have experience in this? Is this possible? Other solutions are welcome. Again, the company is slightly low on funds, and the transactions are usually going to be ~$10. They are currently working through 100% cash right now and averaging about 30 transactions a day, which is expected to increase drastically over the summer.
Unfortunately, with the new DSS 3.1, you may still need to perform a SAQ A-EP. Part of the requirements for the SAQ A-EP are:
Your e-commerce website does not receive cardholder data but controls how consumers, or their
cardholder data, are redirected to a PCI DSS validated third-party payment processor
Even though your site never takes or processes credit card data, since your site does perform a redirect, that redirect could be changed to point to a malicious site.
Further information can be found in the SAQ A-EP.
Related
I have a client who is dead-set on using PayPal for Credit Card processing. The application must be able to charge cards without the user entering the information every time. Digging around, I've found the Credit Card Vault feature, which would at least let me store credit card information for future use. Unfortunately, as far as I can tell, there's no JS based tokenization procedure in the RoR Paypal SDK gem -- in order to store data in the vault, the information first has to hit my server. Which means I have to provide PCI compliance.
Is there any way to tokenize a credit card for later use in Paypal that will let the token be valid indefinitely?
In the REST API they call it the vault and they have documentation specific to it.
In the Classic API it's called a reference transaction, in which case you would use Payments Pro (DoDirectPayment or PayFlow) to process an original authorization or sale transaction, and then pass that transaction ID into future calls to process payments with the card data PayPal has saved on their server.
If using DoDirectPayment you would use DoReferenceTransaction. If using PayFlow you would just change some of the parameters in the typical request to make it a reference transaction. The doc links above cover all of that.
As long as you aren't saving any card data on your server then the only thing you'll need to be compliant is an SSL certificate on your site, but that's becoming a recommended practice regardless of whether or not you're processing payments.
If you want to completely avoid hitting your server then you'll have to go with Payments Advanced, which embeds a PayPal hosted iframe into your site. I don't think it supports reference transactions, though, and it's a lot more limited than REST or Payments Pro.
I've looked at stripe connect and it forces each user to impute their Social Security number and etc. just so they accept payments for a item they want to sell.
Is there a less painless method where users can sell something on my site, receive monies, and buy from other users?
I tried using stripe alone and it pays me directly. Problem is I want user to sign up, sell something on the site, and get paid. I'm not sure how this can be done without having each user impute social security numbers, tax id, and other personal information if all they want to sell is a pen.
For financial compliance reasons (know your customer laws, anti-money laundering stuff), as well as protecting you from chargebacks and refunds, you'd have to use Stripe Connect and either Standalone or Managed Accounts. Unfortunately this means you'll have to collect certain information from the user like their bank account, date of birth, last 4 of their social, etc.
You can using their Transfers API, but you need to be in the US and so do they. https://stripe.com/blog/send-payouts-with-stripe
I'm currently working on an iOS app where I would like to control the user experience of the entire checkout process when the user is paying directly by credit card. The PayPal iOS SDK doesn't quite fit my use case as it has a baked in ViewController that must be displayed to complete the payment.
The PayPal REST API's appear to allow me to charge a user's card directly but would require my secret key in the process implying it should only be used for some server side flow.
The PayPalPaymentViewController does have an option to take credit card payments directly from the user so I wonder if these services being used to accomplish this are publicly available?
First, I'd be curious as to why the provided view controller is inadequate. The goal is to provide a minimal interface in which to accept credit cards.
But, yes, these services are publicly available. A limited set of functionality (e.g. sale transaction) is possible by omitting the OAuth2 secret.
However, you will still want to verify the transaction on your own server in order to avoid being spoofed by a malicious user.
Don't try to replace the paypal ViewController with anything else, you might run into lots of legal trouble. For example, here in germany, the size and text of the "purchase" button is regulated by law. Paypal's Lawyers have checked the german version of the ViewController for correctness. If anyone, in germany, uses your app, and makes purchases with a different UI, chances are very high that a) the transaction is void and b) german authorities will prosecute you for fraud. Don't risk that.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.
I am developing a rails site that will allow a group of merchants (5 - 10) to accept credit card orders online. I plan on using the Activemerchant gem to handle the processing.
In this case, each merchant will have their own merchant accounts to handle the payments. Storing banking information like that is not something I am a fan of. This could be solved by queing orders and allowing the merchant to log in to the site, input their credentials and process the order.
However, if I go that route then it seems to me that I would have to store the customers' credit card information temporarily until the merchant has the opportunity to log in and process the order, which to me is the greater evil.
Has anyone dealt with this situation? If so, what are the options available and what pitfalls should I look out for? In my mind, security customer credit card information is priority number one with the merchant account information a close second.
When you create the gateway object with ActiveMerchant, you specify the merchant's information. So I'd think that it'd work ok for your sw to place transactions on behalf of multiple merchants. Just keep their information in a db and use as needed. I'd recommend that you encrypt the merchant's information.
See gem attr_encrypted
I'm not sure why you don't want to store the merchant's information. Maybe you should say more about this.
If the merchant is using Authorize.Net, you just need the Authorize.net login and password for each merchant.
I'd recommend that you standardize all of your merchants on a single payment gateway such as Authorize.net or one of their competitors. It's hard enough dealing with one gateway, why deal with more than one. Also, you can easily become a reseller for authorize.net and ease the process for your merchants.
You're right, you really don't want to delay the credit card transactions until a merchant login in and supplies their merchant info:
Depending on how often the merchant logs in, you'd be breaking the merchant's card agreement about timely charges and batching.
You'd have no way to provide speedy feedback to the end customer--did their charge succeed or not?
You'd have to store the complete credit card number and other information. That requires high level of pci compliance. Not worth it. And you are forbidden from storing the CVV number, no matter what. So depending on your other information from the end customer, your charges would have lower qualification (higher transaction costs to your merchants).
My recommendation is to store the merchants' information. -- Encrypt it and do not let a merchant (or anyone else) see it. Only let the merchants replace their info, do not let them see the current info in order to edit it. That will lessen security risk of the wrong person seeing the merchant's info.