I'm working on designing a credit card payment form whose core functionality is provided by a payment processing company ("upstream").

Upon some transaction errors the upstream returns the detail (*one kind at a time) of the user-provided data that was wrong, for example "Invalid CVC" and "Invalid expiry year."

With this in regard, I have three questions:

  • I would use an even more generic message: "Invalid credit card details. Verify them and try again."
    – ThoriumBR
    Commented Nov 30, 2020 at 13:31
  • Let me guess that your point is that someone with a generated list of card-like numbers can by chance spot some working card numbers. If my card form returns something like "Invalid expiry date or CVC" to one of those numbers, it could blow its cover. Your comment motivated me to also not to disclose whether the card actually exists or not. Commented Dec 2, 2020 at 6:04

1 Answer 1


Isn't this behavior susceptible to OAT-010 Card Cracking by exhibiting CWE-204: Observable Response Discrepancy?

Yes, it would be, if you expose the detailed error messages to the end user.

Why aren't the error messages obscured like login failures? According to OWASP, an application should respond to authentication failure in a generic manner.

The application (you) may need to know the error; the end user does not, which is why the application (you) should respond to the user in a generic manner, despite having been given more detail by the processor.

The card processor is giving you details, in case they're necessary. You are not the end user, you're a trusted partner. You may need those details to debug individual problems.

Should I implement a custom error message obscuring the details e.g. "Invalid expiry date or CVC?"

Yes, you should absolutely return (to the end user) a generic error that doesn't indicate which field was incorrect. And you were right to be concerned about this.

  • Stripe has a public Checkout demo page where you can test how it works. You, as a simulated payer, can receive an incorrect_cvc response by submitting a special test card number which would always result to that particular error. To me, it seems to contradict with your answer to my third question. Could you clarify for me how it is justified? Commented Dec 1, 2020 at 7:00
  • @ChristopherSmith that form and those cards are designed to expose the richness of the Stripe solution to application implementers. They're showing off what the platform can provide to the application - by having the mock application pass detailed information along. It is regrettable that they don't include a disclaimer that the detailed level of information shouldn't be exposed to end users (and, by extension, card brute force attacks) in real-life implementations.
    – gowenfawr
    Commented Dec 1, 2020 at 15:23
  • I see. I personally thought that Stripe's Checkout was okay being like that because they have whatever advanced fraud prevention which is proven to ward off adversaries in an early stage. Commented Dec 2, 2020 at 5:09

You must log in to answer this question.

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