Payment Gateway - URL redirects

[Gulam Gaus]

Hi all,

Being a newbie in python+django, I got my first shop completed except payment where I am seeking your suggestion to my payment gateway problem. I am sorry if this is too obvious and been answered before.

Here in India, there is a unique payment solution offered by the local banks called 'Net-banking'. Its nothing but url redirection. As soon as the visiting customer click on "CHECKOUT", he/she must be redirected to the unique Bank's url where all the payment (Debit/Credit Card) will takes place and then based on the payment status (successful or rejection), we should be able to return our customer back to our site along with the transaction code.  Simply put it means that all the payment processing will happen at the bank's gateway only.   

What I am looking at is how to redirect our customer to the Bank's site and return them with a transaction code??

Thanking you in advance.

Gulam Gaus

++

[Ken Bolton]

Hi Gulam,

Do you have a link you can share to any published documentation on how
that is supposed to work?

I can point you to the payment processor I wrote for PayPal about a
year ago, based mostly on the other extant payment processors:
https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/payment/paypal.py.
That is an example of how it is expected to work that returns the
transactionID.

best,
ken

[Gulam Gaus]

Hi Ken

Thank you so much for that quick reply. I was busy collecting the exact requirement of the payment gateway interface from my client to be integrated with my checkout.  I guess it is similar to the link that you sent me. 

I would be grateful if you could help/guide me on the possible integration steps with my checkout. 

For your info: http://www.hdfcbank.com/sme/sme-details/merchant-services/guzh6m0i

How an internet transaction is initiated and processed through Payment Gateway ?

• The customer fills his shopping cart on a merchant website and proceeds to check out.
• The transaction information is transmitted to the merchant server.
• The web merchant forwards a digital order to the Payment Gateway server in an encrypted format.
• The Payment Gateway authenticates the merchant and provides payment options and payment details screens directly on the customer's browser over a secure 128-bit SSL+ connection.
• The customer provides his credit card details, which is directly sent to the Payment Gateway server when he clicks "Pay" .
• The credit card details are then switched to the Operator / Bank for authentication.
• The Operator / Bank then transmits the message to the cardholders' bank for payment authorisation.
• The issuing bank authorises the payment, provided the card is valid and has the requisite credit limit and transmits the confirmation back to the Payment Gateway through the Operator / Bank
• On receiving the authorisation, Payment Gateway forwards a digital receipt to the merchant server.
• The merchant provides a confirmation of the payment to the customer's browser.
• The entire process integrates seamlessly with the shop and buy application of the web merchant.
• The merchant may then ship the goods and capture the transaction on the gateway server.
• Utilises Java architecture and a relational database — either Microsoft SQL or Oracle — for scalability and portability.
  
• Transactions are screened by up to three negative files – BINs; hot cards reported lost or stolen; and warm cards that have exceeded usage or other temporary parameters.
  
• Supports multiple payment types and can route to various authorisation systems and traditional card payment engines.

Thanking you in advance

Gulam Gaus

++

[Ken Bolton]

Hi Gulam,

Happy to provide whatever insight I can.

All I read in that link are what I would generously call "marketing materials".

For the PayPal processor, I relied heavily on the PayPal documentation
at https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_nvp_r_DoDirectPayment
and https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_nvp_errorcodes.
If you can point me to HDFC's equivalent documentation, I can help you
map out the payment structure.

best,
ken

[Gulam Gaus]

Hi  Ken

Thank you so much for your kind reply and nice of you to help me in setting up my payment processor for my requirement. I have contacted my HDFC bank & as soon as I get the details by today or tomorrow I will give you the details & please help me to build this processor. As you said, the concept is very similar to PayPal processor with perhaps little tweaks.

Thanking you in advance.

Gulam Gaus

[Gulam Gaus]

Hi Ken

Here it is.  I finally managed to get the Bank's test kit api which I am forwarding you some attachments (3 files) for your kind reference. Also find below the details which may be of particular interest to you for the integration.

Please remember that the integration type that we are trying to do is, with the Bank's own hosted  UMI. Followings are the major 5 categories of information, received from the Bank to me which I am sure would be helpful to you to advice me.

BANK PAYMENT DETAILS:-

