Below is a list of all the variables that you will deal with in any transaction using the TrillionPay Payment Interface. Apart from this you may want to read the entire Message Exchange for a thorough understanding of these variables.
Member ID/ToID: Your Unique ID given at the time of signup.
Description/Order ID: A Unique Alphanumeric ID generated by you to uniquely identify this order. The Description/Order ID should be unique, since it would allow you to identify the transaction easily. However, in case 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 TrillionPay, TrillionPay 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 interface.
OrderDescription: This is an explanation of the Transaction and is NOT unique. For example -
If you are selling Books from your site, then you can pass the following parameters to the TrillionPay server -
Description/Order ID - ABFUDYE643JDYSK (there can be no spaces in-between and this is a compulsary field)
OrderDescription - Payment for Oliver Twist (this is NOT a compulsary field)
Key: This refers to the 32 bit alphanumeric key, generated by the Member from his Merchant Administration Interface and placed in the Checkout and Redirect pages. This is used to calculate a checksum to be sent with every message between your server and TrillionPay 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 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 TrillionPay for every transaction. This maybe used for referencing a particular transaction with TrillionPay.