This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Storing credit card details
I'm working on creating an architecture for a site where users can login and buy products. My boss would like the checkout page to remember the user's credit card info so they don't have to enter it every time, like Amazon.
I don't want to store credit card info in a database for a variety of reasons; I refuse to do it. But my boss insists on the site remembering the user's credit card info.
So, how can this be accomplished? It obviously is being done, unless sites like Amazon are storing user's credit card info and making it extremely secure.
Some companies do indeed store credit card information. If they're responsible, they conform to the Payment Card Industry Data Security Standards. This can be quite expensive, so companies often partner with third parties to handle these transactions.
You could use a service like Authorize.NET's Customer Information Manager CIM. Many other payment gateways offer similar solutions. You store the payment information with them once, then make future requests for payments using a payment profile ID instead of the actual payment information. Another popular company that offers similar services is Braintree Payment Solutions.
Why not encrypt it and make a decryption program that will only allow one CC at a time to be accessed? Maybe something like that would work.
I guess even before that, you have to ask yourself whether or not the user even wants that type of functionality. The only web sites that I might want to keep my CC info stored on are Amazon.com, PapaJohns.com, and maybe one or two others. If you are selling pool equipment, doors, stereo equipment, or something like that, your boss is an idiot.
Related
What is the process of offline payment gateway. I got the one side process from internet.
User will enter first and final 4 digit of credit card and giving cvv code, filling other relevant details then submit.
It will reach to to the admin side, I want to know what is the process happening admin side for receiving and completing the process.
I saw some woocommerce plug in for WordPress, but I didn't clear what is happening in other side.
Thank You
I am going to treat this question as a business logic one more so than a technical one. Based on information provided, I see two possible scenarios:
Scenario One - Storing CC#s for later
You're wanting to collect credit card information to process later via a terminal. Like a POS system inside a store or a web portal where you can type in the information.
This would be very difficult to make compliant with PCI-DSS. The cost of maintaining a PCI complaint system, much less setting it up, tends to be prohibitive except for the largest of companies. You need to use a service, like PayPal, Stripe, Authorize.net, etc etc. Depending on the platform you're developing the website, all major credit card processors should have tools for a simple integration.
Scenario Two - Accepting offline payment methods
This would be a usecase where you want to allow users to pay via mailing a check or some other form of physical payment. This would just mean adapting your shopping / payment experience to allow an option to pay that method, provide a mailing address, and putting a hold on the purchase from processing further until payment is received.
This is what I have based on what was given so far, if I am off base, please elaborate!
I want to set up a consulting service on my blog (WordPress). It would be really simple:
Someone asks me a question
I give them an answer via email (or possibly Skype conversation)
However, I'm having trouble figuring out how to receive payment for such service. I can ask for payment up front using platform like Sellfy/Selz, but that doesn't seems like a good solution.
How would you recommend doing this in the least complicated/most effective way? I'm looking to collect payments by PayPal.
EDIT: It would probably work if there was some kind of an escrow in which case both me (seller) and the buyer would be protected. However, it's more tricky to set it up since we're not dealing with actual products.
you can seperate the auth and capture process with paypal. But i think there are extra fees on this so research it carefully.
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/authcapture/
You can look at getting reference transactions with paypal. They provide you a small deposit before the service. Depending on time of service you can use reference transaction with paypal to charge them the total afterwords. Then if they come back, within 365 days you dont need a deposit if they want to use the same payment method.
I opted for the following solution, which is the simplest in terms of what I'm looking for:
Set up Contact form on the website (someone asks a question)
I write a reply and package it as a downloadable PDF
Set up the reply on a service such as Sellfy or Sellz (with possibly a short preview)
Send notification that reply is available for download
That way, the person only pays once the question is answered and I minimize my risks.
Tip: I'm going to set up a short "Terms of service" to which people agree when sending their question. It will be used as a disclaimer and protection against possible misuse of the system.
We have a client using Volusion as a storefront/e-commerce solution. We need to export purchase data, including credit card information, from it into a fulfillment provider who will then run a customer's credit card only when/if the item they ordered ships.
We have access to the server running IIS, we have the API on the fulfillment provider side to send this data over HTTPS, and we can build a simple polling ASP.Net app that runs on the same PCI-certified server that holds the CC data that moves data from Volusion to the fulfillment provider securely.
What remains is how to get the data out of Volusion. We've had several answers and none have panned out:
Use the API. The API documentation is very light, and doesn't make clear how to get CC data out.
Fill out a verification form and you can "view" it. This came from their customer service department, but they were very shaky on details.
Query the database directly. It's not clear whether this is feasible.
If someone here has handled external credit card processing on Volusion before, we're interested in how to get this done. What the process is to get these fields enabled in the XML API and the format of those fields would be enough, or some other approach - whatever gets us to the finish line.
I am pretty sure that Volusion will not ever release customer's Credit Card information to you via an API or any other means.
maybe this will help you do more research:
http://devwiki.volusion.com/index.php/Customers_Export
http://devwiki.volusion.com/index.php/Orders_Export - the closest you can get is the last 4 of the CC number.
A better design pattern would be to charge the customer at purchase time, if the drop shipper cannot fulfill the order cancel the order and refund the transaction.
You cannot extract the credit card number through the Volusion API. The only way to do it is contact Volusion Support have them enable the displaying of credit card numbers within your Admin. They will probably have you sign a wavier that you will follow PCI compliance.
I am building site for a client in .NET. The site has a monthly subscription service, wherein customer pay for the services with debit/credit card details. Money will be deducted from the account regularly. Customers can cancel the subscription service at any time and the collection should be stopped.
Is there any service that I can use to accomplish this?
Any information on how to go about developing this will be much appreciated.
Thanks in advance.
If you want to outsource the entire billing system (which is certainly advisable, as they can be an extremely complex distraction), I would recommend working with a company like http://spreedly.com/ or http://chargify.com/, who do exactly this and provide an extremely simple API (especially compared to PayPal) to integrate with your .NET app.
Bear in mind that with these solutions you still need to bring your own payment processor and merchant bank account.
PayPal is ideal for this. See:
https://www.paypal.com/en_US/ebook/PP_NVPAPI_DeveloperGuide/Appx_SDKDotNET.html
Most payment processors I have worked with support recurring payments. This means that you don't have to store the credit card information. Typically you just store a reference to the credit card and just send the process the amount and the reference number to complete the transaction after the initial payment.
This is one of the companies I have worked with and their details of how recurring payments work. PayPal also does recurring payments.
Can i suggest you review all the other posts on SO regarding monthly payments? This search does bring back a number of questions that may be of help to you (it also brings back a few non related ones, just ignore those :)
If the merchant account is US based you should consider Authorize.Net's Automated Recurring Billing API. It handles the subscriptions for you and has a very easy to use API. They offer working sample code to get you started.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
At the moment it seems that most webapps store their user-data centrally.
I would like to see a movement towards giving the user total access and ownership of their own personal information and data; ultimately allowing the user to choose where their data is stored.
As an example - with an application like facebook, the user's profile data could exist on any device that they own (e.g. their mobile phone) ... facebook would then request the data from the user, and make use of it.
Does anyone see this idea becoming a reality? Is it a ridiculous idea?
CLARIFICATION:
The information would at least need to be cache-able. The motivation behind the idea was to give the user more control over their own data - the user is self-publishing an
authoritative version of what they are happy for the world to see.
I'm imagining a future which is largely dictated by choices which are made now. Perhaps physical location of the data isn't actually important - and is more a symbolic gesture... but I think that decoupling the relationship between our information and the companies that make use of it could be a positive thing.
But perhaps, the details do need a bit more work ;)
What's with performance? Imagine you want to search for data that is located on hundreds of mobile phones or private distributed systems.
what your describing is simulator to a combination of OpenID Attribute Exchange, Portable Contacts and OpenSocial. Having one repository of user data that every other provider would feed off. Its nice for a user but I would not go so far as to tie it to a specific device. Rather a federated identity that you control from one vendor's website/application.
I am with you on this one.
And I think the key technology might be RDF. Since protocols such as F.O.A.F. are already used in these social applications, it is a small step from $Facebook storing your RDF Graph, to you storing it yourself, and saying: This is me, these are my friends, or anything else you might want someone to know.
This approach might be globalised to other personal information you might ened an authorised party to know, like Health Records.
There are quite a few conceptual problem with what you are suggesting.
Firstly, everytime you reconnected to the system, you would need to upload your personal information back into the system so that it could interact with you. This adds quite an overhead to the signin/handshake/auth with the remote system.
Secondly, alot of online systems (particularly online communities) rely on you leaving an online profile of yourself so that other users can interact with you (via your profile) when you yourself are offline. This data would have to be kept somewhere central.
At the very least, the online system would need a very basic profile to represent you, so that you could login & authenticate against... which sounds like a contradiction to what you are suggesting.
Performance would suffer should the user have physical possession of the data; e.g., thumb drive, local drive. However, if a "padded cell" solution were possible where the user has complete rights to a vault that the application could reach quickly, then there might be a possibility.
This really isn't a technology solution, rather one of corporate policy. Facebook could easily craft a policy that states that your records are yours, just like a bank should. They just don't. For that matter, many other institutions who are supposed to guard our personal information - our property if I can evoke John Locke - but fail miserably. If they reviewed their practices for violation of policy and were honest, you could trust. Unfortunately this just doesn't happen.
The IRS, Homeland Security and other agencies will always require that an institution yield access to assets. In the current climate I can't see how it would be allowed for individuals to remain in physical possession of electronic records that a bank or institution would use online.
Don't misinterrpret me - I think your idea is a good one to pursue, but it's more of a corporate policy issue than a technical solution.
You need to clarify what you mean by ownership. Are you trying to ensure that the data is only stored on your own devices? As others have pointed out, this will make building social networks impossible. You would disappear from Facebook when you weren't connected to it, for example.
Or are you trying to ensure that a single authoritative copy exists and that services defer to it? This might be more possible, and would require essentially synching the master copy on your cell phone with the server when possible.
Or are you trying to ensure that you can edit/delete your account at any time? Most sites already work like this.
The user still wouldn't be sure they 'own' their data, simply because they'd have to upload it every time they connect, and the company it's being sent to could still do whatever it wants with it. It could just not display your profile when you're not online, but still keep a copy of it somewhere.
Total access, ownership and location choices of personal information and data is an interesting goal but your example illustrates some fundamental architecture issues.
For example, Facebook is effectively a publishing mechanism. Anything you put on a public profile has essentially left the realm of information that you can reasonably expect to keep private. As a result, let's assume that public forums are outside the scope of your idea.
Within the realm of things that you can expect to keep private, I'm a big fan of encryption combined with physical and network security balanced against the need for performance. You use the mobile phone as an example. In that case, you almost certainly have at least three problems:
What encryption is used on the phone? Any?
Physical security risk is quite high - have you ever had an expensive portable electronic device stolen? There seems to be quite the stolen phone market out there....
The phone becomes a network hotspot - every service that needs your information would need to make an individual connection to your phone before it could satisfy a request. Your phone needs to be on, you need to have a sufficiently fat data pipeline, etc.
If you flip your idea around, however, it becomes clear that any organization that does require persistent storage of your sensitive private information (aka SPI) should meet some fundamental (and audit-able) requirements:
Demonstrated need to persist the information: many web services already ask "should I remember you?" or "do you want to create an account?" I think the default answer should always be "NO" unless I say otherwise explicitly.
No resale or sharing of SPI. If I didn't tell my bank or my bookstore that they can share my demographic information, they shouldn't be able to. Admittedly, my phone number and address are in the book, so I can't expect that I'll stay off of every mailing list but this would at least make things less convenient for the telemarketers.
Encryption all the time. My SPI should never be stored in the clear.
Physical security all the time. My SPI should never be on a laptop drive.
Given all of the above, it would be possible for you to partially achieve the goal of controlling the dissemination of your SPI. It wouldn't be perfect. The moment you type anything in, there is immediately a non-zero risk that someone somewhere has somehow figured out to monitor or capture it. Even so, you would have some control of where your information goes, some belief that it would only go where you tell it to go and that the probability of it being stolen is somewhat reduced.
Admittedly, that's a lot of weasel words in a row....
We are currently developing a platform to allow people exercise the right to access their personal data (habeas data) against any holder of such data.
Rather than following the approach you suggest, we actually pursue a different strategy: we take snapshots of the personal data as it is in the ddbb of the "data holder" whenever the individual wants to access her data.
Our objective is to give people freedom in the management of their own personal data, allowing them to share it with others based on their previous consent.
I would like to further discuss with you should you be interested.
Please read Architecture Astronauts.