Secure Sessions Overview
SLIM CD Secure Sessions offer the POS developer an easy integration that eliminates PA-DSS requirements. This is done by allowing the developer to create sessions on the SLIM CD servers whereby clerks perform payment data entry through standard Internet browsers. Developers then retrieve the results of clerk payment processing in real-time without ever touching cardholder information.
SLIM CD Secure Sessions offer four unique entry points:
1. CreateSession – This function allows the developer to create a session on the SLIM CD servers. Sessions created are identified by a unique SessionID. If desired, developers can provide additional data that pre-fills forms or enhances transactions.
URL: https://stats.slimcd.com/soft/createsession.asp
2. ShowSession – This function allows a web browser to display an HTML form and collect payment information from a clerk or consumer. The browser is launched by providing a URL containing the unique SessionID.
URL: https://stats.slimcd.com/soft/showsession.asp?SessionID=______________
3. CheckSession – This function is used by the developer to monitor the session and identify the results as the credit card payment transaction is performed.
URL: https://stats.slimcd.com/soft/checksession.asp
4. CancelSession – This function allows the developer to cancel a session and block further processing.
URL: https://stats.slimcd.com/soft/cancelsession.asp
POS Session Diagram
The following represents a simple diagram of CreateSession to start a session, ShowSession to launch a browser for the collection of payment information, and CheckSession to return the payment results.
Getting Started
To display the HTML web page, use the “Show Session” function. This function will accept merchant information and present the payment HTML page inside the browser. We recommend Web developers that can perform an HTTP POST from their current page use this approach. Alternatively, the “Show Session” function can accept a session id that has previously been created using “Create Session”. We recommend Web developers that prefer using redirection to HTTP POST use this method. We also recommend this method for POS merchants who need to launch a browser. Finally, a URL containing session id information can be sent to mobile devices or included in emails so that recipients can use remote client devices to enter payment information independently of the POS system.Getting Payment Results
There are multiple ways to identify the results of the activity from the payment page and regain control of the user interaction. Each different approach is designed to work with different development environments. The simplest way for Web-based applications to regain control is to have the hosted HTML payment page perform a web-based redirection back to the calling application. This can be used in conjunction with a “silent post”, where the payment page first posts the results back to the calling application and then redirects the user to a landing page within the calling application so results can be displayed for the user. The recommended way for POS developers is to a create a session prior to launching the payment page and monitor the session with the SLIM CD LifeLine to acquire the results of the payment page activity. Once the SLIM CD LifeLine returns payment results, the POS application can then resume other activities.Mix and Match Approaches
Web developers may prefer to use a combination of approaches, where initial data is sent silently by creating a session id, browser control is redirected using the session id, results are posted back using silent posts and control is regained with another browser redirect. Alternatively, Web developers may elect to monitor the session for results. Finally, mail-order or other applications that do not expect immediate payment information can create sessions send out payment requests via email or SMS-text using formatted URLs containing session ids, and schedule background tasks that poll for results at longer timed intervals using the session id. This approach is useful when delivering the payment request via email (or other mechanism) where the delay could be several hours or longer.Session Input Format Overview
SLIM CD Sessions accept traditional HTTP FORM name/value pairs with URL-Encoding format. Either HTTP GET or HTTP POST operations can be used, although SLIM CD highly recommends the use of POST when sending consumer information to pre-populate session data with the CreateSession function. Notes:
- SLIM CD Sessions are designed to communicate to and from the developer’s application using 40-byte SessionID values. These SessionID values are sent and received in HEX. Developers can elect to convert the values into 20-byte binary data for local storage; however the SLIM CD servers only send and receive the 40-byte hex version.
Session Output Format Overview
The ShowSession function is designed to display an HTML form for user input, and is intended for use as a URL for a standard web browser (such as Internet Explorer).
All other SLIM CD Session functions, including CreateSession, CheckSession, and CancelSession, return standard XML, formatted in the traditional SLIM CD Gateway format.
The SLIM CD standard XML reply document returned will contain a block. A standard set of fields can be found inside the block:
| Field Name | Description |
|---|---|
| <response> | Text description of the outcome (Success, FAIL, Error, etc.) |
| <responsecode> | Numeric value of the response (0=Success) |
| <description> | Textual description of the FAIL, ERROR, or other non-Success responses |
| <responseurl> | Name of the URL called, to insure the response is from the intended service |
| <datablock> | A placeholder for service-specific information, including sub-fields as needed |
If the field contains the text “Success”, then the service has been successful and the <datablock> will often contain additional information of value as returned from that specific service. All other <response> values represent errors, failures, or other conditions that need attention.CreateSession
CreateSession is used to create a SessionID. SessionID values are later used as part of a secure and tamper-resistant URL so that a browser-style application can be launched to accept cardholder information outside of the developer’s software.CreateSession Input Values
CreateSession Input Values are broken into two sets, required and optional. The required fields match the normal SLIM CD fields created at account setup and used when sending credit card transactions to the SLIM CD Gateway.CreateSession Output Values
CreateSession returns standard XML. The XML document returned will contain a <reply> block. If the <response> field is Success, then the session has been created. All SLIM CD responses contain a <datablock> with additional fields of information. Inside the datablock will be a <sessionid> that uniquely identifies the session created by CreateSession.ShowSession
ShowSession is used to display a previously-created session. It is designed to accept limited input and display HTML output so that the SessionID value can be included in the URL that is provided as a command-line when launching in a browser.ShowSession Input Values
ShowSession requires a single input field, the SessionID. A form is displayed based on the configuration settings for the form on the SLIM CD server.ShowSession Output Values
The ShowSession service returns an HTML web page for display in a browser. The displayed form and the actions of that form can be managed using the SLIM CD HOSTED PAYMENT PAGES functionality in the SLIM CD website.MultiSession
MultiSession is used to display a previously-created session similarly to ShowSession. It is designed to accept limited input and display HTML output so that the SessionID value can be included in the URL that is provided as a command-line when launching in a browser. This also works well when redirecting from one web server to another.MultiSession Input Values
MultiSession requires a single input field, the SessionID(40-Byte value). A form is displayed based on the configuration settings for the form on the SLIM CD server.MultiSession Output Values
The MultiSession service returns an HTML web page for display in a browser. The displayed form and the actions of that form can be managed using the SLIM CD HOSTED PAYMENT PAGES functionality in the SLIM CD website.CheckSession
CheckSession is used to monitor the results of payment processing as it occurs in the browser. CheckSession is designed to allow behind-the-scenes monitoring of the clerk’s payment activity without requiring the developer to touch cardholder data.CheckSession Input Values
CheckSession Input Values are broken into two sets, required and optional. The required fields identify the session and authenticate access to the session information. The optional fields control the timeout for the session and allow additional data to be retrieved from the session or from the SLIM CD payment processing gateway.CheckSession Output Values
The CheckSession service returns an XML document in standard SLIM CD format. The developer should check the <response> field for “Success”, “Fail”, “TIMEOUT” or “Error”.
- The “Success” value indicates an approved transaction.
- The “FAIL” timeout indicates a declined transaction, check <description> for a reason.
- The “TIMEOUT” value indicates that ShowSession has not yet produced a result
- The “Cancel” value indicates that the session has been cancelled by the user or the application.
- The “Error” value indicates some sort of error (such as invalid session id, etc). Check the <description> for a reason.
CancelSession
CancelSession is used to cancel a session. Cancelling a session will prevent the clerk from performing payment processing. Cancelling a session may not be possible if the payment has already been completed or if the payment is currently in-process for payment processing with the credit card companies.CancelSession Input Values
CancelSession Input Values identify the session and authenticate access to the session information.CancelSession Output Values
The CheckSession service returns an XML document in standard SLIM CD format. The developer should check the <response> field for “Success”, “Fail” or “Error”.
- The “Success” value indicates the session has been successfully cancelled prior to payment processing.
- The “FAIL” timeout indicates a declined attempt to cancel.
- The “Error” value indicates some sort of error (such as invalid session id, etc). Check the <description>field for more information.
SendSession
SendSession is used to send a session URL via Email or SMS text message. The recipient can then follow this link on their PC or Mobile device to the previously created hosted payment page where they can enter their payment information and complete the transaction. SendSession Input Values
SendSession Input Values identify the session and authenticate access to the session information.SendSession Output Valuess
The CheckSession service returns an XML document in standard SLIM CD format. The developer should check the <response> field for “Success”, “Fail” or “Error”.
- The “Success” value indicates the session has been successfully cancelled prior to payment processing.
- The “FAIL” timeout indicates a declined attempt to cancel.
- The “Error” value indicates some sort of error (such as invalid session id, etc). Check the <description> field for more information.
Session Review
SLIM CD Secure Sessions provide a simple and effective way to separate cardholder data and payment acceptance from POS applications. Sessions can interact with hosted payment page forms previously created and configured on the SLIM CD servers. Developers can monitor the progress of sessions to identify their completion and can cancel sessions if needed. Configuration of a hosted payment page occurs on the SLIM CD servers. SLIM CD provides interactive web pages that allow the developer to define the form look-and-feel, data fields to display and default values for those data fields. Fields can be display-only, hidden, or editable by clerks. Default values and display HTML form styles be specified.Session Summary
SLIM CD Sessions allow developers to provide payment processing services to clients without touching cardholder data flow within their applications. Sessions are used to communicate information to and from SLM CD’s Hosted Payment Pages. Hosted Payment Pages utilize SLIM CD Payment Gateway Services to process transactions and provide tokenization of cardholder data. Developers can use SLIM CD tokens retrieved from and SLIM CD Payment Gateway Services to process future transactions without touching or storing cardholder data.