I want to collect bank account information from my customers on my website. I would like to do this using a online form, then I will download it to a PC, print it and then delete it from the website. Or eventually send it somewhere externally right after the user submitted the form so customers information is never stored the website.

The goal is to receive the payment information without having to ask the customer to print, fill manually, and send it over fax. And accomplish this without having to use an external payment gateway.

  • 4
    A good thread about that on SO.
    – j0k
    Jul 2, 2012 at 12:18
  • Hi j0k, thanks, but i'd like to mention that it is a dedicated server not a shared one. Jul 2, 2012 at 12:45
  • 1
    In this case It really doesn't matter... this is still highly insecure...
    – Meki
    Jul 2, 2012 at 14:29
  • I endorse the message in the SO thread j0k put forth! stackoverflow.com/questions/596706/…
    – Kzqai
    Jul 2, 2012 at 15:04
  • 1
    I agree - Don't do it. Paying for a professional service should cost you between 3-5%, and it is money well spent.
    – CJM
    Jul 2, 2012 at 15:51

3 Answers 3


Don't do this on your own financial info storage system as it may burn you.

Here are just some of the problems you may encounter:

  • If you collect it online, you will end up storing it online in some format.
  • Your application is not completely secure (none are, so I say that with confidence).
  • Since you are storing the data online, it is accessible via online attack vectors.
  • Due to unforeseen security issues the data may be compromised by a hacker from Russia, the United States, South America or somewhere else more remote... there are lots of smart attackers out there and with online accessibility it is you vs the whole underworld 24/7.
  • Once your data is out, it's out and you have a massive mess on your hands.

To contrast this is what you pay third-party payment gateways for, not just the framework to use and process the data but also the responsibility for properly storing that data or dealing with a security compromise.

I figure that any developer should have used a third-party financial info storage service on at least three projects before they even compare that option with rolling their own solution.


In order to do that, it would be incredibly insecure. Even with HTTPS, banks aren't going to give out account information based off of a name (Or whatever information you request). Third party companies can do this because the banks they are allowed access to scrutinize their system down to the single line for security holes.

Depending on what information you want to pull, I don't know of any language or method to do this, unless you want the certification from banks yourself. The information is stored within the bank itself, and they don't have API's. Another point of interest, there has to be some kind of proof of identity. You could be giving someone's financial information to a malicious party.

If you explained exactly what information you are requesting from the customer and what information you are requesting from the bank, that would help greatly.

  • Hi Christopher, I am not requesting anything from the bank, I am requesting bank account from the customer. Basically I want that information to pass it to the billing department so they can go to the bank and ask charge the customer a monthly fee. So I am not storing anything, I want a online automated mechanism to get that information and pass it to billing. Jul 2, 2012 at 12:45
  • 1
    So is this a mechanism that once the customer enters the information once, it'll save that and pull up every time after that? That's definitely doable, though the main snag with that is what Tchalvak said, security. True, there are no 100% secure systems, but that shouldn't stifle your ambition. Make sure you have an air-tight Privacy Policy and User Agreement, and consult a really good information security expert to secure it the best your budget can allow. Jul 2, 2012 at 17:37
  • 1
    For the mechanism itself, however, I would recommend using SSL and HTTPS to deliver the information to your database, then build a completely separate portal for your billing department to access the information. A sub-domain (e.g. billing.mysite.com) would suffice for the portal (Make sure it's disconnected from your main site). Jul 2, 2012 at 17:39

One option is to create an HTML form that emails the data collected to a secure email address, the email address would only be used for collecting data from the form. And once that data is emailed and printed, you can then delete the email.

  • I was thinking about this option, but I don't know if it is legal. Jul 2, 2012 at 16:03
  • 1
    You would need to encrypt the primary account number before sending it via e-mail (this is a PCI-DSS requirement), and you should still ensure that all of your MTA relays are using TLS. Also, PCI-DSS compliance is required for any organizations that handle credit/debit/cash card information. You need to be especially familiar with these standards if you intend on implementing your own payment acceptance system. At the very least, when you're done implementing it, you need to pay a PCI-DSS auditor to go over your system to make sure you're not endangering your customers. Jul 3, 2012 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.