1. Test Setup/Account Details with API/Plug-in Kit

2. Test Merchant Console/Portal Details

3. Usage/Population of User Defined Fields (i.e. UDF)

4. Transaction Request/Response Handling Mechanism & Questionnaire

5. Test Cases (16 Point User Acceptance Test)

• Section 1. Test Setup/Account Details with API/Plug-in Kit - Please find below your test setup/account details along with necessary API/Plug-in kit.

Sr No	Description	Value
1	Merchant Name	KETANA HOME COLLECTIONS
2	Test Merchant Id	9299
3	Test Terminal Id	90000299
4	Test Terminal Alias Name	90000299
5	Currency Code - Numeric	356
6	Currency Code - Alphabetic	INR
7	Currency Code Exponential	2
8	Payment Gateway	FSS
9	Test Kit Platform	PHP
10	Integration Type	Bank Hosted(UMI)
11	Alliance Partner, if any	Stand - Alone

• Section 2. Test Merchant Console/Portal Details - Please find below your test merchant console details. You can use these details to log-into the Payment Gateway merchant console to monitor transactions, download reports, download resource file details, etc. Kindly ensure that you change the console password at the very first log-in.

Sr No	Description	Value
1	Test Merchant Console URL	https://securepgtest.fssnet.co.in/pgway/gateway/Merchant/index.jsp
2	Test Institution Login Id	hdfc
3	Test Merchant Id	9299
4	Test User Id	KETANA
5	Test Console Password	password5

Important Note: Using the above provided credentials, please log-in into the merchant console in order to take "Tranportal ID and Tranportal password". Kindly browse through Menu tab --> Developers --> Select the option Plug-in setup detail and note the  Tranportal ID and Tranportal password.  The Merchant Id, Terminal Id, Tranportal ID and Tranportal password which are provided in this mail are only for Payment Gateway Test Integration. Please do not try going live with the above mentioned test credentials, as the required processing of the payment and the corresponding card settlement will not be processed for test credentials and it could lead to serious reconciliation issues.

• Section 3. Usage of "User Defined Fields" - i.e. UDF  - Please find below a detailed note on usage of User Defined Fields.

As per HDFC Bank's E-commerce Security Policy, all Payment Gateway Merchant's have to use all the five User Defined Fields compulsorily. Rightly populated UDFs will help our Risk Team to monitor transactions and alert merchants for suspicious/fraudulent transactions. This helps the bank as well as the merchants to mitigate risk and act quickly upon identifying a suspicious transactions to minimize risk exposure.

As per your business model, we recommend five (5) categories of information to be populated in the UDFs. The details to be populated against each UDF's are as follows. UDF 1 to 4 are standardized & remaining one UDF is merchant specific. We shall communicate the same according to the nature of business.

UDF 1 - Service Details
UDF 2 - Email ID
UDF 3 - Contact Number.
UDF 4 - Billing Address
UDF 5 - Merchant specific

