1. Home
2. Integration Solutions
3. Integrations
4. Hosted Payment Page

1. Introduction

Our Hosted Payment Page solution offers your customers the ability to take gateway-hosted payments through your website. It is a combination of high versatility with minimum requirements:

• It’s safe: Keep a low PCI profile by outsourcing the handling of sensitive data to our platform!
• It’s flexible: Adapt our payment page to fit closer to your business
• It’s customer-friendly: Let your customers choose any of our payment methods!

The graph above graphic provides you a broad overview on the parties involved and their responsibilities in the payment process.

Before you process live transactions, feel free to use our test environment to learn our solution without costs or any commitments involved! Once you want to go live, check out here how to get a production account or contact us!

2. Get Started

To process transaction on our platform with Hosted Payment Page, make sure that

• You have a production account on our platform 
• You have at least one payment method activated in your account (Check via Configuration > Payment methods)
• You fulfil the mandatory PCI requirements
• Your website is hosted on a server that can utilise HTML forms notification. If you do not wish to develop software on you own, check out our Plugins and extensions. Any of these full-fledged solutions will help get started quickly!

3. Integrate with Hosted Payment Page

Our Hosted Payment Page channel allows you to process transactions for all payment methods we offer. Check out here how it works and what you need to do.

Understand payment flow

The graphic above explains all the steps of a typical Hosted Payment Page transaction

1. Your customer goes to your check-out pages and finalises the purchase on your check-out page
2. You send the payment request without credit card details to our Hosted Payment Page endpoint-URL composed of a set of mandatory / recommended / optional parameters. By doing so, your customer is also redirected to our Hosted Payment Page.

• (Optional) We retrieve the template to adapt the look and feel of the Hosted Payment Page

3. Your customer enters her/his credit card details on our secure Hosted Payment Page

• (Optional) We perform a Fraud check thanks to our fraud offering tools.

4. We redirect the customer to her/his issuing bank for 3-D Secure authentication
5. The cardholder identifies herself/himself. Our system receives the result from the issuer
6. Based on the result, two scenarios are possible

• If the identification was unsuccessful, we redirect the card holder to the DECLINEURL, ending the flow. You receive the result via eCommerce mode feedback channels.
• If the identification was successful, we submit the actual financial transaction to the acquirer to process the transaction

7. We return the payment result to you. Depending on the acquirer’s result, we redirect the card holder to either the ACCEPTURL / DECLINEURL / EXCEPTIONURL. You receive the result via eCommerce mode feedback channels
8. If the transaction was successful, you can deliver the goods / services

Target endpoint URLs in test / live

Our platform allows you to send requests for new transactions either to our Test environment or Live environment

Endpoint URL TEST	https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp
Endpoint URL LIVE	https://secure.ogone.com/ncol/prod/orderstandard_utf8.asp

For test transactions with no financial impact, use the Test-URL. The transactions will be sent to our test environment thereby to your test account. You will need to pre-configure your test environment to generate transaction responses.  For real transactions with financial impact, use the Live-URL. The transactions will be submitted to our live environment thereby to your live account. Make sure to switch to the LIVE-URL as soon as you have finalised your tests. Please ensure to configure the technical settings for the integration within the relevant test or live Back Office portal.

Send transaction request

Once your customer finalises the purchase on your website or implementation to complete a payment, your server makes an HTTP POST request.

Send the request to the Hosted Payment Page endpoint URL with a set of mandatory / recommended / optional and redirect your customer to this URL at the same time.

A typical request looks like this:

<form method="post" action="https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp" id=form1 name=form1>

<!-- general parameters: see Form parameters -->
<input type="hidden" name="PSPID" value="">
<input type="hidden" name="ORDERID" value="">
<input type="hidden" name="AMOUNT" value="">
<input type="hidden" name="CURRENCY" value="">
<input type="hidden" name="LANGUAGE" value="">
<input type="hidden" name="CN" value="">
<input type="hidden" name="EMAIL" value="">
<input type="hidden" name="OWNERZIP" value="">
<input type="hidden" name="OWNERADDRESS" value="">
<input type="hidden" name="OWNERCTY" value="">
<input type="hidden" name="OWNERTOWN" value="">
<input type="hidden" name="OWNERTELNO" value="">

<!-- check before the payment: see Security: Check before the payment -->
<input type="hidden" name="SHASIGN" value="">
<!-- layout information: see Look and feel of the payment page -->
<input type="hidden" name="TITLE" value="">
<input type="hidden" name="BGCOLOR" value="">
<input type="hidden" name="TXTCOLOR" value="">
<input type="hidden" name="TBLBGCOLOR" value="">
<input type="hidden" name="TBLTXTCOLOR" value="">
<input type="hidden" name="BUTTONBGCOLOR" value="">
<input type="hidden" name="BUTTONTXTCOLOR" value="">
<input type="hidden" name="LOGO" value="">
<input type="hidden" name="FONTTYPE" value="">

<!-- post payment redirection: see Transaction feedback to the customer -->
<input type="hidden" name="ACCEPTURL" value="">
<input type="hidden" name="DECLINEURL" value="">
<input type="hidden" name="EXCEPTIONURL" value="">
<input type="hidden" name="CANCELURL" value="">
<input type="submit" value="" id=submit2 name=submit2>

</form>
    

Send mandatory / recommended / optional parameters

You need to include a set of parameters for every transaction. Find detailed information (short description, format, maximum length and so on) for each parameter in our Parameter Cookbook.

Have a look at the mandatory, recommended and optional parameters for a typical transaction request:

Mandatory

