The client wants a payment page that anyone can browse to, put in their information and id from a previous registration, and make a payment. The problem is that the id is from a different system and I wont have access to the information before hand.

This would be the first time we allow payments without authentication. Is this too risky to becoming exploited? Could people use this for malicious purposed? (Using my page to check whether stolen cards are blocked etc).


  • 3
    Without authentication (user login+password) but WITH TLS (https), right? Commented Mar 7, 2016 at 17:10
  • Of course. HTTPS with a proper certificate. I am just concerned about how someone could spam the page or use it nefariously without accountability (other than logs).
    – Guest1111
    Commented Mar 7, 2016 at 17:36

1 Answer 1


The only problems I can see here is that someone could DDOS by entering random creditcard data, especially if you do not have access to the information and id at the time you accept the payment request. The service handling the payments would have tons of errors afterwards.

Still, realistically, there is no reason for this to happen unless you have someone who wants to damage you. And in this case, its probably also possible to just create an account and do the same. If you have a captcha in place, it shouldnt be a problem.

If the information and ID entered by the users is not checked before payment, there could be problems with assigning payments to the correct person.

But from a security perspective, I don't think that there is a vulnerability for a user entering his data.

  • Thanks. I like the idea of a captcha to prevent all of the garbage requests.
    – Guest1111
    Commented Mar 7, 2016 at 18:03
  • Thanks for the best answer. For the captcha I recommend using ReCaptcha by Google.
    – Alisamix
    Commented Mar 7, 2016 at 18:04

You must log in to answer this question.

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