I'm working on a project with a new client and they've had some problems getting a merchant account for processing their online payments due to the business type. The system works in a similar way to Just Eat/Expedia etc in that a customer places on order on the site which is then passed on to the venue, with the site taking a commission.
The client asked if we could store customer payment details in our database (encrypted) and then pass them on to the venue for processing themselves using their in-house card systems. I know there are PCI Compliance issues with this but I've not been able to get a straight answer on exactly what we need to do. I've spoken to a couple of hosting companies and one is saying we need a cluster with separate web and database servers, while another has said we won't. I've never done something like this before, I usually just farm out payment processing to somebody like SagePay etc.
This is the proposed payment flow:
Customer places order on website
Payment details are stored in database
Customer is emailed an order acknoledgement. Venue is emailed an order notification. If venue accepts the order, order and payment details are transmitted for in-house offline processing
Once the venue has taken payment in-house, the order is confirmed and payment details are deleted from the site database
Customer is emailed a final order confirmation
I want to make sure any process is right, and the last thing I want is for the site to be attacked, payment details taken, and be left liable for any losses!
Any advice would be much appreciated.
You failed to include an actual question....
However: PCI compliance is non-trivial; there are multiple levels of compliance, and the standards are a little dense...in general, as long as you don't store payment details, it's relatively easy to comply. If you do store payment details, your compliance requirements become a lot more complex, and may include processes such as vetting employees.
Your intention to transfer payment details to the venues looks like a huge red flag - you're basically giving credit card details to third parties, which I as a consumer would not be happy about, and is almost certainly not allowed within any of the PCI standards.
It's worth talking to a specialist payment gateway provider about the options you have - for instance, most credit card transactions consist of an "authorisation" call, which submits the card details and amount; the service checks the card is good for the money, and "ring fences" the amount on the account, and issues back an authorization code. The actual "settlement" can occur later - up to 10 days for some cards, and can use just the authorization code, rather than the full card details. A specialist payment provider will know what options you have.
It may be possible for you to share the authorization code with your venues, to allow them to take payment (though this would almost certainly require you all to use the same gateway provider).
It would be straightforward to change the flow you mention to include auth/settle logic:
Customer places order on website
Your site issues "auth" using credit card details, store auth code.
Customer is emailed an order acknoledgement.
Venue is emailed an order notification.
If venue accepts the order, you execute the "settle" transaction
You confirm order details to venue
Customer is emailed a final order confirmation
Weekly/monthly/whatever you issue a report to each venue showing amount outstanding and send them a cheque or whatever.
An alternative approach is to take the storage of credit card information out of your hands completely and put the burden on someone else who has the means and expertise to do so while making it easy for you to charge your customers when necessary. Authorize.Net offers their Customer Information Manager API which allows you to create payment profiles for your customers. They handle the storage of the credit card information and give you a payment ID for it. You then can charge against that payment ID whenever necessary without having to have access to the actual payment details.
Related
I have setup a Paypal payment environment, for the purpose of selling a certain service. I used Laravel to setup the API endpoints in the server for the creation and the approval of the order.
Whereas in the frontend, I used the paypal buttons, specifying the aforementioned API URL endpoints for the purpose of creating and capturing orders (onCreate and onApprove parameters of the button).
Everything is working as intended, the order is correctly created and verified before the payment is processed, but there's a small problem. For every new order, I have to go to the transaction log of my business account and manually click "Get your money" in order to actually transfer the funds to the account. (Refer to image with a couple of test payments).
With the increasing number of orders, this becomes a very tedious process. I don't quite understand why it is even implemented this way.
Is there a way to automatically transfer the funds to the account when a new order is made?
Have I made a mistake (or missed something) in the implementation of the payment gateway, or is there a default setting in the business account that I have to change?
Any help is greatly appreciated. Please let me know if you require any additional information.
Thank you in advance
Why is the payment pending? The screenshot does not show the details.
Is it a currency issue? If you don't have a balance of EUR on the account, open one if you want to receive payments as EUR, or change your payment receiving preferences to automatically convert to your primary currency balance.
Is the payment an authorization? If so the integration facilitating the creation of these transactions needs to be changed to create transactions that are of type "sale" or immediate capture, rather than authorizations for later capture.
This might be quite a long read, because there is a bit if relevant back story. Of you just wanted to see the question summarized I have it written at the end.
Edit: I realize hiding the type of business isn't useful, it's a maid/cleaning business.
I'm working with a client where the service they provide is ordered through the website, but the client doesn't have to pay until the service is finished. Because of this the payment is handled through a third party and no payment information is even processed on the website.
The problem is now with the city. While we were in talks with them to obtain a license for the product they said that we could still collect payment the way we want, but we have to store(or have access to) a credit card for each user so we can identify or track them if they break a law (like assault one of our employees on the job or decide not to pay or whatever)
Originally we thought a fully varied phone number would be enough but they are insistent that we need to be able to link a user on the website to a credit card. Even if they choose to pay by cash we need a credit card on record just in the off chance we need to track them later.
Is there a way to do this without holding credit card information on our personal database? When a user makes an account can I ask for a credit card at that point and then just feed it to a service like stripe and just hold it there sort of acting like a second database? If we go through this route is there anything we need to do on our side in regard to PCI Compliance.
Our owner has had a bad experience in the past with bad developers holding credit card data on a server that was not protected and it ended badly so he refuses to hold any card information on our side Also the insurance we have already lined up refuses to back us any further if we hold it in site without professional security measures. Even if we did start to hold credit card information, what exactly do I have to do to make sure it's all secure and up to standard, I've never had to handle this before.
Any suggestions or help would be awesome I'm really stuck here.
TL;DR: City wants us to be able to link a user to a credit card before service is even started, so basically upon sign-up. Owner of business and isurance company doesn't want to save credit card information on our database. I'm not sure how to handle this and make both happy. Do I learn some basic encryption? Can I use stripe or something as a second database?
Edit: To clarify further, I don't want to use any of the information we save, we plan to charge customers differently. The city just wants it on record.
Yes of course there is a solution.
There are companies (Payment processing companies) that are doing exactly this, they charge a fee and offload all of the responsibility from you.
They invest a lot of money to be able to validate all of the security measures required by the law, including PCI compliance.
Those companies are not only offering different payment formats (such as single payment, recurring payments, etc..) but also takes care of storing some data on their side for future payments from the customer.
stripe, 2checkout and authorize.net are only a few of many options to look into.
Don't you ever think about storing any sensitive information (credit card information is only one example) on your own servers, unless you can comply with all security measures required by the law - which is a tiresome and expensive thing to do.
Good luck !
I need to receive payments via PayPal on my website and have used Omnipay (PayPal_Express) to implement it.
I also like my users to have the option to pay with their credit card without having to create an paypal account. In the sandbox this works great (the user has the option to log in or to enter credit card details).
When I switch to live the only options are to login or create an account.
The setting to accept payments without account on the paypal website is set to on
solutionType is set to "Sole"
landingPage is set to "Billing"
My business account is from Austria and has a verfied bank account (but no credit card).
Does anybody know what I can do?
In Live mode, credit card only payment is actually controlled by PayPal risk detection sysem randomly. In order to manage risk, PayPal may limit the Funding Sources available for a transaction. If we limit the Funding Sources, we will alert our users that there is a higher-than-normal level of risk associated with the payment. Such a notice does not mean that either party to the transaction is acting in a dishonest or fraudulent manner. It means there may be a higher-than-normal level of risk associated with the transaction. PayPal employs complex statistical models to identify patterns of behavior. This is similar to the way banks and credit card companies identify patterns of behavior that are out of the ordinary when approving individual transactions. When our system does not allow a certain funding source for a transaction, it is merely an indication that the individual transaction fits a pattern we have observed in the past to have a high risk of failure. In this situation, your customers can only sign up PayPal accounts or log into their existing PayPal accounts to make payments to you.
I need a payment gateway for my php application.I am running a software consultancy and employees are from different parts of the world. I have build an application manage invoices and pay money to them. I need this to be integrated with a payment gateway.
My organization is in USA.
I checked with some payment gateways, but they need seller account for each employee.That is not possible.
My direct requirement is the cash must be transferred from my card/bank account to my employee's bank account . I want to pay through net banking,credit/debit cards,wired transfers,etc.
Please help!!
Thank you
If your requirements are such that the employees need to invoice you first before they get paid, I don't know how you can get around the seller account requirement.
However, if all you're trying to do is simply pay your employees, and manage their invoices through a separate system, something like PayPal could work -- I think really any payment gateway could work if you could push your requirements to the point that you simply pay your employees (one process) and handle client invoices through a second process.
Last time I checked, Paypal lets you transfer to family and friends without their percentage charge, which you could possibly bend to meet your employee payment requirement, if you can offload the invoicing piece to a separate system.
First, you don't tell us enough information about your requirements: do you need support for physical goods ? if so - who's doing the fulfillment ? you can't charge a credit-card until the package was sent which makes things more complicate than most people are aware of.
Second, what you're referring to is called the re-seller model. This model is problematic since all the major credit-card companies in the US recently came up with a new requirement: a merchant that processes more than 100K a year should open his own merchant account! (that's part of PCI compliancy required from the processors).
If all you need is to pay your employees, and being able to do so globally, there's a cool company that does just that called Tiplati.
Disclosure:I work for one of the major payment processing solutions called Bluesnap
I have started working on a e-commerce website. This website will run PHP and MySQL and requires to have a credit system for the users; they will be able to pay with the credit, top it up by vouchers or regular payment, as well as withdraw.
Now I do have experience with credit cards processing APIs, so paying money in and out shouldn't be a problem; what however is a problem is how to securely store the credit information. Storing it as a single numeric field is not exactly ideal and potentially could be exposed fairly easily. What I was thinking is keep all the transactions and credit history of each user in a separate table, and every time they log in recalculate what should their credit be. Same would then apply before any transaction that they attempt to do.
I would like to hear what are your thoughts how this should be implemented.
EDIT: Just to clarify; my question is not on how to process credit cards and won't be storing credit card information. I will use a well known and secure API to process the payments (e.g. via paypal). However based on the credit card payments, I need to attribute the appropriate user points in a form of credit. These points would be a representation of funds on the website (whilst the money would be retained on the company account, until the user tried to make a payment/withdrawl) and would be used to make payments and withdraw funds. Again for the actual payment processing I would use secure API, however I am not sure how to implement the credit points properly from structural point of view in the application itself. I don't want to use a simple one field point system, as that I would consider very dangerous.
I hope that clears it up a bit.
Cheers
This might not be the answer you are looking for but here are my 2 cents.
In my personal opinion unless you have someone monitoring your dedicated servers 24/7 you should never in any format store credit card numbers in your database, it is just too risky.
A very nice solution I came across last year was BrainTree http://www.braintreepayments.com/. You can set up a very nice credit card payment system without taking on any liability yourself. Their API allows server to server and transparent redirect (form posts to their site and they redirect back to your site) transactions. At the same time their Vault service allows you to store credit cards on their end and you just use a token in the server to server API to process a payment. You can store the last 4 digits (which they provide in the transaction detail) in your DB along with the CC type and the token, with this you can display a drop down for the user to select which card they want to use and you just use the token when talking to their API.
The API is very nicely documented with full examples. I think you should look into them.
Edit:
I believe you should have a table as you have suggested to store all the history and 'totals' field in the users table, which can be used to display in various places. Each time a transaction a made calculate the total and cache it in this field for ready usage. However it is a good idea to re-calculate this in certain crucial places to make sure everything is in order. Even though this field is exposed but you have a full log which can help you re-calculate everything if needed.