Parameter	Description / Possible values
PSPID	The name of your account on our platform to which you send the transaction request.
ORDERID	A unique order number for each request. The parameter ORDERID is used to check whether requests are accidentally sent twice to our platform. If two transactions with the same value for ORDERID are sent within 45 days, we will block the second transaction. This check applies only if the first transaction’s PAYIDSUB has reached one of the following statuses: 2 5 9  Consequentially, an ORDERID can be used only once within 45 days. After that period, ORDERIDs already sent can be re-used
AMOUNT	Amount to be paid by your customer Multiply the amount by 100 as this parameter must not contain any decimals or other separators Example: If the order is 12,34 € / £ etc., you need to send AMOUNT=1234
CURRENCY	Currency of the amount in ISO 4217 format (ie GBP)
LANGUAGE	The language our Hosted Payment Page is displayed to your customer. The value is a combination of ISO 639-1 (language) and ISO 3166-1 (country) Examples: en_US fr_FR Find a full list of all language we support in our Parameter Cookbook.
SHASIGN	Unique character string for order data validation. It is used to make sure that the transaction request is indeed from your server and has not been manipulated by an unauthorised third party. Click here for additional information.

Recommended

EMAIL	Your customer’s address / contact data
OWNERADDRESS
OWNERZIP
OWNERTOWN
OWNERCTY
OWNERTELNO
TP PMLISTTYPE	Modify the look and feel of the Hosted Payment Page Click here for more information

Optional

COMPLUS	Fields to send any additional data you would like to receive in the transaction feedback Click here for more information
PARAMPLUS
PM	Make specific payment methods (un)available on the Hosted Payment Page or redirect your customers directly to third-party payment method services (ie. Paypal, iDEAL etc.) Click here for more information
BRAND
PMLIST
EXCLPMLIST
CREDITDEBIT
OPERATION	Override the default operation code in your Back Office for each transaction  Click here for more information
USERID	Link transactions to a specific user in your data bases Click here for more information
ACCEPTURL DECLINEURL  EXCEPTIONURL CANCELURL HOMEURL  CATALOGURL  BACKURL	URLs to receive transaction feedback and to redirect your customers depending on the outcome Click here for more information

Calculate SHASIGN value

An integral part of the transaction flow is to ensure that transactions sent to our platform are legitimate.

To rule out that an unauthorised third party has manipulated any of your transaction request, we use a method that is both safe and easy for you to implement: by sending the parameter SHASIGN. The SHASIGN is a unique character string that can only be constructed by two parties: You and Worldline.

The string is based on data sent along with the transaction and security settings in your Back Office. These settings are only accessible to both you and Worldline. For each transaction, our system will reconstruct the string sent in SHASIGN. If both strings match, our platform considers the transaction of legitimate origin and will process it.

Construct the value for SHASIGN following these rules

1. Concatenate all parameters / values to one string according to this formula

Parameter name + = + parameter value + SHA-IN passphrase

You must ensure that

• Use the SHA-IN passphrase as defined in your Back Office in Configuration > Technical Information > Checks for e-Commerce & Alias Gateway > SHA-IN pass phrase
• Include all parameters (and only these) our system takes into account and to sort them alphabetically as defined in this list
• Normalise the data (ie remove leading / trailing spaces)
• To not send empty parameters: Include only gateway-specific parameters with an associated value

An example (using only mandatory parameters) looks like this:
Parameters from the transaction request

_{AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID}

SHA-IN passphrase as defined in Back Office

_{Mysecretsig1875!?}

Concatenated string:

_{AMOUNT=1500Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?LANGUAGE=en_USMysecretsig1875!?
ORDERID=1234Mysecretsig1875!?PSPID=MyPSPIDMysecretsig1875!?}

2. Hash the concatenated string according to the selected hashing method in your Back Office in Configuration > Technical Information > Global security parameters > Hash algorithm

Resulting digest (for SHA-1 method):

_{F4CC376CD7A834D997B91598FA747825A238BE0A}

3. Send your transaction request including the digest in parameter SHASIGN

Parameters from the transaction request

_{AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID}

_{SHASIGN=F4CC376CD7A834D997B91598FA747825A238BE0A}

As soon as we receive a transaction request, we recalculate the string according to the parameters you sent and the SHA-IN passphrase / Hash method as defined in your Back Office.

If we get the same value you sent, we will redirect the customers to our Hosted Payment Page, allowing your customers to enter their credit card details.

If there is a mismatch, we redirect the customer to an error page, abandoning the transaction.

For troubleshooting, please contact the support team and request for the error log debug to be enabled on the account for up to 8 hours within the test and live environments. Then process another test and check the Back Office within Configuration > Error. Any SHA hashing errors will be recorded as ‘Unknown order/1/s’. When a failed test has been attempted while the debug is active, the system will also display the SHASIGN you sent and the one our system constructed from the name/ value pairs submitted. This will allow you to review your SHASIGN calculation for errors. Please refer to the Troubleshooting guide for more information.  

Do not include empty parameters in the concatenated string Use upper case letters for parameter names URL-decode the string-to-hash before you calculate the hash All characters in the concatenated string must be in upper case Although we support hashing methods SHA-1 / SHA-256 / SHA-512, we recommend using SHA-256 or SHA-512. This will provide maximum security for the verification process. For extra safety, we request that you use different SHA passphrases in our Test environment and  Live environment

Define Back Office settings

To successfully process transactions, you also need to define some settings in your Back Office. They are in different tabs under Configuration > Technical information.   

Please review the below mandatory, recommended and optional settings. 

Mandatory

Back Office module	Description / function
Global Security parameters > Hashing method > Hash algorithm	Define the hashing method for the concatenated string to calculate the SHASIGN value
Data and origin verification > Checks for e-Commerce & Alias Gateway > SHA-IN pass phrase	Define the SHA-IN passphrase that is added to the concatenated string to calculate the SHASIGN value

Recommended

