0

I'm using PayPal's Website Payment Standard in my ASP.NET website.

What I do is when the user clicks on the "Pay Now" button, I do the following in the codebhind:

  1. DB status changes
  2. Generation of the PayPal form, hidden fields for the items
  3. Call ScriptManager.RegisterClientScriptBlock() to call the javascript function that submits the PayPal form to PayPal.

I'm worried that the user can press stop on the web browser and then edit the values in the hidden forms and then submit the form. Is there a way to prevent this? Or a better alternative?

Thank you so much in advance!

Lob City
  • 87
  • 8

2 Answers2

3

I haven't done PP Standard. I've used Gateway and Pro/Express Checkout but its been quite a while - still, your question can be handled in a more "generic" way...

Unfortunately your plan will not do anything to protect you - just like any other HTML Form on the web, HTTP requests and responses can be inspected and tampered with using readily available tools.

The common way to prevent tampering is to do server-side validation of submitted values coming from any client/browser (the rule of thumb is "trust no one"). In your scenario, you are doing things on the server side, but that's still prior to the actual submission target of the data - which is PayPal. The step that actually sends the data to the "target" is still the browser/client - and there lies the issue so to speak. The data to be validated is meant for a system other than yours (so you can't validate for PayPal).

Unless there is an added layer of security, e.g. signature or encryption, it will always be vulnerable to tampering (viewing is a foregone matter, it can be viewed).

I don't believe (but I could be wrong) PP Standard has a server-to-server option for POSTing data. This would effectively "hide" the data altogether from the client/browser - nothing to see, nothing to tamper with. Data transfer is in the background - client/browser knows nothing of it.

However, their PayPal Payments Standard and Button Manager API seems to be the right/secure way of doing this.

In essence you will be creating what they call "encrypted buttons" on the fly. This way the data will look like gibberish to anyone inspecting it - it will only make sense to PayPal because they can decrypt the data accordingly. That's how the data is secured/protected from tampering (not viewing - but again, what can be seen is gibberish)...

Hth...

Update:

Also, you should consider PayPal IPN for storing data. You are making the assumption above (I think) that everyone who clicks the button will actually go through with the payment (or can pay successfully). With IPN, you will "listen" for data coming from PayPal only after successful payment (which is where you should store order related data and/or inventory updates, etc.) ....

EdSF
  • 11,753
  • 6
  • 42
  • 83
0

Even though I'm working with PHP, using the NVP API you can get links to redirect using a token which can only be used by paypal. All the links will look like https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=TOKEN, where TOKEN is a token retrieved previously by calling the PayPal API.

I've only developed it for ExpressCheckout. You can check the API here:

https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_reference

Lumbendil
  • 2,906
  • 1
  • 19
  • 24
  • If memory serves, **prior** to that token, there is a server-to-server call sending your NVP data. The token is your "identifier link" back to the (previously) submitted NVP data (that at that point **was** sent via server-to-server call) where you then redirect the client/browser (so there is nothing POSTed by the client) - it's just redirected. – EdSF Apr 20 '12 at 14:10