There are two primary options in which transactions can be submitted through the Payment Gateway API. The most direct and transparent method is our direct post method.
Step 1 - The customer sends their payment information to the merchant's website.
Step 2 - The merchant's website posts the payment data to the Payment Gateway.
Step 3 - The Payment Gateway responds immediately with the results of the transactions.
Step 4 - The merchant's web site displays the appropriate message to the customer.
The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection.
In the Direct Post method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway.
Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message.
In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request.
In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands.
For example: variable1=value1&variable2=value2&variable3=value3
Step 1 - The customer begins the merchant's checkout process.
Step 2 - The merchant returns a payment page to the customer with the form's action pointing to the Payment Gateway.
Step 3 - The customer posts payment data to the Payment Gateway by submitting the form.
Step 4 - The Payment Gateway processes the transaction and redirects the customer back to the merchant's website with the appropriate results in the GET query string.
Step 5 - Because of the redirect, the customer's browser automatically requests the previously passed redirect page on the merchant's web site.
Step 6 - The merchant's web site interprets the query string variables and displays the appropriate message to the customer.
The redirect method is a bit more involved because the cardholder will be submitting payment data directly to the Payment Gateway but the response must be relayed back to the merchant's web site.
Upon the cardholder's request to checkout (Step 1), the merchant must display a form to the cardholder (Step 2) that contains or collects the appropriately named variables (as defined below). The additional redirect variable (as defined below) will indicate to the Payment Gateway where the cardholder should be directed and essentially what file will parse the transaction results. This will typically be passed as a hidden field. This form should also have an action of the Payment Gateway's URL.
When the cardholder submits the form, the data is posted to the Payment Gateway (Step 3). The Payment Gateway processes the transaction and sends a header redirect back to the cardholder (Step 4).
In Step 5, the cardholder requests the URL defined by the previously posted redirect variable and the results of the transaction are included in the GET query string. The merchant must create a script that parses these response variables, updates their database/ordering system appropriately, and displays the receipt or decline message to the cardholder. (Step 6)