Back Office module	Description / function
Global transaction parameters > Payment retry	Attempts per transaction request you grant your customers to successfully finalise their payment. After the last try fails, the transaction reaches status 2.
Global transaction parameters > Processing for individual transactions	Our platform offers you to time the payment requests we send to our acquirers in three different ways. Select the one that fits business model best: Always online (Immediate): We send the transaction right after we receive the request from you. If the acquirer is unavailable, the transaction reaches status 2. Appropriate for goods/services you need to deliver right after the purchase Online but switch to offline when the online acquiring system is unavailable: ): We send the transaction right after we receive the request from you. If the acquirer is unavailable, we will try to recover it by resending it at a later time. Appropriate for goods/services for which a time gap between purchase and delivery is acceptable Always offline (Scheduled): We send the transaction at specific cut-off times (around 4hrs after you have sent it). As your customer will not have to wait for the real-time result, the purchase is faster finalised than the other methods. Consequentially, both you and your customer receive a final transaction status with a delay of several hours. Appropriate for goods/services for which a time gap between purchase and delivery is acceptable
Transaction feedback > eCommerce > HTTP redirection in the browser	Define the URLs your customers are redirected to depending on the result. Learn more in our dedicated chapter.
Transaction feedback > eCommerce > Direct HTTP server-to-server request	Define the URLs and the timing when you wish to receive transaction feedback. Learn more in our dedicated chapter.
Transaction feedback > eCommerce > Dynamic e-Commerce parameters	Select the parameters you wish to be included in the transaction feedback. Learn more in our dedicated chapter.
Transaction feedback > eCommerce > All transaction submission modes > Security for request parameters	Define a SHA-OUT pass phrase to validate the transaction feedback’s origin. Learn more in our dedicated chapter.
Transaction feedback > eCommerce > All transaction submission modes > HTTP request for status changes	Define the URL and the timing when you wish to receive feedback for transactions status changes after the initial purchase. Learn more in our dedicated chapter.
Global transaction parameters > Default operation code	Define whether our platform should process your transactions as authorisations (status 5) or direct sales (status 9) at the timing of the request. Learn more in our dedicated chapter

Optional

Back Office module	Description / function
Global transaction parameters > Default data capture (payment) procedure	Define the method and the timing to capture status 5 transactions. Learn more in our dedicated chapter
Payment page > Cancel button	Make a button on our Hosted Payment Page appear / disappear that allows your customers to abandon the transaction
Payment page > Back button redirection	Define the URL your customers are sent to when clicking on the “Back” button on our Hosted Payment Page
Payment page > General terms and conditions	Make a link to your general terms and conditions appear on our Hosted Payment Page
Transaction e-mails > E-Mails to the merchant	Define whether you wish to receive e-mails from our system for processed transactions. Learn more in our dedicated chapter
Transaction e-mails > E-mails to the customer	Define whether your customers should receive e-mails from our system for processed orders Learn more in our dedicated chapter

4. Customise payment page look and feel

Our platform allows you to adapt the look and feel of our Hosted Payment Page to a great extent. Adapting the payment page to your corporate identity will encourage your customers to finalise their order after they are redirected to the Hosted Payment Page.

Have a look at all our payment page recommendation to optimise your business!

Learn here how to use this feature and the manifolds ways to enhance your customer’s payment experience.

Using our platform to host templates will not change your PCI level. If you choose to host the template on your own, you might be required to fulfil a higher PCI level. Contact your acquirer for detailed information.

Use Worldline Responsive Payment Page template

The easiest way to modify our Hosted Payment Page is using our Responsive Payment Page template (RPP). It is perfect for a multi-screen online shopping experience for your customers. It ensures you an optimised conversion on both desktop and mobile devices.

To give you an easy start and to learn about all its possibilities, we provide you with a complete demo template. Follow these steps to use it

1. Download the zip file.
2. Login to the Back Office. Go to Configuration > Template > Template selection > eCommerce payment page and click on “ACTIVATE”.
3. Go to Configuration > Template > File Manager > Upload Template Files. Upload the whole content from the zip file. After a couple of minutes, our system has validated the files (In “Uploaded Files”, they appear as “Validated” in column “Status”). They are now ready to be used on our Hosted Payment Page
4. Go to Configuration > Template > Template selection > eCommerce payment page. Select the HTML file “WorldlineResponsivePaymentPageTemplate_index.html” from the dropdown menu “Default merchant template”.
   

For our Responsive Payment Page template, you need to arrange the display of the payment methods in a vertical order. You can achieve this by sending the additional parameter PMLISTTYPE=2 for each transaction We recommend that you limit the size of your logos to 300px for both width and height. This will ensure that the loading time on mobile devices is kept to a minimum

Create individual Responsive Payment Page templates

Our platform also allows you to modify the demo file completely at your liking and thereby create templates by yourself from scratch and to set up templates to be used based on specifics occasions, like Black Friday or End of Year seasons.

Include these elements to do so:

