I maintain an internal web app used for customer relationship management (CRM) by company staff (agents and bookkeepers), there are no online sales/purchases all payment processing is done in person with terminals to accept credit card payments. Sometimes there are subsequent payments that have to be processed at later date away from customer.
Here's my scenario:
A staff agent answers a call and requested to take a credit card payment the customer wishes to pay with, but since the agent cannot run the payment through the terminal (only the bookkeeper can) they take a note of the information and give this note to the bookkeeping staff to run the credit card payment on terminal at a later time.
Of course this is an insecure method of transferring credit card information as anyone could see in plain text what is written on the sticky note, including cleaners of the office, etc. When the payment is finally run by the bookkeeper and destroyed in a shredder.
Anyway, I got a request to store this information temporarliy until the bookkeeper runs it and deletes from the database. I can't find specific information about temporary storage and hoping someone can help point me in the right direction or give me a better idea of what the practices should be or if there are third party I can use.
So far what I think is to encrypt the cc data and store in db until the bookkeeper clicks delete in which case it will be removed from the database.
Final note; I am using PHP/MySQL and javascript front end.
Thanks for the help.
If your software handles credit cards in any way and for any period of time, you're in scope for PCI. PCI compliance is kind of a big deal and best left to a 3rd party vendor that specializes in this kind of thing. Storing credit cards even "temporarily" is asking for trouble.
Related
I am currently redesigning a website and looking for a solution on how to add a paid version of the site.
For example, say I have a <select> drop-down box with 20 elements inside. However, I want 15 of these 20 elements to be disabled unless the user has a paid account. At this time, that is the extent of what I need to differentiate between free/paid versions.
I'm planning on adding the ability to register an account and log in, as well as some type of payment processor (recommendations are appreciated for this! - currently looking at using Django/Python). I just don't know how to best go about managing two different levels of the website, and allowing those additional options to paid members.
I'm working with calculators that are pure Javascript. Using Bootstrap for the page design. As far as anything else goes, I'm open.
To do that, you'd have to add a field with a default value of NULL to your database, let's call it "subscription", into your users table. Then, everytime a user login to your website, fetch the subcription value and write it into a session variable. The last thing you have to do to ensure free members aren't allowed to perform any actions the subscribed members can is checking the content of the session variable while :
building your html, or you could check it on the client side with javascript right after the premium element has loaded (this is for user experience only since a client can remove any html attribute whnever they want)
and
while recieving the data of the premium element on the server side, accept it if the user is premium, reject it if they're free (again, just checking the session variable should do the job).
So as you can see, it's much more about preventing free users to gain access at the paid members options than allowing paid members to browse a completly new version of the website designed specifically for them.
I will try to give you a blunt idea maybe this might help you.
So lets say a user has paid for your service you can flag a token in yours app's backend if a particular user is paid or not. So whenever the user logs in your app next time you can get the status of the logged user.
Once you get the status of the logged user you can enable or disable ui elements.
I hope this made some sense.
So i am thinking of using dibs payment
dibspayment
So i found this node wrapper for: DIBS API wrapper for Node.js
However this would require me to send credit card information through a post request to my node server.
My question is: Is this safe? And if not how to i make sure it is safe? So that the request cannot be hacked by unwanted parties
They provide so called "hosted payment window" (http://tech.dibspayment.com/D2/Hosted). In such case all data will be sent directly to DIBS without going to your server. It's preferred solution for the most of applications.
In case if you want to send credit card data to your server you will need to make sure that it can not be leaked (see https://www.pcisecuritystandards.org/). It's a big subject (in general, it's mainly about your server and network infrastructure).
The standard practice for merchants handling CC info, if they do so at all, is (a) encrypted in transit (so unencrypted connections or fallback to unsecure protocols e.g SSL3 must be disabled) and (b) not stored at all anywhere - not in your database, not in any logs; make the transaction and ensure that the full CC info is destroyed or anonymized, e.g. the middle 6 digit replacement with asterisks that you might have seeon often.
The even more common practice is to ensure that you and your systems never ever see full cardholder data, and you delegate someone else to handle the secure processing.
I've not used Dibs, but I have used Stripe..
I assume Dibs will do this the same way. This is because you can't accept credit card details over the internet, unless your company has been accredited, and from what I can gather this can costs thousands..
Basically credit card information is NOT sent to your server, but the Javascript library that comes with say Stripe sends the data directly to Stripe (IOW: bypassing your server), stripe then returns a token, this token is then sent to your Server, and it's this token you then use to debit money etc.
This means that there is never any Credit Card information that is sent between you and your user's browsers. It's an important distinction, because unless your accredited it's illegal to store any credit card information on your server, and this includes in memory storage.
A quick look at DIB's, and it appears it doesn't do it this way. So a word of warning, if you handle CC details you better check your local laws on this, it even say's this on DIB's website..
It is the responsibility of the webshop to comply with current
legislation. If you are unsure if your webshop contains the required
information, please contact your acquirer(s).
Get the above wrong, and depending on what country your from, you could receive a heavy fine, or even worse. :)
Update: like #Peteris has mentioned, DIB's do the hosted option, this then works similar to Stripe, and card details are sent to DIB's, and then DIB's server contacts your site.
I'm new to develop things in JS and i was wandering aroud Stripe techno.
I have a project to make a site where you can buy credits, let's say for 24h, to use for accessing extended functionnality (not a pr0n site :) )
Things i want to do is:
User buys credit (for 24h, 48h, 1 week)
The credits are stackable (if I buy 2x 24h I have 48h)
When user's credit hits 0, sends a command to client side to "close access"
All stack is in JS client side and NodeJS server side.
I have no clue how to develop this with Stripe integration. Does Stripe have a function to do this, or should i use the token they return and build a thing with Redis and EXPIRY keys ?
Thanks for reading and in advance for your answers.
As your business, you need to use 2 features of stripe:
Subscription feature (https://stripe.com/docs/subscriptions/quickstart). It is used to charge your customer in period time you defined. Beside of that, you are able to create a plan for recurring billing.
Events feature
(https://stripe.com/docs/api#events). The stripe system will notify you any events what made changes on your account. Let's say when the subscription of the customer is expired. The stripe system will raise an alert to url you registered to receive the events.
Hope information above will give you more ideas to work on the stripe system.
I am working on a site for a client where purchases are always sent to a third party in Magento CE ver. 1.8.1.0. While doing some style edits, we ran into a deeper issue; all of the shipping addresses are anchored to the account that created the billing information. The initial problem became apparent when dealing with shipping address pre-population in onepage checkout, where shipping was defaulting to the billing address (when tracing the methods calling the name). We could resolve this part on the frontend by repopulating the fields (or depopulating them) with javascript/ajax, however this will still leave an administrative nightmare unresolved on the back end, which will need to be addressed for the clients business model to work as intended. Basically, we need to disassociate the shipping addresses completely with the billing account and assign independent addresses to each purchase rather than keeping them all tied to the origin account, so when whoever is administrating the site has to deal with ongoing business concerns, they don't have to sort through a billion addresses in admin >> customers >> (account) >> addresses to deal with customer issues. Is there any extension that can easily accomplish this, or alternately some hidden core functionality to do so? Writing a custom solution will be difficult on the budget.
I'm setting up a PayPal button to sell my e-book on my website, but one tiny problem. During the process, you have to provide a thank you page and specific download link for the PDF file.
Instead of changing it myself, is there a way to make it automatic and random every time a new customer buys? A script perhaps?
But then the thank you page would be the same, which wouldn't work... so I don't know.
Can anyone give me suggestions on how to approach this matter, please?
Thanks.
Usually the way this is done is when a purchase is completed successfully, a server script coins a unique download ID (usually some long sequence of randomly generated digits), associates it with the person who bought it, stores that info in a database and then puts it in a download link and sends it to the buyer - either in a returned web page or in an email.
The buyer can then click on that link which will take the buyer to your server. The server looks up the unique download ID that is in the URL, checks the database, decides if it's still a legitimate download ID and, if it is, it returns that actual download file to the browser with the right content-type so that the browser does the right thing with the returned data.
Your server can then decide how long it wants to keep that download ID as valid. It can be only for 1-3 uses (allowing for the fact that the legitimate person downloading may have had a glitch and had to redownload it), it can be for only a certain amount of time from purchase or from first download or any other algorithm that you thinks suits your business needs. You can age out old, expired records from the DB either with a chron job or in some regular housekeeping function you call.
Sorry, but I do not know enough about the back-end integration options in PayPal to know how to integrate this into PayPal, but this is the general workflow you probably want. If PayPal generates a unique transaction ID that is random enough for your needs, you might even be able to use that in your URL and database.