Hosted Payment Pages
Steps of Creating Hosted Payment Page.
Step 1. visit http://www.slimcd.com and login with your credentials.Step 2. Goto Sessions->Manage Forms.
Step 3. Click on “Add a new form” button.
Step 4. “Configuration Forms for ” page opens.
Step 5. Now, the first section is the form configuration. It has a number of sections. Each section allows the user to specify different aspects of the form.
Step 6. Now, the next section is “Page Options” which control the HTML for each page you create.
Step 7. Then, the next section is “<Table>Tag Information” which specifies the values to insert when generating HTML(Note that the best way to judge the effectiveness of changes is to use SHOWSESSION to see the effects and VIEW SOURCE to see where the values are inserted).
Step 8. Now, the next section is <FONT>Tag Information which allows the developer to select font face and color for the page text,prompts, errors, and “grey” items.
Step 9. Click on Add New Form button when you are finished and your form will be added.
Step 10. Now you can use this form as your WEB page.
Overview: Managing Hosted Payment Pages.
Hosted Payment Pages
The SLIM CD Hosted Payment Pages provide POS and WEB developers with the fastest and easiest way to attain PCI compliance. This is done by removing the collection of payment data from the POS or WEB application and placing the credit card information screens within a browser-based payment page that runs on SLIM CD’s PCI-secured servers.
Once a developer’s application avoids touching cardholder data within their applications, they are no longer required to obtain a PA-DSS certification. Developers circumvent the PA-DSS requirement altogether by directing the input of cardholder data to a SLIM CD hosted payment page.
The center of the system is the HTML payment page. This page can display information, relay information and can collect information. SLIM CD provides multiple ways to integrate information into the HTML page and retrieve results at the conclusion of payment processing.
SLIM CD’s solutions offer traditional redirection-based responses and SLIM CD’s proprietary LifeLine technology to allow seamless integration and separation of payment interfaces from merchant applications.
HTML Pages
SLIM CD Hosted Payment Pages provide HTML-based display of forms for cardholder data input. Both keyed and swiped transactions are supported. Standard Internet browser-style applications are used to display the form and send data to our secure servers. These HTML-based forms can be pre-populated with consumer information from either a POS or WEB application.
Transaction Flow
In its simplest form, this SLIM CD hosted HTML page can be launched by web developers using an HTTP POST or web-based redirection. Upon completion of the payment, the HTML page can display receipts and/or redirect the browser to a location specified by the developer to complete the round-trip back to the originating system.
A second approach, popular among POS developers, is to create a session and send data to and from that session. In this implementation, an HTTP POST is performed by the POS or WEB application to initiate a session and acquire a unique session identifier. The payment page is then displayed separately using the unique session identifier. Finally, the POS or WEB application uses the SLIM CD LifeLine technology to retrieve synchronous or asynchronous results from the SLIM CD. This multi-step approach allows developers to send data outbound to the Hosted Payment Pages and retrieve results from those pages without requiring POS or WEB systems to accept inbound transmissions from SLIM CD’s servers.
Parts of a Hosted Payment Page
Payment pages are created/configured by developers and reside on the SLIM CD server. SLIM CD servers generate HTML for these hosted pages using a variety of options that can be configured. There are a few decisions to be made when creating the form.
- How will the transaction flow operate?
- What fields will be sent to the form, collected/updated by the form, and retrieved from the form?
- How do you want the form fields to display/operate?
- What will the graphics look like?
Understanding Transaction Flow
Transaction flow to the Hosted Payment Page is performed with the CreateSession and the ShowSession functions. The CreateSession function stores data on the SLIM CD servers so that it can be displayed or utilized by the session and the Hosted Payment Page. A form is pre-populated by calling CreateSession with the data for the fields. The form is displayed by launching a browser or redirecting to ShowSession. There are no configuration options required to create a session or show a session, other than creating the form itself. Data fields can be created so their values can be displayed, edited, or returned.
Transaction flow from the Hosted Payment Page is performed in one of two ways. The calling application passes control to ShowSession. It can either call CheckSession to monitor results, or it can wait for a PostBack containing the results, followed by a returning Redirect to transfer display control to a pre-configured web page.
For POS merchants, the POS application should call CheckSession to poll for results, as there is no web server or page to use as a redirection target. CheckSession returns a standard set of values, plus any additional fields for which the “Pass back to checksession” checkbox has been marked.
For WEB merchants, the PostBack and redirect approach is the most popular. The pre-configured PostBack URL will be invoked for each attempted credit card transaction, providing intermediate results as the session progresses and allowing the developer to update their database with the most current progression.
Understanding Forms
Forms have four main parts:
- The Form: Configures the flow URLs, Receipt handling, page color, decline counter, card entry features, and more.
- The Headers: These html elements are used to insert graphics on the page by surrounding the form table on top and bottom.
- The Templates: Similar to headers, but are additional rows of the table that are placed before or after the form’s fields.
- The Fields: The fields are items within the form where data is displayed or entered. Some fields can be hidden and only used to communicate to the caller. Others are only used to send options to the gateway for processing (such as allow_duplicates).
Managing Forms
Forms are created and updated by selecting the Manage Forms item from the Sessions menu within slimcd.com. Forms can be exported and imported as a way to easily transfer the designs from one CLIENT ID to another. Clicking on the Manage Forms menu will list any available forms and let you create a new one. You can also import a form from this screen.
Manage Forms
You can also create new ones and edit existing designs. You can directly access the different parts of the form, such as the Headers, Templates, and Fields.
Edit Form
Select the Edit Form button or click on the name of the form to edit the form configuration. The Edit Form option has two pages, DISPLAY GRAPHICS and ADVANCED SETTINGS.
The form configuration has a number of sections. Each section allows the user to specify different aspects of the form. For ex: Form Name, Active, Version.
TableTag Information
The Table Tag Information specifies the values to insert when generating HTML. (Note that the best way to judge the effectiveness of changes is to use SHOWSESSION to see the effects and VIEW SOURCE to see where the values are inserted.
Font Tag Information
The Font Tag Information allows the developer to select font face and color for the page text, prompts, errors, and “grey” items.
The Navigation Buttons appear at the bottom of this (and most) screens. These buttons allow you to quickly and easily switch between the different editors.
Edit Form- ADVANCED SETTINGS (c)
Total Order Limits
The Total Order Limits section allows the Hosted Page to automatically stop orders less than or more than the configured amounts.
Minimum Total $ – The minimum amount allowed for an order.
Maximum Total $ – The maximum amount allowed for an order.
Card Types Accepted
The Card Types Accepted section identifies the types of cards to allow for this payment form. These include Visa, MasterCard, American Express, Discover, JCB, and Diners. (Note that JCB and Diners are now processed on the Discover network).
Card number Entry Options
The Card number Entry Options specify how card numbers and expiration dates are entered:
Card Entry Option – Card entry can be displayed as keyed, swiped, or both.
On-Screen Keypad – This option allows a keypad to be displayed instead of a normal edit field.
Card Type Option – Specifies if card types are identified automatically or must be selected.
Expiration Entry Option – Specifies how the expiration date will be entered.
CVV2/Seccode Option – Specifies how CVV2 information will be captured.
Form/Session Control Options
The Form/Session Control Options section determines the way the form operates when processing transactions. Decline Counter – indicates how many times a declined card will be allowed before the session returns control to the application. This can range from a single try to unlimited.
Duplicate Handling – indicates what to do if a DUPLICATE_DECLINE message is returned from the gateway. If the form contains a “client_transref” field and that field is pre-filled with a unique value by the developer for each transaction, we recommend that this be set to convert the DUPLICATE_DECLINE into an approval.
Display Timer – Indicates an on-screen JavaScript timer should count down to encourage the clerk to complete the transaction within the specified countdown.
Timer Seconds -Identifies how many seconds to show in the countdown timer.
Timer Action – Identifies what to do at the end of the countdown.
Hosted Page Processing
The Hosted-Page Pos Processing section allows the developer to specify the URLs to use when performing web-based server-to-server communication.
PostBack URL – Specifies the URL on the merchant’s server which will receive the responses for each credit card transaction as it is processed. Note that this URL can be called multiple times as multiple cards are attempted.
Redirect URL – This URL is used to transfer the browser’s view back to the merchant’s website at the end of processing. The target of the redirection should use the previously acquired data from the PostBack URL, or should call CheckSession to determine the approved/declined status.
Final Approval/Decline Screen Text
The Final Approval/Decline Screen Text controls the display after the credit card payment process has reached its conclusion. Note that the options for Receipt Display and the Redirect URL can cause this page to be skipped (if there is no receipt to display and there is a redirect link).
Email Options
The Email Options provide controls over emailing receipts to the consumer and/or the merchant.
Note: When sending receipts to the consumer, you must edit the FIELD containing the user’s email address and set the checkbox that identifies that field as the recipient.
Submit/Cancel Button Options
The Submit/Cancel Button Options allow configuration of the display and actions of these form buttons.
Edit Headers
The Headers are portions of the generated HTML. Some headers are actually part of the HTML, like the and tag. Others are simply HTML that is inserted into the page.
HEAD Tag
The HEAD Tag allows you to insert HTML/JavaScript between the <head> and <head> tags.
BODY Tag
The BODY Tag allows actual code to be inserted in the middle of the <body> tag itself.
The Header Text is placed after the <body> and any page logos/images (see Edit Form). The Header Text can be used to display graphics on the top and left of the <table> used to hold the form fields. If graphics is displayed on the left, use either a CSS <div> tag, or create a table in the header and have the first column contain the leftmost graphics.
Footer Text
The Footer Text is inserted after the generation of the <table> containing the form. The Footer text should place graphics on the right and/or bottom of the page.
Table Header
The Table Header is inserted after the outer table, before the table containing fields. This allows graphics to be placed inside the outermost table, but outside the fields themselves. This can also be used to split the field layout into two separate columns.
Table Footer
The Table Footer is inserted after the table containing fields. This can have trailing graphics, or can close out a table that is split into multiple columns.
The Navigation Buttons allow quick access to the other form element editors, and appear at the bottom of each page.
Edit Templates
Templates are different than headers because they appear as part of the innermost table of fields. They also support “Data Merge” where variables passed to the form can be displayed or utilized inside the page.
PreTemplate HTML
The PreTemplate HTML is inserted before the actual fields. This occurs after the HTML <table> tag, so any template text here should be formatted as a row in a 2-column table.
Payment Text
The Payment Text template controls the header text verbiage used before the “pre-fields”. Note that this can contain HTML, however this text will not support mail-merge values.
Billing Text
The Billing Text template controls the header text verbiage after the “pre-fields”. Note that this can contain HTML, however this text will not support mail-merge values.
Email Template
The Email Template is used to format the receipt to be used for sending emails. A standard format will be included. You can observe the mail-merge field names in square brackets. Mail-merge
Field Options
The Mail-merge Field Options section provides a quick legend to all of the built-in mail-merge fields. You can merge data from the merchant’s setup (company name, site name, address, etc.). You can merge data for a receipt (x-filled card number, type of card, etc.). Finally, you can merge in ANY field you have posted over, even if it does not have a formal definition.
List Fields
Fields are used to configure and control data capture in a Hosted Payment Page. The List Fields function displays the fields and provides easy visibility to see which fields are above or below the card number entry. In addition, field order can easily be adjusted. By this you can easily change the order or pre/post position of a field. Click on the pulldown to change the information.
Edit Field
Add/Edit a field lets you configure data input or storage items on the form.
Field Definition
The Field Definition identifies and activates the field.
Field Name- specifies the name of the field as it should appear in the HTML form, in CreateSession, and in CheckSession.
Active- allows a field to be enabled or disabled, if desired. Note that disabling a field simply stops it from appearing on the form.
Display Position
The Display Position settings determine where the field is displayed on the page.
Group Type – Identifies if the field is positioned before or after the card number entry area.
Display Order – Specifies the order of the fields within the group type, with lowest number first.
Form Field
The Form Field information controls the look and text for the field when generated as HTML.
The first item shows a mock-up of how the field looks when generated on the page. It shows the Prompt, the HTML Field, and the “Hint Text”.
Display Attributes
The Display Attributes section controls the look of HTML items on the form.
HTML Display Rows – Number of rows for <textarea> multi-line fields.
HTML Display Size – Width for<input> or <textarea> fields.
Data values
The Data values specify the type of data and defaults for the fields.
Data Type – Select from Text, Integer, Money or Yes/No. The selection here controls basic filtering for input and return values from some list/checkboxes.
Default Value – Enter the default value to be used if not overridden by CreateSession data.
Value Lists – Provide a list of values for ListBox or Radio Buttons, separated by semi-colons.
Form/Data Actions
The Form/Data Actionssection specifies data validation or filtering actions to take on fields when SUBMIT is pressed.
Validation Type – Select from a variety of types that include name matching logic, email logic, etc.
Value Match Field-The fieldname of another field to use when comparing the two field values for a match.
Text Scrubbing- This setting can cause ShowSession to reject input with unacceptable language.
Text Filtering – Text filtering strips input PRIOR to saving or further scrubbing. This is useful to help eliminate typographical extraneous characters (for example, quotes from phone numbers).
HTML/JavaScript Text – Any HTML or JavaScript for an individual field can be placed here, such as an OnChange ,OnBlur or other JavaScript or HTML structure.
Processing Controls
Payment Gateway – Checkbox that indicates this field should be sent to the SLIM CD gateway as part of payment processing.
SLIM CD Field Name – Name for the field when sent to the SLIM CD gateway. Note that this is only filled of the field’s name does not match the name used by SLIM CD’s gateway.
Callback – This checkbox allows the value to be included in the returned data when CheckSession is called.
Postback – This checkbox allows the value to be included in the returned data when the PostBack URL is called.
Redirect – This checkbox allows the value to be included in the returned data when the REDIRECT URL is invoked
Receipt Email Address – This checkbox allows you to identify which field to use as the “TO” address when sending email receipts.