• HTML file: The basis for every template (just like “WorldlineResponsivePaymentPageTemplate_index.html"from the demo file).
  The template page can be designed completely to your liking. The only requirement is that it must contain the placeholder string "$$$PAYMENT ZONE$$$":
  
  

<html>$$$PAYMENT ZONE$$$</html>

This placeholder is reserved space for the fields your customers enter their credit card data. You can modify the elements in this space by using a CSS file.
You can include the following file types in your template: .css, .jpg, .jpeg, .gif, .png, .html, .js.
Use “ $$$TP RESOURCES URL$$$/[your file name]” to reference them in the file.

<html><head>        <link rel=”stylesheet” type=”text/css” href=”$$$TP RESOURCES URL$$$/yourFile.css”>        <script scr=”$$$TP RESOURCES URL$$$/test.js”></script></head><body><div>$$$PAYMENT ZONE$$$</div></body></html>

Be sure to upload all references files in the Back Office via Configuration > Template > File Manager > Upload Template Files.

Do not use BASE tags, frames or FORM tags to encapsulate the $$$PAYMENT ZONE$$$ string.

CSS file: You can use style sheets to adapt both your elements in the HTML file and the reserved space for the fields your customers enter their credit card data. To adapt the latter, we have defined a class for the various elements in this space. You need to add the following block of code between the tags <head></head> and change the properties of those classes to fit to the look and feel of your site:

<style type="text/css"><!--td.ncolh1 {background-color : #006600; color : yellow; font-family : verdana}td.ncoltxtl {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}td.ncoltxtl2 {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}td.ncoltxtr {background-color : #ffffcc; color : black; text-align : left; font-weight : bold}td.ncoltxtc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}td.ncolinput {background-color : #ffffcc; color : black}td.ncolline1 {background-color : #ffffff; color : black}td.ncolline2 {background-color : #ffffcc; color : black}
input.ncol {background-color : #006600; color : white}td.ncollogoc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}table.ncoltable1 { background-color: #ffffcc; }table.ncoltable2 { background-color: #ffffcc; border-width : medium; border-color : green; }table.ncoltable3 { background-color: #ffffcc; }--></style>

These screenshots of the payment selection screen, the payment form and the result page show which elements exactly you can modify with the properties.  

As with the HTML file, you can reference files in your CSS. Instead of “ $$$TP RESOURCES URL$$$/[your file name]”, use simply "./[your file name]”

Make sure to stick to the established cascading style sheet syntax. Test your CSS it in various browsers, as the way they handle style may differ

Create mobile templates

Although the Responsive Payment Page template is suitable for all devices, we also offer you specialised files to enhance the payment experience on mobile devices. Take a look at the branded one and the “stripped” version. You can download both here.

The basis for both versions is a HTM file called “StandardMobileTemplate” and “StandardMobileTemplate_Generic” respectively.  Unlike the standard Responsive Payment Page template, it is a combination of an HTML and CSS file. The CSS properties are located as follows:

Example screenshot	Properties
The header part of the payment page:	.securedBG{background: #797979;}.secured{padding: 8px 20px 0px 40px;color: #ffffff;width: 235px;margin: 0 auto;background: url("lock.png") 5px no-repeat #797979; height: 30px; }- Order Summarytable.ncoltable1{width: 100%;margin: 0 auto;min-width: 300px !important;}td.ncoltxtl{font-family: open-sans ,Verdana,sans-serif;font-size: 14px;background-color:#ffffff;text-align : left !important;font-weight : bold !important;vertical-align:bottom;}td.ncoltxtr{text-align: left;font-weight: normal;font-family: open-sans ,Verdana,sans-serif;font-size: 14px;background-color:#ffffff;}
The payment detail section the customers enter their credit card details:	td.ncolinput{text-align: left;font-weight: normal;font-size: 14px;font-family: open-sans ,Verdana,sans-serif; display: block;box-shadow: none !important;}input.ncol{background-color: #ffffff;height: 40px;font-size: 14px;text-align: center;padding: 0px;font-family: open-sans ,Verdana,sans-serif;margin: 0 35px 20px;border-bottom: 1px solid #999999;border-radius: 0px;-webkit-appearance: none !important;-webkit-border-radius: 0 !important;}td.ncoltxtl2{text-align: left;font-family: open-sans ,Verdana,sans-serif;white-space: nowrap;display: block; font-size: 14px;background-color:#ffffff;}
The footer part of the payment page:	td.ncollogoc{text-align: center;font-weight: normal;font-size: 14px;padding: 2px;vertical-align: top !important;}td.ncollogoc IMG{width: 90px;height: 55px;margin-right: 4px;}.ncollogoc td .ncol{width: auto;padding-right: 10px;padding-left: 10px;cursor:pointer;}.ncollogoc input.ncol{margin-top:10px !important;-webkit-appearance: none !important;-webkit-border-radius: 0 !important;}
The payment status page your customers are redirected after the validation of the credit card details:	td.ncoltxtc{background-color:#ffffff;color:#999999;padding: 0px;text-align: left;font-weight: normal;font-size: 14px;border-top: 0px solid #ffffff;font-family: open-sans ,Verdana,sans-serif;}td.ncoltxtc h3</code{text-align: center;font-weight: normal !important;padding: 5px;font-family: open-sans ,Verdana,sans-serif;}td.ncoltxtmessage{background-color: #ffffff;color: #999999;text-align: left;font-weight: normal;}

Use multiple templates

You can upload multiple templates to the Back Office and reference them for transactions individually.

Per default, the template selected in the Back Office in Configuration > Template > Template selection > eCommerce payment page > from the dropdown menu “Default merchant template” will be used for every transaction. However, you can override this setting by sending an additional parameter with your transaction request

Parameter	Description / Possible values
TP	By sending the file name of any of your HTML files uploaded in the Back Office (Configuration > Template > File Manager > Uploaded files), you can select a specific template for the transaction Example: “myTemplate.html”

Use Dynamic template

Our platform also allows you to adapt our Hosted Payment Page by hosting a template on your own server.

Creating the HTML/CSS follows the same process as described in the previous chapter. However, as you do not upload the template in the Back Office but host it on your own, some differences apply

• To instruct our system to load the template from your server, you must send an additional parameter for all of your transaction requests:

Parameter	Description / Possible values
TP	The URL of the dynamic template page The URL must be absolute (contain the full path) and cannot be relative. Do not specify any ports in your URL, we only accept ports 443 and 80. Any component included in the template page must also have an absolute URL.

• Although you can use the same template page for all orders (or vary it by sending parameter TP), your application can generate it dynamically according to the order parameters. To achieve this, use a fixed template URL returning a result derived from the order number. Our system adds the main payment data – including the merchant’s order reference number – when it retrieves the template page:

HTTP request = url_page_template?ORDERID=...&AMOUNT=...&CURRENCY=…

If you choose to host the template on your own, you might be required to fulfil a higher PCI level. Contact your acquirer for detailed information As loading the template from your server takes more time to load from our own, the overall payment process takes longer. Our system is configured with a 5-second time-out for the request to retrieve the dynamic template. Contact our support team to change the duration of the time-out. If one of your elements used in the dynamic template page is not hosted on a secure server, most browsers will not recognise the connection to our platform as secure. Therefore, we strongly encourage you to host all your files on a secure server

Enable template security control

To protect your customers from fraud, we have established several security checks for the template.

Login to the Back Office and go to Configuration > Template > Advanced configuration. You can adapt the following settings

• Go to Global > Enable JavaScript check on template
  When activated, our platform checks whether JavaScript is used on the template page. If JavaScript is detected, we will block the template and use a default template instead
• Dynamic template 

If you select “Yes” for “Allow usage of dynamic template”, you need to configure one or more trusted website name(s) hosting the dynamic template. If you enter multiple ones, separate them by semicolon (“;”). Make sure to add the full URL domain path (sub directories where the template is located can be left out).
For each transaction, our system compares the value sent in parameter TP with the website names configured in the Back Office. In case of a mismatch, we block the dynamic template and load a template you have uploaded in the Back Office instead. If you have not uploaded any template, our system will load a default template instead.  

5. Redirect customer after purchase

After your customer has entered her/his credit card details, we send the data to the acquirer for validation. Once we receive the result, we redirect your customer on a page of your choice.

For each scenario, you can define a separate URL. Calculate SHASIGN value

You have two options to define these URLs:

1. Via the Back Office: Go to Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser.Enter a URL in the field for the respective scenario:

Field	Description
Accepturl	Successful transactions (status 5, 41 or 9)
Declineurl	Declined transactions (status 2)
Exceptionurl	Cancelled transactions (status 1)
Cancelurl	Transactions with an uncertain result (status 51 or 92)

2. Send the following additional parameters for every transaction request:

Parameter	Description / Possible values
ACCEPTURL	Successful transactions (status 5, 41 or 9)
DECLINEURL	Declined transactions (status 2)
CANCELURL	Cancelled transactions (status 1)
EXCEPTIONURL	Transactions with an uncertain result (status 51 or 92)

If you have defined URLs as described in option 1. and also send values for the parameters as described in option 2., the URLs in the Back Office will be overwritten by the parameter values. If any of your URLs does not comply with the HTTPS protocol but with the HTTP protocol only, your customer might get a browser alert about entering a non-secure environment. For such cases, we can display a notification to your customers right before the redirection takes place. Activate it in the Back Office via Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser by flagging “I would like Worldline to display a short text to the customer on the secure payment page if a redirection to my website is detected immediately after the payment process.” If any of your server-to-server feedback URLs (as configured in your account under Configuration > Technical Information > Transaction Feedback > Direct HTTP server-to-server request) replies with a text, plain HTML code or a HTTP 302 redirection command, our system will show the page as-is to your customer. Neither of the redirection URLs (ACCEPTURL etc.) will be shown to your customers.

If you choose neither of the options, we redirect your customers to one of our generic result pages instead. The pages will state the result in the respective language you have sent with parameter LANGUAGE (ie. “Authorised” for status 5).

You can add a catalogue and / or home URL on our result page you can redirect your customer to.  This requires you to send the following parameters along with the transaction request

Parameter	Description / Possible values
CATALOGURL	URL of your catalogue   If sent, a “Back to our catalouge” button will be visible on our generic result page
HOMEURL	URL of your home page   If sent, a “Back to merchant site” button will be visible on our generic result page   Can also be defined in the Back Office via Configuration > Technical Information > Payment page > Back button redirection, but will be overwritten if you send this parameter If you send the value "NONE", the button is not displayed

6. Get transaction feedback

To keep track of the transaction results, our platform offers multiple ways to send feedback to your server. You can use this information to access the transaction at a later point to perform maintenance operations (i.e. a refund) at a later point.

Select feedback parameters

Depending on your database’s requirements, you can define exactly what kind of information you want to receive. As we send the feedback by individual parameters, you can select them freely in the Back Office:

• Go to Configuration > Technical Information > Transaction feedback > eCommerce > Dynamic e-Commerce parameters
• Move the parameters you would like to receive in the feedback from the “Available” box to the “Selected” box. The following parameters will always be included in the feedback and cannot be deselected:

NCERROR

PAYID

ORDERID

STATUS

Calculate SHASIGN value for feedback requests

In the same way we validate requests from your server, you can also validate the origin of our feedback.

To ensure that the received feedback is legitimate and not an intrusion from a third party, we offer you to send a digest based on the parameters sent in the feedback. By recalculating this digest based on these parameters on your own, you can easily verify the legitimacy of the feedback.

The way this digest is calculated follows the same principle as described in this chapter. As some differences apply, have a look at the following summary of all steps:

1. The feedback your server receives includes a parameter called SHASIGN, containing the digest

To recalculate the digest, concatenate all parameters / values to one string according to the formula

Parameter name + = + parameter value + SHA-OUT pass phrase

Make sure to

• Use the SHA-OUT pass phrase as defined in your Back Office in Configuration > Technical Information > Transaction feedback > All transaction submission modes > SHA-OUT pass phrase
• Include all parameters (and only these) our system takes into account and to sort them alphabetically as defined in this separate SHA-OUT parameter list
  
  

2. Hash the concatenated string according to the selected hashing method in your Back Office in Configuration > Technical Information > Global security parameters > Hash algorithm
   
   
3. Compare you digest with the one you received from us. If you have a match, you have the confirmation that the received feedback is legitimate

This feature is optional, as the server request is a closed loop with additional security layers (TLS / HTTPS / IP filters on your server - please check our Firewall documentation for that) If you still want to use this feature, make sure to configure a SHA-OUT pass phrase. Otherwise, we will not send a digest in the feedback

Get feedback

After you have selected the feedback parameters and defined a SHA-OUT, you are ready to receive feedback. Our platform offers you two ways:

1. Receive feedback on redirection URLs: As soon as your customers end up on one of these URLs, we send a GET request accordingly. To use this option, set the following flag in Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser:

This option will only work if your customers close their browser after the redirection is completed. To be independent of your customers’ behaviour, we offer a second option as described below

 2. Receive server-to-server feedback: You can define separate URLs and a choose a time spot to receive the feedback. To use this option, go to Configuration > Technical Information > Transaction feedback > eCommerce > Direct HTTP server-to-server request. Define the following:

Timing of the request Always deferred (not immediately after the payment). Online Online but switch to a deferred request when the online requests fail.	Get feedback either 10 minutes after the purchase Right after the purchase Right after the purchase or 10 minutes after the purchase should the initial feedback transfer fail
If the payment's status is "accepted", "on hold" or "uncertain".	Get feedback for transactions that end up in status 5 / 9 or 51 / 91 on an URL of your choice
If the payment's status is "cancelled by the client" or "too many rejections by the acquirer".	Get feedback for transactions that end up in status 1 or 2 on an URL of your choice
Request method	Get feedback as GET or POST

 

To ensure that your server accepts our feedback, make sure to set up your firewall correctly For timing options “Always deferred” and “Online but switch to a deferred request […]” our platform will try four times to send you the feedback should we be unable to send the feedback in the first place For security reasons, we recommend selecting POST over GET

Get feedback for subsequent status changes

In some cases, your transactions’ status will change at a later point after the initial purchase. To get feedback for these so-called “offline” status changes, go to Configuration > Technical Information > Transaction feedback > All transaction submission modes > HTTP request for status change. Define the following:

Timing of the request Only at the time of the order authorisation request For each offline status change (payment, cancellation, etc.).	Get feedback either For transactions with initial status 5 or 51 / 52 For transactions with one of the following initial statuses: 5 / 51 / 52 91 / 92 61 / 62 81 / 82 91 / 92
URL on which the merchant wishes to receive a deferred HTTP request, should the status of a transaction change offline.	Get the feedback on an URL of your choice

Resend feedback

In some cases, a redirection / feedback request is not performed properly. This can happen i.e. if your customers click on the back button in their browser. To avoid confusion on your customers’ side and to ensure you get the feedback after all, flag go to Configuration > Technical Information > Transaction feedback > General  and flag “I would like Worldline to re-launch the "end of transaction" (post-payment request/redirection) process if required.” This will ensure that

• Your customers ends up on the proper redirection URL after the purchase
• You receive the feedback on your URLs

7. Secure payment with 3-D Secure

An important part of the transaction processing flow for your customer is the 3-D Secure (3DS). There is no effort for you involved, except having 3DS active on all your card payment methods, and we will take care of everything necessary.

Following the introduction of 3DSv2, new rules apply. Although we collect all relevant data for you during the payment process, you can still make the 3DSv2 approach to risk evaluation more effective. You can achieve this by sending additional parameters along with the transaction.

Have a look on the recommended and optional parameters for a typical transaction request. These parameters need to be included in the SHA-calculation.

PSD2 enhances the transparency of the payment process for you and your customers. This is especially helpful when dealing with status 2 transactions.
Our feedback parameter CH_AUTHENTICATION_INFO provides you with detailed information from the issuers when they reject your customers' transactions.
Share this information with your customers to help them understand why their bank declined their transaction.

To receive CH_AUTHENTICATION_INFO in your redirection URLs, select this parameter in the Back Office via Configuration > Technical information > Transaction feedback > Dynamic e-Commerce parameters. This will also ensure that this information is visible in the transaction overview via Operations > View transactions / Financial history.
As you will not receive the information early enough to modify your redirection URLs accordingly once a transaction is finalised, we recommend flagging "I would like Worldline to display a short text to the customer on the secure payment page if a redirection to my website is detected immediately after the payment process." in the Back Office via Configuration > Technical information > Transaction feedback > eCommerce > HTTP redirection in the browser. Our platform will then redirect your customers to our intermediate result page showing the information before your customers end up on your redirection URLs eventually.

7.1 Exclusions and exemptions for 3DSv2

Some transactions are excluded from SCA. If any of your transactions are among them, 3-D Secure will not be rolled out. For more information which type of transaction they are, consult our dedicated guide here. 

You can request to omit 3-D Secure in two ways

1. Authentication by selecting the appropriate values for Mpi.threeDSRequestorChallengeIndicator and 3DS_EXEMPTION_INDICATOR
   

   Parameter	Values
   Mpi.threeDSRequestorChallengeIndicator	Length: 2 characters Data Type: String Values accepted: 01 = No preference 02 = No challenge requested - use this value for low amount transactions (below 30 euros) 03 = Challenge requested: merchant Preference 04 = Challenge requested: Mandate - use this value when setting up a recurring transaction with your customer or when retrying the transaction after soft decline 05 = No Challenge Requested [transactional risk analysis is already performed] use this value if your acquirer agreed on TRA exemptions with you 07 = No Challenge Requested [SCA is already Performed] use this value when you do the SCA on your side, has to be approved by your acquirer
   3DS_EXEMPTION_INDICATOR	Length: 2 characters Data Type: String Values accepted: 03 = Issuer TRA* 04 = Low amount exemption (below 30 euros) 05 = Merchant/Acquirer TRA* 06 = White Listing 07 = Corporate 08 = Delayed Shipment 09 = Delegated authentication (certified wallet) * Transaction risk analysis

   Check out the authentication log in the Back Office and search for “TransStatus = I” to see if the issuer has granted the exemption. However, you will loose the liability shift in a case of a fraudulent transaction

2. Authorisation by selecting the appropriate 3DS_EXEMPTION_INDICATOR and FLAG3D
   To skip 3-D secure altogether, send the following parameters:
   
   

   Parameter	Values
   FLAG3D	N = Skip the 3DS authentication process
   3DS_EXEMPTION_INDICATOR	Length: 2 characters Data Type: String Values accepted: 03 = Issuer TRA* 04 = Low amount exemption (below 30 euros) 05 = Merchant/Acquirer TRA* 06 = White Listing 07 = Corporate 08 = Delayed Shipment 09 = Delegated authentication (certified wallet) * Transaction risk analysis

   
   However, it is still up to the issuer whether an authentication process must take place. In case the issuer insists on 3DS, the transaction will be declined with error code 40001139.
   If transaction is accepted without 3-D Secure, you will loose the liability protection.
   
   When your customers are setting up a new recurring payment with you, under the PSD2 rules, the first transaction always have to be strongly authenticated. Submit all the relevant 3DS parameters, COF parameters together with Mpi.threeDSRequestorChallengeIndicator=04. This will make sure that the issuer is aware of this request and will approve the transaction

Frictionless / challenge flow

If you do not want to request an exemption but rely on the issuers rolling out a frictionless flow and keep your liability protection, send some additional parameters.
Sending these parameters for these schemes raise the chance for a frictionless flow:

• Carte Bancaire (if you are on low risk merchant program, they are strongly required)
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  Mpi.HomePhone.countryCode
  Mpi.HomePhone.subscriber or Mpi.MobilePhone.subscriber
  Mpi.shippingIndicator
  REMOTE_ADDR
  
  
• MasterCard
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  Mpi.HomePhone.countryCode
  Mpi.HomePhone.subscriber or Mpi.MobilePhone.subscriber
  ADDMATCH
  REMOTE_ADDR

You can even increase the chance of a frictionless flow and a higher conversion rate by sending more optional parameters.

Soft Decline

A typical flow of a soft declined transaction looks like this:

1. In your first request, send FLAG3D=N together with the appropriate value for 3DS_EXEMPTION_INDICATOR and no further authentication parameter. This way you indicate that you wish to skip 3-D Secure. The transaction might be accepted already now.
   If it is rejected by your customer’s bank because it insists on 3-D Secure, we will indicate this in the feedback parameter by sending NCERROR=40001139. The transaction will be put in status 2.
2. To recover this declined transaction, resubmit the transaction by sending the following parameters to our platform
   
   1. The standard request for Hosted Payment Page / DirectLink parameters as sent in your first request as a new order
   2. FLAG3D=Y to indicate 3-D Secure needs to be rolled out
   3. The 3DSv2 authentication parameters as described here
   4. Mpi.threeDSRequestorChallengeIndicator=04 to indicate that your customer’s bank insists on 3-D Secure following the Soft Decline

Your customer will have to pass the 3-D Secure authentication during this second request. Finally, the transaction will reach either status 2 or 9. This depends on both whether your customer passed the authentication and the payment is accepted by both your and your customer’s bank.

Soft Decline is currently available for payment methods Visa, MasterCard, American Express and Carte Bancaire.

7.2 Test cards

You can use the following test card to simulate a 3-D Secure registered card in our test environment:

Frictionless Flow
Brand	Card number	Expiry date
VISA	4186455175836497	Any date in the future
Mastercard	5137009801943438	Any date in the future
American Express	375418081197346	Any date in the future
Carte Bancaire	4150557357382737	Any date in the future

Challenge Flow
Brand	Card number	Expiry date
VISA	4874970686672022	Any date in the future
Mastercard	5130257474533310	Any date in the future
American Express	379764422997381	Any date in the future
Carte Bancaire	4150550997933993	Any date in the future

More test cards numbers can be downloaded here.

7.3 Get overview on 3-D Secure transactions

To keep track on your transactions and their 3-D Secure results, we offer you a way to access your 3DS report from the Back Office.

Have a look at this video explaining how to set up your report quickly and easily.

8. Use additional possibilities

Our Hosted Payment Page offers many more features. They make this solution even more adaptable to your individual needs and offer you additional possibilities to make your business thrive.

Process transactions via Alias Manager

As with all our solutions, you can use our Alias Manager to create, store and update card data with Hosted Payment Page. Check out our dedicated chapter to make your customer journey even more conventient and seamless!

Receive and send e-mails for orders

Our system can send order confirmation emails to both you and your customers once a payment has been finalised. To use this option, go to Configuration > Technical Information > Transaction e-mails > E-mails to the merchant / E-mails to the customer. Make the following selection

• E-mails to the merchant

E-mail address(es) for transaction-related e-mails	Your email address(es) to which the e-mails are sent to.
Receive transaction confirmation e-mails Yes, but only for e-Commerce transactions. Yes, for all transaction submission modes.	Get e-mails for transactions you process via Hosted Payment Page Any other of our solutions
Receive e-mails in the event of offline transaction status changes Yes, but only at the time of the order authorisation request. Yes, for each offline status change (payment, cancellation, etc.).	Get e-mails For transactions with initial status 5 or 51 / 52 For transactions with one of the following initial statuses: 5 / 51 / 52 91 / 92 61 / 62 81 / 82 91 / 92

 

• E-mails to the customer

Support E-mail address to include in transaction-related e-mails	Include your email address in the e-mail
Support Phone number to include in transaction-related e-mails	Include your phone number in the e-mail
I would like Worldline to send a transaction confirmation e-mail to the customer. I would like Worldline to send a transaction confirmation e-mail to the customer at the time of the capture. I would like Worldline to send a transaction confirmation e-mail to the customer at the time of the refund.	You customers receive emails for transactions that receive status 5 or 9 after their purchase receive status 9 after a capture request (status 91) status 8 after a refund request (status 81)

Send payment link via e-mail

Instead of redirecting your customers to our payment page in real-time, you can let your customers choose to enter their credit card data anytime they want!

You can achieve this by sending your customers an e-mail, containing either the request as

• POST: an HTML form with hidden HTML fields to send us the necessary parameters
  This HTML form works in the same way as shown in our example for your webshop checkout page
  
  
• GET: a link consisting of the endpoint and the necessary parameters added to it:
  https://ogone.test.v-psp.com/ncol/test/orderstandard.asp / orderstandard_utf8.asp?PSPID=TESTSTD&OrderID=order123&amount=12500¤cy=EUR&SHASIGN=8DDF4795640EB9FE9B367315C48E47338129A4F5& …

In both cases, your customers end up on our secure payment page as described in step 2 in our payment flow overview, starting the payment flow at that point.

Preselect payment methods available on eCommerce

By default, our platform will display all payment methods on the Hosted Payment Page that are active in your Back Office (Configuration > Payment methods). Sending one or more of the following parameters along with your transaction requests defines the list of available payment methods on the payment selection screen.

Find detailed information (short description, format, maximum length and so on) for each parameter in our Parameter Cookbook.

Parameter	Description / Possible values
PM	Payment method (ie. Visa) or payment method group (ie. credit cards) To display only one specific payment method on the Hosted Payment Page, send this parameter together with the according value for BRAND: PM=CreditCard BRAND=VISA If the payment method belongs to a third-party payment method services (ie. Paypal, iDEAL etc.), we will redirect your customer directly to the respective homepage, omitting a redirection to our Hosted Payment Page To display a payment method group (ie. credit cards), send only this parameter: PM=CreditCard Find a list of all accepted values.
BRAND	Specifies the payment method brand (ie. VISA) from the payment method group (ie. credit cards) as defined by PM Find a list of all accepted values.
PMLIST	Define a list of available payment methods on the Hosted Payment Page. Combine multiple values of parameter PM (separate them by  a “;” (semicolon)): PMLIST=VISA;iDEAL Find a list of all accepted values for parameter PM.
EXCLPMLIST	Define a list of payment methods that should not be available on Hosted Payment Page Combine multiple values of parameter PM (separate them by  a “;” (semicolon)) EXCLPMLIST= VISA;iDEAL Find a list of all accepted values for parameter PM.
CREDITDEBIT	Split payment methods Visa and MasterCard as separate credit and debit payment methods. This allows your customers to choose either of them by sending it along PM / BRAND: C: offer payment method as credit card D: offer payment method as debit card PM=CreditCard BRAND=VISA CREDITDEBIT=C

Use OGM-VCS for ORDERID

For payment methods KBC/CBC Online, ING Homepay and Belfius DirectNet it is possible to include a structured communication (Gestructureerde mededeling) according to the OGM-VCS standard in your acquiring payout reports.

This structured communication is visible in our Back Office for individual transactions via Operations > View transactions or available as parameter STRUCT via our electronic reporting tool.

To make use of that, you will have to send the value of parameter ORDERID containing only digits.

Depending on the length of the ORDERID, the following content will apply to the structured communication:

Length ORDERID	Result
>12	PAYID + two check digits (as Modulo 97) will be used for structured communication
12 (including Modulo 97 checksum)	ORDERID will be used for structured communication. The same applies if this value is sent with parameter COM
11	PAYID + two check digits (as Modulo 97) will be used for structured communication
10 (not including Modulo 97 checksum)	ORDERID will be used for structured communication + two check digits (as Modulo 97) will be added by our system
Between 1 and 9	ORDERID + leading zeros + two check digits (as Modulo 97) will be used for structured communication. Depending on the length of the ORDERID, the amount of leading zeros will vary to get a length of 12 digits in total

Please align with your acquirer to print out the structured communication on your payout reports, taking into consideration that this might involve a modification of your acquiring contract.

This service is not available for these payment methods if offered via Full Service We will send the PAYID as structured communication instead

Display Hosted Payment Page in iframe

Iframes allow you to integrate the Hosted Payment Page on your website, while maintaining your own URL in the browser. This gives your customers the illusion of staying in your environment for during the whole payment process.

However, due to its limitations, we do not recommend using this feature for various reasons

• If your URL works with HTTP protocol only, the padlock icon will not appear in your customer’s browser. This may cause your customers doubt the security of the payment page
• Third-party payment method services (ie. Paypal, iDEAL etc.) will not work well with iframes, causing poor layout results during the payment process

Instead of iframes we suggest using the established possibilities to adapt the look and feel of the Hosted Payment Page or integrating via Flexcheckout.

If you still want to use iframes, make sure to

• Use them only on the payment method selection screen
• Use pop-ups for external payment methods whenever possible, to ensure the visibility of third-party web applications

Get extra data in transaction feedback

On top the feedback parameters you can choose in the Back Office, you can define you own parameters that should be included in the feedback. These are pass-through parameters you send in the transaction request and that are identically sent in the feedback. Use the following parameters to use this feature:

Parameter	Description / Possible values
COMPLUS	Pass a value within this parameter you would like to receive in the feedback Sending COMPLUS=1234 would be sent in the feedback like this: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]&COMPLUS=1234 […standard.parameters…]
PARAMPLUS	Pass both parameter names and values you would like to receive in the feedback Sending PARAMPLUS=SessionID=126548354&ShopperID=73541312 would be sent in the feedback like this: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]& SessionID=126548354&ShopperID=73541312

Use variable transaction feedback URLs

If you have multiple shops, you can adapt the feedback URL in the Back Office for each transaction individually.

To do so, take care of the following:

• In the Back Office, go to Configuration > Technical Information > Transaction feedback > eCommerce > Direct HTTP server-to-server request. Add the placeholder “<Paramvar>” for the part of the URL you want to change on transaction level.

Example:
https://www.yourwebsite.com/<PARAMVAR>/yourpage.asp

• In your transaction request, send for parameter PARAMVAR the value that will fill for the placeholder “<Paramvar>”
  
  Example:
  For PARAMVAR=shop1, the feedback for this transaction would be sent to
  https://www.yourwebsite.com/shop1/yourpage.asp

Define operation code per transaction

Per default, our platform processes every transaction request as an authorisation (status 5) or direct sales (status 9). You can override this Default operation code for each transaction individually with the additional parameter OPERATION. This enables you to decide from case to case whether you want to request an authorisation or a direct sale:

Parameter	Description / Possible values
OPERATION	Send for each transaction to override the Back Office configuration Find a list of all possible values in our our Parameter Cookbook

 

Link transactions to user

If you have multiple employees working with your Back Office and your web shop, you might want to register transactions associated with a specific user (ie. call center agents creating transactions via the payment link feature). You can achieve this by sending the following parameter:

Parameter	Description / Possible values
USERID	The name of the user as defined in your Back Office (Configuration > Users) In the transaction overview (Operations > View transactions / Financial History), the creator of the transaction is named by the formula “UserID/PSPID/User type”. If the USERID does not exist, we will replace it by the default USERID of the account (your PSPID)