Doing an integration with an online payment provider. Payment provider will be making a web request to my server to provide some information about the basket content. On my end there's no payment processing involved, I only need to be able to capture the basket information along with the merchant ID. The payment provider will be acting on behalf of multiple eCommerce merchants in capturing and processing credit card details.

Security requirements:

  • I need to be able to verify that a request has come from a specific merchant
  • I need to be able to verify that the message hasn't been tampered with
  • I need to be able to validate the client time stamp

Few alternatives that I have.

  1. HMAC Signature

    • Payment provider to generates a HMAC signature (SHA-256). (With a pre-agreed signing key per Merchant) StringToSign = MerchantId + BasketInfo + Timestamp
    • Payment provider sends the above signature along with MerchantId, BasketInfo and Timestamp in clear text in a HTTP post.
    • Signature is verified on my end
  2. Public key encryption along with symmetric encryption

    • SymmetricEncryptedText = AES_Encryption( BasketInfo + Timestamp) using a pre-agreed symmetric encryption key
    • TextToPublicKeyEncrypt = MerchantId + SymmetricEncryptedText
    • FinalEncryptedText = Public Key Encryption using my public key (TextToPublicKeyEncrypt ) FinalEncryptedText is sent in HTTP Post
    • On my end, FinalEncryptedText is decrypted using my private key. This gives me access to MerchantId + SymmetricEncryptedText
    • Decrypt SymmetricEncryptedText using MerchantId specific symmetric key
  3. Symmetric Key Encryption

    • StringToEncrypt = BasketInfo + Timestamp
    • EncryptedText = AES Encryption (StringToEncrypt )
    • MerchantId and EncryptedText is sent by payment provider in HTTP Post
    • EncryptedText is decrypted using the MerchantId specific symmetric key

Appreciate you could shed some light on evaluating these options (Or any other suggestions) All communication is using SSL/TLS. So a man in the middle attack can be ruled out.

HTTP Posts happen through client web pages using a JavaScript AJAX call. So any token generated using above schemes will need to be generated and included in client side JavaScript. (Which enables an end user to be able to see the tokens on their web page source)

In my view, Option #1 and #3 are of the same nature. In Option #2, due to public key encryption, MerchantId is not shown on plaintext on user's HTML source. But does it really make #2 more secure due to MerchantId not being visible on user's HTML source?

Apologies in advance for the lengthy question. Let me know if any clarifications required.

  • I prefer considering webhooks unauthenticated. They simply trigger a request from my server to the server that sent the request. The receiving server only acts on the information fetched from the the sending server, not on the information pushed by that server. Depending on the third party this approach may not be possible, but when it's available I prefer this approach instead of doing any crypto myself. – CodesInChaos Aug 6 '14 at 14:35
  • @CodesInChaos: unfortunately that option is not viable with the Payment providers we need to deal with. They are happy to push data from their end though. – user1502505 Aug 6 '14 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.