Are these merchant integration instructions bad?
I'm working with a payment gateway that seems to have a fundamental misunderstanding of "clients" and how to protect sensitive data.

The integration instructions are mostly about a "redirect" mode of operation, where a customer is directed to the gateway's website to enter credit card details, where they see a receipt and then get directed back to your website.

**Docs**:

> https://www.myvirtualmerchant.com/VirtualMerchant/download/developerGuide.pdf

Here's an example

    <form 
    action="https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process
    .do" method="POST"> 
    <input type="hidden" name="ssl_merchant_id" 
    value="my_virtualmerchant_id">
    <input type="hidden" name="ssl_user_id" value="my_user_id"> 
    <input type="hidden" name="ssl_pin" value="my_pin">
    <input type="hidden" name="ssl_transaction_type" value="ccsale">
    <input type="hidden" name="ssl_show_form" value="true"> 
    <input type="hidden" name="ssl_amount" value="14.95"> 
    <input type="submit" value="Click to Order"> 
    </form> 

This is the paragraph that has me concerned:

> All sensitive data, specifically your VirtualMerchant credentials, should be placed in server side code 
rather than placing hidden value fields on an HTML form.  This will limit the ability of malicious users 
to edit and use this data for their own fraudulent purposes.  The use of  server-side scripting allows 
custom HTML to be delivered to a client machine.  The code that generates the custom HTML is 
processed on the Web server before the HTML is sent to the user's machine over the Internet.  This is in 
contrast to client-side scripting where the HTML is modified, typically by java-script in the client's 
machine after the HTML and java are sent from the Web server.  The primary strength of using serverside scripting with VirtualMerchant integration is the ability to hide the sensitive processing credentials 
from the browser.

That sounds great &mdash; not exposing my account ID to the client.

However I don't think that what they are suggesting takes care of it. I can only see two ways to hide the details entirely from the client:

* **Have the server act as the client and the browser is never directed to the payment gateway's website**

    They offer this mode, but most of the documents refer to the HTML/client-side form mode instead.
* **Use a signed token of some sort** &mdash; which they don't support.

This paragraph, however, seems to claim something about using "server-side scripting" to deliver "custom HTML", and therefore hide the details?  I just don't see any way - even if the redirect took place via a `Location` header, that data would still be exposed to the browser and anyone with malicious intent could easily get it.

Can somebody please help me understand why this sounds so wrong to me?
Are these merchant integration instructions bad?
===

I'm working with a payment gateway that seems to have a fundamental misunderstanding of "clients" and how to protect sensitive data.

The integration instructions are mostly about a "redirect" mode of operation, where a customer is directed to the gateway's website to enter credit card details, where they see a receipt and then get directed back to your website.

**Docs**:

> https://www.myvirtualmerchant.com/VirtualMerchant/download/developerGuide.pdf

Here's an example

    <form 
    action="https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process
    .do" method="POST"> 
    <input type="hidden" name="ssl_merchant_id" 
    value="my_virtualmerchant_id">
    <input type="hidden" name="ssl_user_id" value="my_user_id"> 
    <input type="hidden" name="ssl_pin" value="my_pin">
    <input type="hidden" name="ssl_transaction_type" value="ccsale">
    <input type="hidden" name="ssl_show_form" value="true"> 
    <input type="hidden" name="ssl_amount" value="14.95"> 
    <input type="submit" value="Click to Order"> 
    </form> 

This is the paragraph that has me concerned:

> All sensitive data, specifically your VirtualMerchant credentials, should be placed in server side code 
rather than placing hidden value fields on an HTML form.  This will limit the ability of malicious users 
to edit and use this data for their own fraudulent purposes.  The use of  server-side scripting allows 
custom HTML to be delivered to a client machine.  The code that generates the custom HTML is 
processed on the Web server before the HTML is sent to the user's machine over the Internet.  This is in 
contrast to client-side scripting where the HTML is modified, typically by java-script in the client's 
machine after the HTML and java are sent from the Web server.  The primary strength of using serverside scripting with VirtualMerchant integration is the ability to hide the sensitive processing credentials 
from the browser.

That sounds great &mdash; not exposing my account ID to the client.

However I don't think that what they are suggesting takes care of it. I can only see two ways to hide the details entirely from the client:

* **Have the server act as the client and the browser is never directed to the payment gateway's website**

    They offer this mode, but most of the documents refer to the HTML/client-side form mode instead.
* **Use a signed token of some sort** &mdash; which they don't support.

This paragraph, however, seems to claim something about using "server-side scripting" to deliver "custom HTML", and therefore hide the details?  I just don't see any way - even if the redirect took place via a `Location` header, that data would still be exposed to the browser and anyone with malicious intent could easily get it.

Can somebody please help me understand why this sounds so wrong to me?