There are lot of payment gateways (Worldpay, PayPal, ..) offering easy integration, when the plain webpage using URL redirection to the payment page. HTTPS (worldpay,paypal), where the user posts his card details and payment data it is encrypted and trusted.

There are two webpages HTTP and HTTPS (secure) for payment. The user from the non-encrypted HTTP page is redirected to the HTTPS page, using redirect URL like: https://secure.payment.com/pay?to=merchant123&amount=300

The HTTPS page is opened to the user from a normal HTTP page, clicking to a button which opens a new URL. The URL string with its parameters is traveling as plaintext to the HTTPS site. The URL parameter contains the merchant ID and the amount.

The HTTPS (worldpay) displays all the data what is sent via url (so if MITM attack would change, the changed data would be displayed) and the user enters his card details there. This destination page is encrypted, and the user can double-check the payment details. Like paying for who, whats the amount, etc.

The question is, is it secure?

For the feedback, I try to re-edit and clarify more. 2015-04-17 EDIT: "secure enough" = it is trustable, and you can pay without a risk of a hacker steal your money. I'm not sure, isn't an easy hack trick to cheat that kind of system. Btw. this is the way suggested by the 3rd party (paypal, worldpay) payment gateway companies.

http://support.worldpay.com/support/bg/index.php?page=development&sub=integration&c= It states: "All payment processing is handled by WorldPay's secure server, so you and your Shoppers can be confident that their payment details are safe."

support/kb/bg/pdf/rhtml.pdf "The advantages are that nearly all browsers support URL strings, and they are simple to code and to use. However, because the recipient can see all the attributes and values in the URL string, you may not feel it is secure. "

closed as unclear what you're asking by schroeder, RoraΖ, Steve, Mark, M'vy Apr 16 '15 at 7:06

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You don't provide enough details, including what you mean by "secure enough". – schroeder Apr 15 '15 at 16:57
  • It's not clear from your question which pieces are HTTP, which are HTTPS, how the data flows, who stores what data, or anything of the sort. – Mark Apr 15 '15 at 23:02
  • I edited, to be more clear. The data going from HTTP -> HTTPS as plain text. – oupse1234 Apr 16 '15 at 7:23

Such a setup can be trusted, since the payment details cannot be extracted by your hacker and the payment details can be verified securely.

The thing to watch out for is that a lot of user might not bother to double-check the details on the https page, or if there are 'hidden' paramaters sent along that aren't displayed and verified explicitly.


"Secure enough" and "trusted" are risky phrases.

If you're talking about transmitting a credit card number, email address, SSN, or other personal information unencrypted as plain text via a URL parameter then this is definitely unsecure, regardless of where it is going. The page would need to be an encrypted page for that information to be encrypted in transit. If it's not, then anyone in between with a passive listener could pick up that information.

If you're sandboxing you can open a packet sniffer (like wireshark) and check to see what's actually being transferred.

If the page that captures (contains the form) the sensitive information is encrypted it's likely fine.

  1. On the certificate you'll want to check the level they're using for authentication, meaning how many bits of encryption.
  2. You'll want to make sure the certificate they're using is done by a proper third party Certificate Authority so it's not easily spoofed.
  3. Ideally the site would have its own certificate that encrypts the connection for the rest of the form.

If a non-secured page is loading elements from a secured page, then risks with having non-secured content can exist in regard to Javascript or other client-side scripting capabilities. If for example a Javascript is compromised on that page, then it can in theory capture the data from a form using event listeners something like onChange and AJAX prior to the form contents being sent over the secure connection. Javascript could also allow a man-in-the-middle attack that scrapes the contents on transmission via a handler like onSubmit. This really depends on whether the site itself is "secure" enough to not allow injection attacks and things like that.

Often people won't think about things like banner ads which often run Javascript. A banner ad can easily capture data from anything else on the page so long as it has the same permissions. Same goes for client-side plugins depending on the browser.

  • The redirection to that encrypted page is unencrypted. The payment details handled by the official, encrypted page. No sensitive user data sent unencrypted. – oupse1234 Apr 17 '15 at 10:40

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