Securing Web Based Payment Systems

By Paladion

March 30, 2007

A typical internet payment system consists of a payment gateway that handles information transfer over the internet between merchant and customer. In this article we shall look at some of the risks involved in this information flow.

A typical internet payment
system consists of a payment gateway that handles information transfer over the
internet between merchant and customer. In this article we shall look at some
of the risks involved in this information flow.

What is a payment gateway?

The Payment gateway as the
name suggest act as an important payment link between customers and mechants,
it authorizes payments for merchants and ensure that information travels
securely between customer and the merchant.

Internet Payment Cycle

 Internet Payment Cycle
Fig 1. Internet Payment Cycle

A typical internet payment cycle will involve atleast the following parties:

  1. Customer / Cardholders: A customer places order on a merchant's website. The communication between the website and
    the customer's browser is done via SSL (Secure Socket Layer) encryption.
  2. Merchants: When the customer clicks on 'submit order' or 'Payment' the Merchant Website "redirects"
    the customer's browser to the Merchant's Acquired Bank/Payment gateway
    alongwith the order details (Merchant ID, Order ID, amount etc..). This is
    often another SSL encrypted
    connection to the payment server hosted by the payment gateway
  3. Payment Gateways/Acquirers: The Payment
    gateway/Acquiring bank presents the customer's browser with an interface to
    enter the card/account details used for payment authorization.
  4. The Payment
    gateway/Acquiring bank then forwards the authorization information over a SSL
    encrypted connection to the issuing bank/Host (the bank that issued the credit
    card to the customer) for verification.
  5. Issuer Bank/ Host: The issuing bank/Host
    sends a response back to the Payment gateway/Acquiring bank with a response
    code. In addition to determining the fate of the payment, (i.e Approved or
    Declined) the response code is used to define the reason why the transaction
    failed (such as insufficient funds, or bank link not available).
  6. The Payment gateway/Acquiring bank receives the response, and "redirects" the customer's
    browser to the Merchant's website alongwith the order details and the response
    code, where it is interpreted and a relevant response then relayed back to the
    customer's browser.

The entire process typically takes 3-4 seconds. At the end of the bank day
(or settlement period) the Payment gateway/Acquiring bank deposits the total of
the approved funds in to the Merchants nominated account.

Most Payment gateway
solution providers focus on securing the connection between Customer, Merchant,
Payment Gateway and Bank and feel secure after implementing a 128 bit SSL
connection. The problem is that information is not generally compromised during
transfer, it is compromised when it is received (as a redirect request on the
browser) and stored (payment information on the payment gateway or customer's
browser). We shall look into some of these problems in detail below.

Risks involved

It is evident from the Payment cycle that variables are passed in the
form of HTTP redirects from the Merchant's Website to Payment Gateway and then
the result of the transaction is passed back from Payment gateway to the
Merchant's Website. Since these variables are passed via the customer's browser
they are at a risk of being tampered along the way. Following risks arise as a

  • An adversary posing as a customer modifies
    the Order details passed in HTTP redirect request from the merchant website to
    Payment gateway, so as to pay less or charge some other account.
  • An adversary posing as a customer
    modifies the result of the transaction (response code) passed in HTTP redirect request
    from the Payment gateway to the merchant's website, so as to fake a successful
  • An adversary posing as a customer replays
    a prior transaction (order details and response code) between Merchant website
    and Payment gateway.
  • The card/authorization details may
    be stolen from the payment gateway (in case they are stored there in some form)
    or computer's browser.
  • The merchant are not who they


To mitigate the risks, we need
to look at solutions from the perspective of basic principles of security.


In order to
protect data from being tampered on transit between merchant website and
payment gateway a checksum can be calculated
(using all the variables in the HTTP request) and passed as one of the
variables along with the HTTP requests. This checksum can then be recalculated
at the either end to verify the integrity of the data.

The cryptographic checksum can be
calculated using popular hashing algorithms (HMAC-MD5) using a pre-shared key
between merchant and payment gateway. Since the key is shared only between
merchant and the Payment gateway an adversary posing as the customer will not
be able to modify variables and generate a valid checksum. The pre-shared
secret used for the cryptographic checksum:

  • should be different for each merchant
  • should be securely stored on the merchant's
    website and Payment gateway.
  • should be created and distributed when the
    merchant registers with the Payment gateway.

In addition or alternative to the cryptographic checksum solution, a direct
SSL connection can be established between the merchant and Payment gateway to send
the order and transaction status information.

The direct SSL connection will be used to transfer order details between
merchant website and Payment gateway server before the user is redirected to
the payment gateway for providing authorization information. The Payment
gateway uses the amount in the order information obtained from the direct SSL
communication to debit from the customer's account.

When the payment gateway redirects the customer to the merchant website
along with order information and response code (transaction status), the
merchant website can use order information (Order ID) to query the payment gateway
on the direct SSL connection the status of the transaction. Based on the answer
to this query, the merchant website can decide what needs to be displayed to
the customer.

In either approach,
additionally a unique random token needs to be assigned for each transaction. The
token must be passed along with the variables transferred via the client's
browser to Payment gateway (as payment request) and to Merchant Website (as
Payment response) respectively. The random token will foil "replay attacks"
when it's combined with the cryptographic checksum solution or the direct SSL
connection solution.


Although the transaction data is protected while in transit by SSL, it does not
ensure that key authorization credentials are not stored anywhere in transit.
Authorization credentials may be stored inadvertently into the customer's
computer by the following ways –

  • Stored by Browser's Autocomplete feature
  • Stored in Browser's History as HTTP GET
  • Stored in Browser's memory in cleartext.

The web interface used to capture authorization details must –

  • "Turn off" the Autocomplete feature
  • Transmit credentials as data in a HTTP POST
  • Use salted hash technique for transmitting


Digitally signing the request and responses with a certificate is the safest and cleanest
option to achieve prevention against non-repudiation. The
merchant "signs" or encrypts his digital certificate and sends it along with the
message, the public key of the Certificate Authority is used to decrypt the
digital certificate. This
proves the merchant is genuine. However,
deploying the certificates on a large scale can be a challenge. The
reality is that most consumer e-commerce transactions do not use digital

Tags: Technical