|
|
Payment Gateway
Mumbai
Payment
Gateway India
Payment
Gateway Pricing
Payment Excess Charge
Payment Fraud Alerts
Payment
Over View
Payment Gateway Requirements
Payment
Gateway Process
Payment
Gateway Billing
Payment
Gateway Comparison
Payment Gateway FAQ |
|
|
Payment Gateway India Over View
.
Transecute is today the most comprehensive
online peer-to-peer payment exchange platform. This document discusses how
you may integrate your website to accept payments online through the
Transecute Payment Gateway. Due its ease of integration a typical website
can be online accepting live transactions in a couple of hours. This
document serves to explain how Transecute works and how a merchant may use
Transecute to e-enable his online presence or simply accept online payments.
Before we delve into the nittygritties of integration of your website we
will need to first understand the Transecute Architecture. Following are
some loose concepts that will help you grasp the remainder of this document.
The Transecute integration process consists of a simple URL exchange format
between you as a Merchant website and Transecute Server as the Payment
Gateway server. This involves passing certain variables from your server to
ours and then passing back the result of the transaction from our server
back to yours.
Obviously since variables are being openly passed between your server and
Transecute we need to ensure that these variables are not tampered along the
way. For this purpose a checksum is calculated and passed alongwith the
data, using a 32 bit alphanumeric key exchanged between us. This checksum is
then recalculated at the other end to verify the authenticity of the data.
This is explained in further detail later.
Apart from the above overview you will need to know the meaning of
the following variables -
Member ID: Each Transecute Member is given a Member ID. As a Merchant
accepting payments online through Transecute even you will have a Member ID.
This Member ID uniquely identifies you as a Member of Transecute. This is
very much like a Bank Account number.
Key: Besides the Member ID a 32 bit alphanumeric key is assigned to each
Member. This key is used to ensure security of all communications between
the Member and Transecute. This key can be changed at anytime by the Member
by logging into his Backoffice interface. It is advised to change this
key at regular intervals or immediately upon identifying any security
compromise. However it is important to note that once you change the key
your code on the checkout page will also need to be changed to reflect this.
To describe this in more detail - this key is actually used to calculate a
checksum for any message exchanged between the Member's website and
Transecute. So if the Member is sending some data to transecute a checksum
will also be sent alongwith this data. Transecute will then take the data
and recalculate the checksum at its end and if it does not match the
checksum sent by the Member then the data has been tampered on the way and
an error will be displayed. Similarly the Member will calculate the checksum
for all messages sent to the Member by Transecute and verify the accuracy of
the data.
Login/Password: A Login and password is assigned to you upon sign-up which
will allow you to login to your Backoffice interface.
The Backoffice interface will also have additional options to transfer your
funds elsewhere, modify your settings and other details.
Test/Live Interface
Test/Live Interface: In order to facilitate easy integration an online
testing sandbox environment is offered to all Merchants. All integration
code, modifications and upgrades can be tested here by you before actual
deployment.
When sending any transactions to the Transecute server you can set the
transaction to be live or test. This is to ensure that during testing you do
not accidentally carry out a transaction, which charges your card. All test
transactions are not sent to the payment gateway and therefore will not
have any effect on your balance. In test mode you have the facility to
simulate a transaction failure or a transaction success to judge whether
your scripts give you the appropriate result.
Variables in any Transaction:
Below is a list of all the variables that you will deal with in any
transaction.
Member ID/Client_ID/ToID: Your unique ID given at the time of signup.
Description/Order No/Order ID/Desc: A Unique alphanumeric ID generated by
you to uniquely identify this order. The situation is slightly tricky here.
The Description/Order ID should be unique since it would allow you to
identify the transaction easily. However incase a transaction fails the same
order id maybe sent again. Actually this is how it works. When an Order ID
is sent from your website to Transecute, Transecute verifies if there is any
successful transaction or pending transaction of that particular Order ID in
the database. If it finds an ongoing transaction or a successful transaction
of the same Order ID an error message will be displayed. If however no
successful or partially complete transaction is found for this Order ID then
the transaction will move on.
Note that it is this Description/Order ID that will be visible to you
corresponding to this transaction in your Account statement in your
backoffice.
Key: This refers to the 32 bit alphanumeric key assigned to you during
signup. This is used to calculate a checksum to be sent with every message
between your server and Transecute Server to ensure that the message is not
tampered along the way.
Checksum: This refers to a random numeric string generated using a
mathematical algorithm (a complex quadratic equation) to ensure that data is
not tampered along the way. The way it works is lets say a message has to be
sent from A to B. A and B both mutually agree on a Key that only both of
them possess. A checksum is generated by a mathematical function using the
message and the Key as input. This checksum is then sent alongwith the
message to B. B then recalculates this checksum using the Key and the same
algorithm. If the checksum that B calculates is different from the checksum
that A passed then the data was tampered along the way. Ideally the best
checksum algorithms produce a very large change in the checksum with the
smallest change in the data. The algorithm we use is a standard Adler32
which is used for CRC checks in data and is supposedly one of the most
efficient.
Redirect URL: Once the customer on your website has finished authenticating
the transaction he is returned back to your website. The URL to which the
customer returns back is called the Redirect URL. To this redirect URL we
pass return values such as the status of the transaction, the Amount, Order
No and a checksum. This Redirect URL is a dynamic page on the Merchant
Server.
Transaction ID: This is a unique ID generated by Transecute for every
transaction. This maybe used for referencing a particular transaction with
Transecute. This number is visible on your Backoffice interface.
Credit Card Number: This refers to the Credit Card Number that has been
entered by the customer.
Name on the Card: This refers to the name of the customer as it appeards on
the Credit Card.
Expiry Date: This refers to the expiry date as it appears on the Credit
Card.
Return URL: Required only and only if Socket connection method is not being
used. This contains the URL of the file to which the status and the message
of the transaction will be passed.
Message Exchange:
The following messages are exchanged between the Merchant and Transecute in
a complete transaction in the following order.
1) Redirecting the Customer from your website to Transecute: When the
customer reaches the checkout page you will submit the following variables
to our server
toid: The Member ID assigned to you. The reason it is called toid (To ID)is
because this is the ID to which the money is going
description: The Unique alphanumeric order number assigned to each Customer
Order.
redirecturl: the complete url to which the customer will be returned after
the transaction is complete
fromtype: this signifies the Payment option the customer chooses for payment
(ie Visa/Master, HDFC Debit, Transecute Account etc)
amount: This signifies the amount of the transaction
checksum: This is the value of the checksum calculated for the data that is
being passed to our server. This checksum is calculated using functions
provided by us to you
2) Redirecting the Customer from Transecute back to Merchant's website:
When the transaction completes your Redirect URL script will be called with
the following parameters.
desc: Unique Order Number of this transaction that was generated by the
Merchant in the beginning of the transaction and sent to Transecute amount:
Amount of the transaction
status: This can be either 'Y' or 'N'. A 'Y' signifies that the transaction
went through successfully and that the amount has been collected. An 'N' on
the other hand signifies that the transaction failed.
newchecksum: The checksum calculated for the above parameters using the key.
This checksum has to be verified by the Merchant to ensure that the data
received is indeed sent by Transecute and not tampered along the way.
Merchant Backoffice interface:
The Backoffice interface has been greatly modified to represent a bank like
interface showing all the debits and credits with appropriate descriptions.
Indeed a Transecute Account may be treated as an online banking account
where money is being received from your customers.
|
|
