I'm a web developer, but I occasionally step over into doing some mobile app development here and there. A client recently asked me to help them develop a very simple app. The app is essentially just an HTML / jQuery form that the user fills out to reserve my clients service. Having heard a lot about phonegap, I decided to try it for the first time, along with jQuery mobile. Everything worked fine with the phonegap build, and after testing both iOS/Android work.

Although, part of the form requires users to enter their Credit Card information, so my client can book them with their own system. The card is never processed through the app, the information is just gathered and sent (via e-mail) to my client who uses their own payment gateway.

Since I used phonegap to build the app, I simply used action="https://www.my-website-with-ssl.php" on the form. Like I said, both iOS and Adroid are sending the e-mails(to my client) fine. But is this even secure?

  • there are far larger issues in play here. Handling PCI (credit card numbers) means that your server now most likely needs to be PCI-DSS compliant to be allowed to handle the information according to the merchant services agreement that your client signed. It sounds likely that there are a fair number of significant risks in this situation which are very strongly not PCI-DSS compliant in this setup as a whole. Jan 31, 2013 at 17:54
  • Thanks for you reply, it sounds like their actual site isn't PCI-DSS compliant then, because it too works off a similar premise. I'm the second web developer to work on their site, and this was the system that was set up before me. It looks like I need to do some research on PCI-DSS compliance, and re-work their current system.
    – SpoonIsBad
    Jan 31, 2013 at 18:37
  • use Paypal or google checkout Sdk's to perform transaction.. else it would be a fraud against the IT policy
    – user52007
    Jul 16, 2014 at 13:01

3 Answers 3


Sending credit card info via e-mail is very bad and likely a violation of their merchant service agreement. Credit card details must be protected in transit and e-mail leaves it flapping in the breeze.

The SSL connection to the server or not for transmitting form data is irrelevant unless the server is somehow encrypting the e-mail to protect it and even then it is really not a very good channel to use compared to storing the information protected in a database (still likely requires PCI-DSS compliance) or simply having it directly relay the user to the payment gateway itself to sidestep compliance issues entirely.

  • So would it be better if I had the CC info sent to a database, and my client then pulled the info from there? The app is only for booking their service. Their software requires them to have a CC number before they can book a reservation, then once the service is completed they are charged through their software they made the booking with.
    – SpoonIsBad
    Jan 31, 2013 at 18:28
  • Encrypted in a database is far more secure as you can control the communication channel far more tightly. Ideally, it should be SSL to the server and then an encrypted connection to the database server and the database should encrypt the values at rest within the DB. The problem is that any system that handles and particularly stores credit card information needs to follow PCI-DSS guidelines and that puts some pretty serious limitations on what the hardware can be used for and how it needs to be configured. In the vast majority of small business cases, it is far better to have the ... Jan 31, 2013 at 19:22
  • 1
    ... merchant gateway handle processing the credit card transaction through an API and then returning a token that links to the transaction in the merchant gateway so that they can interact with that transaction in the future. This sidesteps PCI-DSS requirements since the server never actually handles PCI. Jan 31, 2013 at 19:23
  • @SpoonIsBad - hmm, so is your client using a payment gateway to process the CC transaction or are they forwarding the information to another party for that other party to actually do a charge? If it is just a payment gateway, then the gateway may well have an API available to have the information entered directly. If it is actually another organization that is charging for a service provided and your client is acting as a relay, then they are going to be stuck with PCI-DSS and the requirements for handing off the information to a third party service provider. Jan 31, 2013 at 19:28
  • Thanks for all your help, it's certainly given me a lot to think about/learn! As I've mentioned above, this already in place when I was hired. How it works now is they have an HTML/jQuery form that on submit sends the information in an e-mail using php. I now know, despite having an SSL certificate, this is a bad way of doing things. I will be changing this. Now, what they do with this information once they receive the email is beyond me, so I'll have to get down to the bottom of that. As far as the app is concerned, it sounds like I should keep my fingers crossed for an API I can implement.
    – SpoonIsBad
    Jan 31, 2013 at 20:41

If that form is not embedded in the app and is delivered over an unencrypted channel then it is possible for an attacker to change it in transit to action=https://evil-site.com/carding.php.

Ensure that all communication is encrypted and user data is being validated thoroughly on the server.

To make sure the framework is interpreting the https part you can use an interception proxy to check out the live data. Putting :443 after the domain name could force the connection to only use the secure channel.

A different thing for concern is how safely the PhoneGap framework is using SSL. Classic browsers will prompt users for decisions while frameworks will have default behaviors for those special cases. Things to check for:

  • How PhoneGap deals with self-signed certificates that are usually a sign of communication being intercepted.
  • The same case for expired certificates.
  • In order to check for revoked certificates PhoneGap has to take additional actions such as CRL checking and OSCP server queries.
  • Validating basic constraints. Even iOS was vulnerable to this in 2011.
  • SSL cipher strength used.
  • Thanks for you reply, the form itself is not hosted on the web, it's built into the app. The only time there is a connection to the internet is on submit, when it then runs my php script that is hosted on my website with SSL.
    – SpoonIsBad
    Jan 31, 2013 at 17:13
  • I realized my mistake and updated the answer. Jan 31, 2013 at 17:16
  • Thanks for the update, so if I'm understanding this correctly I should be O.K. My form is embedded into the app, and on submit it runs the php script from my server with SSL. There should be no way for a hacker to change the form action to a different url?
    – SpoonIsBad
    Jan 31, 2013 at 17:20
  • I see no way for a remote attacker to even interact with the app. My concern is how the framework is dealing with special cases such as an invalid certificate that would indicate someone intercepting communication. Jan 31, 2013 at 17:35
  • I'll try adding the :443 to the end of the url and rebuilding the app. Thanks for your help, I'll let you know if Apple rejects or accepts the app.
    – SpoonIsBad
    Jan 31, 2013 at 17:50

DO NOT email credit card info - that's probably a min $500 for your client right there - and it would be your fault for allowing it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .