Lateral Payment Solutions provide an online credit card/debit card processing solution for e-commerce businesses. We provide a highly sophisticated fraud screening process to reduce the risk posed to online merchants in the ‘card not present’ environment.

We provide a 256 bit SSL interface for secure transmission of data over the internet. A secure reporting and administration system to provide real time information available.

This document explains the technical integration requirements and procedures. It is of a technical nature and should be read as such.

INTRODUCTION

The merchant’s server makes a request through a HTTP POST and receives the result of the processing request as the response to the POST request. Both the request & response are made through a single TCP/IP connection. Your server opens an SSL protected socket connection to the LPS payment engine and the LPS system posts the result of the transaction back on the same connection.

TRANSACTION FLOW DIAGRAM

Transactions are sent via a Synchronous HTTP POST, the response is received on the same TCP/IP connection. The transaction flow is depicted in the following diagram given below:

1. CUSTOMER TO MERCHANTS WEBSITE
   Customer submits payment request encrypted over SSL;

2. MERCHANTS SERVER TO LPS SERVER
   Contains all the necessary card data and card holder details. This is sent over secure encrypted SSL;

3. a. LPS SERVER TO MERCHANTS SERVER
   LPS gateway performs data, velocity and fraud checks. If any fail, the transaction process is stopped and a failure code is returned;

   b. LPS SERVER TO BANK
   The transaction is sent from the LPS gateway to the bank;

4. LPS TO MERCHANTS SERVER
   LPS sends the bank response details to merchant server;

5. MERCHANT SERVER TO END USER
   Merchant updates database and notifies customer of success or failure of the transaction;

6. LPS SERVER TO END USER
   LPS can send an e-mail receipt to customers where the transaction is successful. Merchant can receive a copy of the e-mail for customer support or account management purposes;


INTEGRATION IN DETAIL

NB. For questions or help at any stage of integration, please send an email to technical@lpsmail.com

1. OVERVIEW

The merchant’s server makes a request through a HTTP POST and receives the result of the processing request as the response to the POST request. Both the request & response are made through a single TCP/IP connection. Your server opens an SSL protected socket connection to the LPS payment engine and the LPS system posts the result of the transaction back on the same connection.

2. MERCHANT SERVER TO LPS SERVER

To process a payment, request all mandatory fields found in Schedule 2A need to be posted via SSL to LPS payment gateway URL which will be provided by LPS. All communication between LPS and the merchant is via SSL only. The merchant server makes a request through an HTTP POST to the LPS server LPS receives the payment request, performs fraud screening and returns to the merchant a result of either fraudscreening (failed) or the bank response (if passed fraud screening).

Points to note about the POST to LPS

• LPS provide the merchant_user_id and merchantpwd
• Replace spaces in the user details with +. You do not however have to do a full URL-encode of the request string.
• Post amounts as 2 decimal places only. Applies to amount field. i.e. 125.03
• A payment request will not be accepted for processing if the mandatory fields in Schedule 2A are missing.

If a payment request does not contain all the mandatory fields then the system will return the fraudscreening_status value of 9001 and an LPS_Transaction_id of –1.

3. LPS SERVER BACK TO MERCHANT SERVER

Using the synchronous method your server opens an SSL protected connection to the LPS server and awaits a HTTP response from the server. If the data is sent successfully (HTTP Status 200) you need to retrieve the Response to the payment request. This will be returned as a query string with the variables described in Schedule 2B. Two response types may be returned; either fraud screening failed or bank transaction status.

Points to note about the LPS return POST

• LPS generates a unique transaction id for each transaction. This is returned to the merchant’s server along with the merchant reference number.
• Merchants must use the LPS_transaction_id for any transaction enquiries with LPS • LPS response includes an id and password in the string for merchant server authentication purposes; this is the user name & password you supply to LPS and is different from the LPS supplied pair in the original post to Schedule 2A.
• If mandatory fields are missing then the system will not accept the transaction for processing. The details will be logged, and the system will return a Fraudscreening_status of 9001 & an LPS_transaction_id of –1.

4. LPS TO END USER

LPS send an e-mail receipt to the customer for each authorised payment request. The receipt contains all transaction details and an email address for customer enquiries. The email is sent from the merchants chosen address and not from LPS e.g. support@merchant.com. The merchant will receive a copy of the receipt sent to the customer

When the customer is redirected to a URL on LPS Gateway after 3D SECURE authentication, it will match the transaction Id passed with the existing pending transaction. The status of the transaction will be updated to “3D SECURE Response Returned” and the 3D SECURE response will then be transferred back to a merchant’s URL which will return the customer back to the merchant site along with the details given in Table 2E.

The merchant should extract the 3D SECURE response and update the status of the transaction as 3D SECURE Response received. Note at this stage neither LPS nor the merchant know if the 3D SECURE authentication is successful. They will then open synchronous connection back to LPS payment gateway with the transaction details as shown in Table 2F.

Folders contain information about the items contained inside of them, including files and other folders. There is also a set of metadata such as who owns the folder and when it was modified that is also returned. When accessing other resources that make reference to folders, a ‘mini folder’ object will be used.

Retrieves the files and/or folders contained within this folder without any other metadata about the folder. Any attribute in the full files or folders objects can be passed in with the fieldsparameter to get specific attributes, and only those specific attributes back; otherwise, the mini format is returned for each item by default. Multiple attributes can be passed in separated by commas e.g. fields=name,created_at. Paginated results can be retrieved using thelimit and offset parameters.

Used to create a new empty folder. The new folder will be created inside of the specified parent folder

Retrieves the full metadata about a folder, including information about when it was last updated as well as the files and folders contained in it. The root folder of a Box account is always represented by the id “0″.

Used to update information about the folder. To move a folder, update the ID of its parent. To enable an email address that can be used to upload files to this folder, update thefolder_upload_email attribute. An optional If-Match header can be included to ensure that client only updates the folder if it knows about the latest version.

Used to delete a folder.

Used to create a copy of a folder in another folder. The original version of the folder will not be altered.

File objects represent that metadata about individual files in Box, with attributes describing who created the file, when it was last modified, and other information. The actual content of the file itself is accessible through the /files/{id}/content endpoint. Attributes listed in green will not appear in default file requests and must be explicitly asked for using the fields parameter.

Used to retrieve the metadata about a file.

Used to update individual or multiple fields in the file object, including renaming the file, changing it’s description, and creating a shared link for the file. To move a file, change the ID of its parent folder. An optional If-Match header can be included to ensure that client only updates the file if it knows about the latest version.

Comments are messages generated by Box users. Each message is tied to a specific file. You can create comments independently or create them as responses to other comments.

Used to update the message of the comment.

Used to add a comment by the user to a specific file or comment (i.e. as a reply comment).