Is it possible to directly pass card details in the backend and pay using stripe?
Can anyone help me with this?
Any reference doc to build stripe payment from the backend will be much appreciated.
I'm sure it is, but handling card details on the back end means your servers sharing responsibility for handling users' card numbers. It means you are that much more exposed to be hacked. It means that you will therefore need extra vigilance and insurance if you want to be ethical, and might need to be able to prove it both to keep your financial institution happy AND in case of any legal matters.
Not a technical answer, I know, but be sure you realize that part is this isn't a technical question.
I am trying to implement recurring payment in Stripe. I also want to store card information and allow user to edit it. Because sometimes user may want to change card or edit card information. I want this edited/updated card information to be used to process recurring payment. I am using PHP(in Wordpress). Please share some guideline. Thank you.
I created a plugin for this exactly, as well as checking Whether or not they are still valid subscribers, that way you may lock them out of content effectively. I coded it in php.
i wanted to buy some Azure Products online, but i found out that i couldn't choose EC (Electronic Cash - usual payment method in Germany) as a payment method, only Master Card and Visa (tried it on the German version of the site aswell).
so my question is: Is it possible to do so ? or is it defenitely not.
the reason i need reassurence is because if it's not possible i am gonna have to approach my Boss about it (and it would be extremely dumb if it turned out to be Possible).
Thanks a lot in advance!
They can do invoices and different payment methods. http://www.windowsazure.com/en-us/pricing/invoicing/
I have a general question about accepting credit card payements.
Here is my situation:
I have a website which gives the posibility to our clients to publish some adds on it.
The add is first received and checked internaly by an add editor. Then, we are asking the client for the payement and when the payement is received, the add is published.
My goal is to give the possibility to our clients to pay with their credit card.
For example, send them the invoice by email with the link (or button) to a webpage where they could introduce their CC number et all needed information. This page can be created on our website.
I have read some articles about the onLine payement and sow that there is 2 main possibilities:
Use a third party merchant
Use my own merchant account
Which one of those two solutions are better in your opinion, are ther advantages - disadvantages ?
Is there another solution except those two?
What about the solution to use my own merchant account? Complicated to implement ?
Thank you very much.
Unless you have a lot of resources available to comply with the PCI DSS standards ( https://www.pcisecuritystandards.org/ ), use a third party. Much less hassle.
Currently, I'm in the process of hiring a web developer who will be working on a site that processes credit cards. While he won't have the credentials to log into the payment gateway's UI he will have access to the API login and transaction key since it's embedded in the application's code.
I'd like to be aware of all the "what if" scenarios pertaining to the type of damage one could do with that information. Obviously, he can process credit cards but the money goes into the site owner's bank account so I'm not sure how much damage that could cause. Can anyone think of any other possible scenarios?
UPDATE: The payment gateway being used is Authorize.net.
Do they really need access to your production sites?
Don't store the key in your code, store it in your production database, or on a file on the production server.
Some good answers here, I'll just add that you'd probably have some trouble with PCI.
PCI-DSS specifically dictates separation of duties, isolation of production environments from dev/test, protection of encryption keys from anyone who does not require it, and more.
As #Matthew Watson said, rethink this, and dont grant production access to developers.
As an aside, if he can access the API directly, how do you ensure that "the money goes into the site owner's bank account"? Not to mention access to all that credit card data...
If the developer gets access to the raw credit card numbers that can become a bigger problem as your site can be associated with fraudulent activity, assuming the developer is a bad apple. (They could redirect account numbers, CCV, expiration date to another site, though this should be spottable through network tools and a comprehensive code review.)
Does the API perform the "$1.00" charge (or "$X.XX") to verify that a credit card can be charged a certain amount (and thus returning the result to the caller, such as "yes" or "no")? If so, it could be used to automate the validation of credit card account numbers traded on the Internet and abuse of such a system could lead back to you.
With any gateway I have worked with, the payment processor ties the API key to the specific IP or IP range of the site of the merchant. With that said, unless the malicious(?) code in question is executed on the same server as the merchant - there shouldn't be any security concerns in that regard.
If this is not the case for your merchant site - contact them and ask if this is feasible.
Does the payment gateway allow for reversal of charges? If so there is the possibility of a number of scams being run.
Does the site process refunds? Will it ever in the future?
If we're talking about nefarious uses, then the site owner might be investigated if lots of unauthorized purchases are made. How would that affect you if the owner is investigated?
From your description it seems that this developer will have access to the customer cards detail in which case the customers privacy may be compromised. You might consider wording the contract appropriately to make sure that this angle is covered.
However the main point is that if you're working on a sensitive project/information it's better for you to find people you could trust. Hiring a software house to do the job may save you some sleep later on.
First and foremost, it is best that you never store this type of information in plain text. Usually people take this as second-hand knowledge for credit card numbers (Sadly, only because of legal reasons), but any sort of private data that you don't want others with database/source-code access viewing should be encrypted. You should store the account information somewhere in a well encrypted format, and you should provide a test account for your developers to use on their development workstations. This way, only people with server access are able to see even the encrypted information.
This way, you can have a database on the developer's workstation with the test account's API information stored (hopefully encrypted) in it's local database, but when the code is mirrored onto the production server it will still use the live, real gateway information stored on the production server's database without extra code/configuration.
With this said, I don't think that a programmer with API authentication details can do too much. Either way, it's not worth the risk - in my opinion.
Hope this help.
PS: If something bad does end up happening, you can always generate a new key in the web interface on authorize.net after you've taken the precautions to make sure it wont happen again.
In the specific case of Authorize.Net they would not be able to do credits towards their own credit cards since Authorize.Net only allows this to be done on transactions performed through them within the last six months. The only exception being allowed if you are granted an exception for unlinked refunds. If you have signed the proper paperwork for this and someone has your API login and transaction key then can then process credits towards their own credit cards. The only way for you to catch this would be to monitor your statements carefully.
To help mitigate this you should change your transaction key immediately upon completion of the work they perform for you. That would render the key they have useless after 24 hours.