UDF Limitation: While populating UDFs, please make sure that you do not use the following characters as they are considered hack characters: >> << < > ( ) { } [ ] ? & * ~ ` ! # $ % ^ = + | \ / : ' " , ;

Each UDF's length is 250 characters and only the following special characters are allowed: - _ @  . and Space

• Section 4. Transaction Request/Response Handling Mechanism & Questionnaire And IP Address Validation and Parameters Verification- Please find below a detailed note and best practices on handling transaction request and response. You are requested to carefully read this and adhere to the bank mandated request/response handling recommendations.

• Payment Request Initiation Process: While the shopping cart population and customer check-out process will vary from merchant to merchant, the bank strongly recommends you to ensure that your customer/shopper cannot modify the quantum of goods and purchase value, so that Payment Request to the bank’s Payment Client/Plug-in residing in your domain receives intact card payment request. One of the best practices to transfer the shopping data to bank’s Payment Client/Plug-in is by using a back-end process, so as to ensure that the shopper cannot modify the quantum of goods or services or the purchase value of the selected goods or services.

• Payment Response Validation Process: As per the standard integration methodology, merchant initiates a transaction request and provides a URL to Payment Gateway on which transaction response has to be delivered. Payment Gateway processes this transaction request and delivers transaction response on the URL provided by the merchant. This URL is referred to as Receipt URL OR Error URL OR Re-direct URL. Payment Gateway ensures that transaction response is relayed securely on the Receipt/Error URL using a 128 bit SSL tunnel. However it is the merchant's business logic to handle and take forward the transaction response from here and Payment Gateway/Bank does not have any role in taking forward this response for cardholder communication.

Response handling logic differs from merchant to merchant. For instance some merchants may use session management to take ahead the response, some merchants use encryption/decryption with re-direction, some merchants have the receipt page as the final confirmation page, etc. Whichever be the scenario, the merchants should necessarily validate transaction response from Payment Gateway and then securely store it first, in his secured storage environment. Validation includes but is not limited to; validating transaction amount, result and track id received in response against the transaction request, validating other parameters that the merchant may have sent in the request & validating whether the transaction was successful or unsuccessful. If the validation is successful, then the merchant needs to ensure no tampering/modification happens to the transaction response and the response should be securely stored in the merchant’s storage environment, ONLY then the response should be communicated to the cardholder. While communicating the transaction response to the cardholder, the merchant needs to retrieve the response from his secured storage environment instead of using simple re-direction methods which are prone to getting tampered.

In an unlikely event where the validation fails, then the merchant is requested to immediately raise an alarm and contact his relationship manager/bank’s risk management team to initiate further course of action. In this scenario the merchant should not confirm transaction success status to the cardholder till such time bank’s risk team verifies the authenticity of the transaction. This helps in mitigating fraud/risk originating from tampering of transaction response.

The merchants are also encouraged to use the Dual Inquiry option of Payment Gateway to have a two level check on the transaction response authenticity.

• Payment Response Validation Process: IP Address validation needs to be implemented by the Bank Hosted Page merchants in their RESPONSE URL and ERROR URL; this is to validate the IP address from where the  response is receiving on the merchant response URL of error URL.

Pls call for the IP(s) to be enabled for receiving the response from Payment Gateway.

• Response Handling Questionnaire: Request you to kindly fill and submit the below attached questionnaire once you have integrated with our Payment Gateway by following the bank mandated procedures and response handling mechanism, we would verify it basis your written confirmation/inputs and would offer feedback in case there is any disconnect/ambiguity. We would also provide our confirmation basis your written confirmation on whether the request/response handling is done properly or not. In no way this confirmation should be treated as a validation confirmation as we are playing a consultative role on what you tell us and have no control on what is actually written in your business logic/code. This exercise is done to sensitize our merchants on how important it is to ensure proper request/response handling to mitigate the risk of request/response getting tampered.

The bank mandated request/response handling mechanism should be strictly followed for test as well as production setup/integration. 

• Section 5. Test Cases (18 Point User Acceptance Testing) - Post successful completion of the above we request you to execute the bank mandated 18 test cases. This would also provide you a fair idea of transaction processing life-cycle and would further help you to develop an enriching customer experience for transaction processing.

There are 18 test cases to be executed/responded back. Cases 1 to 14 are transactional and cases 15 to 18 are to get a confirmation from merchant on adherence to request/response handling, storage of response in secured database storage, usage of their own demo/sample pages & implementation of daily reconciliation process.

Please find below the test cards that you can use (STRICTLY IN THE TEST ENVIRONMENT WITH TEST PAYMENT GATEWAY INTEGRATION)

Test card for testing
Card Number: 4346 7700 0000 0029
Expiry Date: 12/12
CVV Value: 203

Thanks

GG

++

[Ken Bolton]

Hi Gulam,

I am away for the next two-plus weeks doing a charity kayak trip down the Hudson River. (Shameless plug: http://www.hudsonsheart.com/web-pages#!__web-pages/paddling-the-hudson-for-hudson. Give till it hurts!) The best I can offer you is a link to the existing payment processors here: https://github.com/stephenmcd/cartridge/tree/master/cartridge/shop/payment. The way Stephen set that up, writing a new processor is very straightforward. The paypal processor (which was my first contribution to Cartridge) was cribbed from the authorize processor, with changes only to handle the specifics and peculiarities of PayPal.

best,

ken