Payment Page Solutions

Our payment page solutions maximize the user experience of the checkout process by giving you control over its design and feel. With three readily available integration options, you decide where and how you want your customers to pay, while still enjoying the benefits of a dependable payment solution. All you need to get started is PCI SAQ A compliance.

Payment Page URLs

PROD

https://paymentpage.getneteurope.com/api/payment/register

TEST

https://paymentpage-test.getneteurope.com/api/payment/register

Payment Page

Payment Page delivers a highly customizable, secure and polished checkout experience with multiple integration options. If visual design is your main priority, Payment Page gives you all the tools you need to create a great-looking payment page.

Payment Page

Features:

  • Credit Card support & APM Support

  • Integration types are hosted, embedded and seamless

  • Multi-language support

  • Custom CSS

  • Customization through GUI designer

  • Multiple themes

  • Responsive design (mobile & desktop)

Hosted Payment Page
HPP Advantages

Integrate the Hosted Payment Page (HPP) to redirect the consumer from your shop to a standalone payment page hosted by Getnet.

Use the Payment Page Designer to customize the HPP interface: set background, colors, fonts, logos and more for a cohesive look that meets your preferences and fits your merchant branding. The redirect to the HPP will be barely noticeable, which makes consumers feel at ease.

HPP also allows you to configure expiration times for payment hyperlinks: payments can be postponed.

Getnet hosts all sensitive data - you only need to meet the requirements of SAQ A to be fully PCI DSS compliant. With the HPP you can focus on your business and stop worrying about data security.

Hosted Payment Page Customization Through Payment Page Designer
Hosted Payment Page Customization Through Payment Page Designer
Hosted Payment Page Customization Through Payment Page Designer
Hosted Payment Page Customization Through Payment Page Designer
Embedded Payment Page
EPP Advantages

  • Payment form as overlay (iframe) to the checkout page

  • No consumer redirection

  • Customization with Payment Page Designer

  • PCI DSS SAQ A

Integrate the Embedded Payment Page (EPP) to display the payment form as an overlay to the checkout page. The consumer stays on the same page until the payment is finished, rather than being redirected to a separate site. This creates a smooth, uninterrupted shopping experience.

Use the Payment Page Designer to customize the EPP interface: set colors, fonts, logos and more for a cohesive look that meets your preferences and fits your merchant branding.

Getnet hosts all sensitive data - you only need to meet the requirements of SAQ A to be fully PCI DSS compliant. With the EPP you can focus on your business and stop worrying about data security.

Seamless Mode
Seamless Mode Advantages

  • Payment form integrated into the checkout page (iframe)

  • No consumer redirection, overlays, or pop-ups

  • Customization with Payment Page Designer

  • PCI DSS SAQ A

Use Seamless Mode to display the Payment Page payment form as a fully integrated part of your checkout page. Without redirects to external pages (except for credit card 3D Secure verification), overlays, or pop-ups, the payment form appears native to your website but is still being hosted by Getnet.

Use the Payment Page Designer to customize the payment form: set colors, fonts, logos and more for a cohesive look that meets your preferences and fits your merchant branding.

Getnet hosts all sensitive data - you only need to meet the requirements of SAQ A to be fully PCI DSS compliant. With Seamless Mode you can focus on your business and stop worrying about data security.

Currently, Seamless Mode is only available for credit card payments.
Redirects and IPNs
Configuring the Redirect Pages

During and after the payment process, the consumer is redirected to a corresponding page (e.g. success page upon a successful payment). You can set the URLs for 'successful', 'failed' and 'canceled' page redirects. Each type of redirect must be defined on at least one level. There are multiple ways of how you can do this:

  1. Default database URLs

The default values for redirect URLs are configured during account setup (merchant configuration) and saved into the database. They are then loaded from the database each time you send a payment request (which means you do not have to send them in the request).

If you need to change the default values, contact merchant support.

  1. Specifying redirect URLs in the payment request

Any redirect URLs which are sent in a payment request override their respective database defaults.

You can overwrite the default values by specifying the redirect links in the payment request:

Field (JSON) Required Data Type Size JSON Parent Description

success-redirect-url

N

String

2000

payment ({ })

The URL to which the consumer is redirected after a successful payment.

fail-redirect-url

N

String

2000

payment ({ })

The URL to which the consumer is redirected after an unsuccessful payment.

cancel-redirect-url

N

String

2000

payment ({ })

The URL to which the consumer is redirected after they cancel a payment.

If you have no database defaults, you must include them in the request. Certain payment methods also require a specific redirect field (⇒ redirect-url) to be present in the request.

redirect-url field

redirect-url overrides the database defaults for successful, failed and canceled redirects.

Do not confuse this field with payment-redirect-url, which contains the payment URL.

redirect-url covers all redirection options, i.e. regardless of whether the payment succeeds, fails or the consumer cancels, they are redirected to the URL specified in redirect-url:

Field (JSON) Required Data Type Size JSON Parent Description

redirect-url

N

String

256

payment ({ })

The URL to which the consumer is redirected after a successful, failed or canceled payment if there are no alternatives available.

redirect-url is only used as a fallback if there is no success-redirect-url, cancel-redirect-url or fail-redirect-url defined in the database or request.

pending-redirect-url field

Pending URL is a special variation of success-redirect-url. Certain payment methods require additional processing: even if the initial request is successful, the process is not complete yet.

In this specific situation, Payment Gateway returns a pending-debit transaction type in the response: the payment is processed, but its current state is not final. Since this is not the final response, the consumer is redirected to the pending-redirect-url instead of the usual success-redirect-url.

Field (JSON) Required Data Type Size JSON Parent Description

pending-redirect-url

N

String

256

payment ({ })

The URL to which the consumer is redirected when the response returns a pending transaction type.
Recap

There are 3 levels for each type (canceled, successful, failed) of redirection:

  1. Redirect fields sent in the request (success-redirect-url, fail-redirect-url or cancel-redirect-url).

  2. The redirect-url field - covering all of the three options - used as a fallback if the above is not defined.

  3. The third level is defined in merchant configuration (database default), set up during merchant configuration.

pending-redirect-url does not fit into these categories since it is a specific variation of the success-redirect-url. It is used when a payment request is successfully registered, but the response returns a pending-xx transaction type, pending further processing (e.g. the payment is finished at a later time, or there is a delay).

When the payment is processed, the consumer is redirected to the success-redirect-url page. pending-redirect-url can be sent in the request, or have a default value in the database like the others.

The order of precedence starts at the top, i.e. if the first level redirects are not defined, the second level is checked. You need to define at least one level for each redirect, e.g. if you have no database defaults set, you must include the redirects in the request.

Successful, failed and canceled redirects all POST payment response data to the redirection URL target.

Here is an example payment request with defined redirects. You can substitute them for any of the redirects found here (or add more):

{
  "payment": {
    "merchant-account-id": {
      "value": "61e8c484-dbb3-4b69-ad8f-706f13ca141b"
    },
    "request-id": "{{$guid}}",
    "transaction-type": "auto-sale",
    "requested-amount": {
      "value": 10.1,
      "currency": "EUR"
    },
    "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
    "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error",
    "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel"
  }
}
Configuring IPNs through Payment Page requests
This is only an example of how to configure extra IPNs through a Payment Page payment request. For information regarding automatic IPNs and other configuration options head over here.

You can set up additional IPNs by indicating them in a request. These are sent only per request (payment) and are not saved in your merchant configuration:

Example of IPN configuration in a payment request (JSON)
{
  "payment": {
    "merchant-account-id": {
      "value": "7a6dd74f-06ab-4f3f-a864-adc52687270a"
    },
    "request-id": "{{$guid}}",
    "requested-amount": {
      "value": "1.01",
      "currency": "EUR"
    },
    "account-holder": {
      "first-name": "John",
      "last-name": "Dao"
    },
    "transaction-type": "auto-sale",
    "notifications": {
      "format": "application/json",
      "notification": [
        {
          "url": "https://www.yourdomain.com/notification-target"
        },
        {
          "url": "https://www.yourdomain.com/success-notification-target",
          "transaction-state": "success"
        },
        {
          "url": "https://www.yourdomain.com/failed-notification-target",
          "transaction-state": "failed"
        },
        {
          "url": "https://www.yourdomain.com/success-notification-target2",
          "transaction-state": "success"
        }
      ]
    }
  }
}
Payment Page Features

Payment Page features support convenient customization of the payment and checkout process.

Add fields in the initial POST request or use Payment Page Designer to enable/disable features based on what you want for your business. Set default values during merchant configuration for simplified payment requests.

Read about individual features by clicking on the respective link below:

Order Overview
ShoppingCartDetails OrderOverview

Providing shopping cart details within the payment page enhances your customer experience because consumers are more likely to feel confident with the purchase. Payment Page features an order overview, toggled on and off using a single variable. Whereas most payment pages only show the order total, but not the specific items, Payment Page offers both.

This helps with a number of situations merchants face:

  • Avoiding abandoned shopping carts because customers are unsure what they are paying for

  • Postponed payments (concert reservations, football tickets, etc.), where it is easy to forget what one ordered weeks or even months before

  • Important & "quality of life" information (flight/train numbers, trip time, etc.) and more

To enable order overview for a payment:

Add the order-overview field to the payment request and set its value to true.
Field (JSON) Data Type JSON Parent Description

order-overview

Boolean

options (\{ })

Indicates whether order items are shown on the payment form.

The default value for order-overview is false. You can also enable order overview as a theme option in Payment Page Designer.

Detailing Order Items

The above shows how to enable the order overview, but not how to record the actual order items in the request.

See the examples below for JSON code sample for an order of 10 notebooks and 5 sets of colored pencils. All fields related to order items are optional, so it is up to you which ones you include (or leave out).

JSON Example For Detailing Order Items
 "order-items": {
      "order-item": [
        {
          "amount": {
            "currency": "EUR",
            "value": 1
          },
          "article-number": "123",
          "description": "A simple notebook",
          "name": "Notebook",
          "quantity": 2,
          "tax-amount": {
            "currency": "EUR"
          },
          "tax-rate": 19
        },
        {
          "amount": {
            "currency": "EUR",
            "value": 9.5
          },
          "article-number": "456",
          "description": "A set of colored pencils",
          "name": "Colored Pencils",
          "quantity": 3,
          "tax-amount": {
            "currency": "EUR"
          },
          "tax-rate": 19
        }
      ]
    }

demoshop OrderOverview
Cardholder Name

Some merchants prefer to use a single field instead of 'First Name' and 'Last Name'. As with order overview, you can set these options using a single field in the request.

First Name/Last Name Cardholder Name

To control the behavior of name field(s) on the payment form:

Add the cardholder field to the payment request and set it to the desired value.
Field (JSON) Data Type Values JSON Parent Description

cardholder

Boolean

names cardholder none

options (\{ })

Indicates the type of name field(s) used in the payment form or if they are enabled at all.

There are three options:

  1. Show both the First name & the Last name field on the payment page:
    Set the value of cardholder to names. This is the default option, so you do not need to do anything for this to happen unless you change the default.

  2. Show the Cardholder name field (instead of First name & Last name) on the payment page:
    Set the value of cardholder to cardholder.

  3. Only show card information on the payment page (no names):
    Set the value of cardholder to none.

Cardholder name renders the value from the last-name field; i.e. if you send the example request below with cardholder set to cardholder, only "Doe" shows.

Additional Fields

Billing & shipping fields are not showing in the payment form by default. However, you may enable these fields to show in the payment form:

  • Email

  • Phone

  • Address 1

  • Address 2

  • City

  • State

  • Country

  • Postal Code

These fields are available for credit card transactions only.
Show Additional Fields

To show these fields in the form, you have two options:

Field Toggles in Payment Page Designer

Click the button(s) of the field you want to show in the Designer menu, then save the theme. Payment Page then shows the saved field selection each time it loads a payment page with that theme.

Payment Page Designer
Using the Custom CSS Feature in Payment Page Designer

Add the CSS class of the field you want to show to the Payment Page Designer Custom CSS Editor and set its display property to block.

Payment Page Designer

For example:

.pp-cc-address1 {
    display: block;
 }

 .pp-cc-city {
    display: block;
 }

Since the default value of display property for these fields is none, as soon as you change it to block they become visible. These CSS settings are a part of the theme and are loaded at any time that you use that particular theme.

Here is a list of the CSS element names for the hidden fields:

.pp-cc-email
.pp-cc-phone
.pp-cc-address1
.pp-cc-address2
.pp-cc-city
.pp-cc-state
.pp-cc-country
.pp-cc-postal-code
Pay by Link via API

Payment Page offers the option to configure the expiration time & date of a payment URL (payment-redirect-url). By adding the hyperlink-expiration-time-stamp field to a normal payment request, you can set the time & date when the payment URL expires: This allows for using such URLs in different scenarios than instant payment, e.g. sending the payment URL as a part of a newsletter/email, MOTO (Mail Order/Telephone Order) payments, etc.

The maximum allowed value is one month in the future

You can use Pay by Link via API with credit card payments or alternative payment methods; both are supported.

Payment links with an expiration stamp redirect to a Hosted Payment Page. You remain fully PCI SAQ-A compliant using these links.

To set the expiration stamp for a payment link:

Add the hyperlink-expiration-time-stamp field to the payment request and set its value to the desired time & date.
Field (JSON) Data Type JSON Parent Description

hyperlink-expiration-time-stamp

yyyy-MM-ddTHH:mm:ss±HH:mm

payment ({})

Indicates the expiration time & date of the respective payment hyperlink.
Example request (hyperlink-expiration-time-stamp is at the end):
 {
   "payment":{
      "merchant-account-id":{
         "value":"7a6dd74f-06ab-4f3f-a864-adc52687270a"
      },
      "request-id":"{{$guid}}",
      "transaction-type":"authorization",
      "requested-amount":{
         "value":10.1,
         "currency":"EUR"
      },
      "account-holder":{
         "first-name":"John",
         "last-name":"Doe"
      },
      "payment-methods":{
         "payment-method":[
            {
               "name":"creditcard"
            }
         ]
      },
    "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
    "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error",
    "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel",
    "hyperlink-expiration-time-stamp": "2018-11-01T09:00:00.645Z"
   }
}

  • By specifying the hyperlink-expiration-time-stamp value in the request, you set the expiration time & date for the payment URL (default value is 30 minutes).

  • Each payment hyperlink can only be used once.

  • Specify redirect URLs in the request if you need to redirect your customers to a different page than your database defaults (or you have no defaults set). See the Configuring the Redirect Pages section for more details

  • The stamp uses ISO 8601 format with timezone, e.g. 2018-06-22T10:15:30+01:00.

  • The latest date for the expiration stamp is one month from the initial request creation.

Max Retries
Max Retries

The Max Retries feature allows consumers to try and resubmit the payment again if it fails. It works with all payment methods.

An example situation:

A consumer attempts to pay with their credit card, but the payment fails.

Payment page prompts the consumer whether they would like to retry the payment. They can resubmit the card information or select a different payment method altogether (depending on the configuration).
To enable Max Retries for a transaction:

Add the max-retries field to the payment request and set it to the desired value.
Field (JSON) Data Type JSON Parent Description

max-retries

Numeric

options (\{ })

Indicates whether a consumer can retry the payment if it fails (as well as how many times).
Configuring Max Retries

The rules for configuring Max Retries are simple:

  • If the value is less than 0, consumers have unlimited retries for failed payments.

  • If the value is exactly 0, consumers cannot retry payments: They are redirected to the fail-redirect-url page immediately.

  • If the value is greater than 0, that same value is the number of retries allowed; e.g. if max-retries value is 2, consumers are redirected to the fail-redirect-url only after two unsuccessful attempts.

  • Max Retries is disabled by default.

Example Request w/ Max Retries enabled (set to "unlimited retries")
 {
   "payment":{
      "merchant-account-id":{
         "value":"7a6dd74f-06ab-4f3f-a864-adc52687270a"
      },
      "request-id":"{{$guid}}",
      "transaction-type":"purchase",
      "requested-amount":{
         "value":10.1,
         "currency":"EUR"
      },
      "payment-methods":{
         "payment-method":[
            {
               "name":"creditcard"
            }
         ]
      },
    "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
    "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error",
    "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel"
   },
   "options": {
        "max-retries": -1
  }
}
Auto-Sale

Auto-sale is a pseudo transaction type, which has been created for the purpose of offering merchants and easier way to integrate the standard and most widely used "SALE" transactions. Auto-sale does not exist as an individual transaction type: it is only a place-holder which is used by Payment Gateway to decide which transaction type should be used for a specific transaction. When using auto-sale, you are not required to send a specific transaction-type for each credit card or alternative payment method request.

Basic Configuration

Your merchant account is automatically configured for the default auto-sale settings. If you send a request with auto-sale as the transaction type, these are the values used:

Payment method Default transaction type

creditcard

purchase

ideal

debit

paypal

debit

sepadirectdebit

debit

sofortbanking

debit

However, the transaction is not registered as auto-sale in the database, but as the default transaction type. Look at example request below:

{
   "payment":{
      "merchant-account-id":{
         "value":"5c4a8a42-04a8-4970-a595-262f0ba0a108"
      },
      "request-id":"{{$guid}}",
      "transaction-type":"auto-sale",
      "requested-amount":{
         "value":224.0,
         "currency":"EUR"
      },
      "payment-methods":{
         "payment-method":[
            {
               "name":"creditcard"
            }
         ]
      },
    "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
    "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error",
    "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel"
   }
}

Although the transaction-type is auto-sale, the request is actually sent as purchase (or any other default value you set for credit card payments). The behavior is the same for all payment methods.

Extended Configuration

You can reconfigure the default auto-sale settings for every payment method upon request. As this requires changing your Merchant Account configuration, you need to contact Merchant Support for extended configuration options.

Currency Configuration

You can also configure auto-sale options for a specific currency. You can have multiple default transaction types based on which currency is used, e.g. credit card payments in EUR use authorization as the default type, whereas USD payments are sent as purchase. Again, this is only possible by changing your Merchant Account configuration (contact Merchant Support).

My Favorite Payment

My Favorite Payment allows you to streamline the payment process for your returning consumers by using card tokens which are created during each card payment. If you include a card token (from a previous transaction) in any future payment request, the consumer only needs to input their CVV instead of filling out the entire card form.

There is also an option to use a different card: Consumers can switch between the two options freely without leaving the session.

My Favorite Payment

How does it work?

Card information is tokenized and returned as the ''token-id'' field in the response automatically during a card payment.

Adding the token-id field with a token value from a previous payment (e.g. "token-id": "4242796444090018") to the payment request prepopulates the respective fields on the card form with the tokenized information when payment page loads.

Example of a payment request using a card token
 {
   "payment":{
      "merchant-account-id":{
         "value":"5c4a8a42-04a8-4970-a595-262f0ba0a108"
      },
      "request-id":"{{$guid}}",
      "transaction-type":"authorization",
      "requested-amount":{
         "value":224,
         "currency":"EUR"
      },
      "payment-methods":{
         "payment-method":[
            {
               "name":"creditcard"
            }
         ]
      },
      "card-token" : {
      "token-id" : "4242796444090018"
      },
    "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
    "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error",
    "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel"
   }
}
Customized Display Text

Customized Display Text is an optional feature available for two of our Payment Page integration options:

Customized Display Text allows you to personalize your checkout process with a brief message to your consumers.

If you want to use this feature, add customized-display-text in the initial POST request and insert a short text (see example request below).

The inserted text then appears on the payment page (for HPP) or in the iframe (EPP).

By default, payment page and iframe display the first four lines of your text.

If your text is longer than four lines, consumers can expand the field using the arrows at the bottom.

Format your text with any of these three HTML formatting options:

  • <b> bold </bold>,

  • <i> italic </i>,

  • <br> line break.

Customized Display Text is a single-language feature: the text will always be displayed in the same language.
Test Credentials

Use the following test credentials to test Customized Display Text:

URL (Endpoint)

https://paymentpage-test.getneteurope.com/api/payment/register

Merchant Account ID (MAID)

5c4a8a42-04a8-4970-a595-262f0ba0a108

Username

784320-getneteurope

Password

2NQBnucU19mY
Example Request
Field (JSON) Data Type Size JSON Parent Description

customized-display-text

String

1024

options ({ })

Includes a customized display text on the payment page / in the iframe. For Hosted and Embedded Payment Page.

 
{
    "payment": {
        "merchant-account-id": {
            "value": "7a6dd74f-06ab-4f3f-a864-adc52687270a"
        },
        "request-id": "{{$guid}}",
        "transaction-type": "purchase",
        "requested-amount": {
            "value": 1.95,
            "currency": "EUR"
        },
        "payment-methods": {
            "payment-method": [
                {
                    "name": "creditcard"
                }
            ]
        },
        "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
        "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel",
        "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error"
    },
    "options": {
        "customized-display-text": "Dear Customer,<br>Thank you for shopping at <i>The Magic Store</i>.<br><br>We are now processing your order and will ship it as soon as possible.<br> Your order number is <b>999999</b>.<br> Your customer number is <b>111111</b>.<br><br>Thanks for shopping with us. Please visit us again soon!"
    }
}
Order and Filter Payment Methods

This Order and Filter option allows you to display the available payment methods in your preferred order. If you use this option, only the payment methods defined are displayed. All the other payment methods are ignored.

This option is available for all of our Payment Page integration options:

Configure the Order and Filter Option

  1. Include the payment-method-order-and-filter field in the payment request.

  2. Add the payment method names to the JSON array in your preferred order. Separate the payment method names with a comma.

If you don’t want to sort all of your payment methods manually, you have the option to use the asterisk ( * ) as a placeholder. Enter your preferred payment methods and then the asterisk, e.g. ["creditcard", "paypal", "*"]
As a result, Payment Page lists your preferred payment methods first, followed by all of your other payment methods.

Misspellings or unavailable payment methods are ignored. Payment Page displays the full list of available payment methods instead.

The Order and Filter option is available in JSON only. You can send this option with each request.

Test Credentials

Use the following credentials to test the Order and Filter option:

URLs (Endpoints)

https://paymentpage-test.getneteurope.com/api/payment/register

Merchant Account ID (MAID)

5c4a8a42-04a8-4970-a595-262f0ba0a108

Username

84320-getneteurope

Password

2NQBnucU19mY

Secret Key

49c90b00-e5f7-40d0-bc7f-4971b8e7681e
Example Request
Field Data Type Parent Description

payment-method-order-and-filter

Array

options (\{ })

Displays the available payment methods in the order specified in this field.

 
{
  "payment": {
      "merchant-account-id": {
          "value": "ab62ea6e-ba97-48ef-b3bc-bf0319e09d78"
      },
      "request-id": "{{$guid}}",
      "requested-amount": {
          "value": "1.01",
          "currency": "EUR"
      },
      "account-holder": {
          "first-name": "Paul",
          "last-name": "Peterson"
      },
      "transaction-type": "auto-sale"
  },
  "options": {
      "payment-method-order-and-filter": ["creditcard", "paypal", "*" ]
  }
}
Limit Credit Card Brands

Use the Limit Credit Card Brands option to display your preferred credit card brands. Display, for example, a different set of credit card brands to consumers in different regions in the world.

This option is available for all of our Payment Page integration options:

Configure the Limit Credit Card Brands Option

  1. Include the credit-card-brand-filter array in the payment request.

  2. Add the credit card brand names to the JSON array in your preferred order. Separate the credit card brand names with a comma.

  3. As a result, Payment Page displays only the credit card brands you added to the array.

See our supported credit card brands.

The Limit Credit Card Brands option is available in JSON only. You can send the Limit Credit Card Brands option with each request.

Field Data Type Parent Description

credit-card-brand-filter

Array

options (\{ })

Displays the credit card brands specified in this field.
Example Request

Use the test credentials we provide for Credit Card and send the sample below.

P:S: this sample is just for demo

{
   "payment": {
       "merchant-account-id": {
           "value": "7a6dd74f-06ab-4f3f-a864-adc52687270a"
       },
       "request-id": "{{$guid}}",
       "transaction-type": "purchase",
       "requested-amount": {
           "value": 10,
           "currency": "EUR"
       },
      "ip-address": "127.0.0.1",
       "success-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/success",
      "fail-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/error",
      "cancel-redirect-url": "https://demoshop-test.getneteurope.com/demoshop/#/cancel"
   },
   "options": {
      "credit-card-brand-filter":  ["visa", "mastercard"]
   }
}
Payment Page Designer

Live demo - try our Payment Page Designer now.

PPD Advantages

  • Branding-oriented customization for HPP, EPP and Seamless

  • Large selection of fonts, colors, effects, backgrounds and logos

  • Creation of themes

  • Responsive and code-free design

  • Possibility to enable/disable Payment Page Features>>

  • Live preview

Use the Getnet Payment Page Designer (PPD) to customize the Hosted Payment Page and Embedded Payment Page, as well as the Seamless interface: set background, colors, fonts, logos and more for a cohesive look that meets your preferences and fits your merchant branding. You can then use your newly created themes right away or export and import them for further editing.

Customize your Payment Page

Open the Payment Page Designer.

The Payment Page Designer is divided into three sections:

  • Device Preview in the upper-left corner

  • Live Preview in the center

  • Payment Page Designer menu on the right

Device Preview
Click the unfold button in the upper-left corner to open the Device Preview menu. Select either Desktop preview, Tablet preview or Mobile preview to adjust the Live Preview accordingly.

Live Preview
The Live Preview simulates the Payment Page form. It changes as soon as you

  • change the device in the Device Preview.

  • modify the settings in the Payment Page Designer menu.

Payment Page Designer menu
The Payment Page Designer menu is available in three languages:

  • English (EN)

  • German (DE)

  • French (FR)

Click Login to access the Payment Page design manager menu.

The Payment Page Designer menu is divided into eight sections:

1. Preview mode

The Live Preview changes depending on your selection in the Preview mode:

  • Payment displays the payment form according to your settings.

  • Grid displays all available payment methods.

  • Processing displays the Spinner.

    • Spinner is the process indicator presented to the consumer while waiting during the payment process.

2. General

Expand the General section to:

  • Customize the appearance of the payment form and its input fields (e.g. roundness and icons).

  • Select a predefined Spinner.

  • Upload a personalized Spinner. The uploaded file must be an animated gif.

  • Upload your logo.

    • Max. file size: 300 kB

    • Logo size: between 30x30 px and 1200x900 px

    • Once you upload a logo you can change the position and/or size.

  • Upload a background picture.

    • Max. file size: 1024 kB

    • Logo size: between 1000x768 px and 2651x1441 px

3. Miscellaneous

Expand the Miscellaneous section to:

  • Display or hide the consumer’s order items.

  • Display the card data in either one or three input fields.

  • Switch between labels and/or placeholders to display the names of the input fields. You can cancel the Placeholder selection only if Label is selected and vice versa.

  • Switch between currency symbol and/or currency name (ISO 4217 code) for the Amount format. You can cancel the currency symbol selection only if the currency name is selected and vice versa.

  • Add further input fields (Card form fields) for additional consumer information (e.g. address, email, phone).

  • Determine where you want to place the CANCEL PAYMENT button. By default, it is displayed as a command in the hamburger menu.

  • Display a secure SSL encryption/payment badge. Click the Secure Badge list and select either No Secure Badge or one of the six available badge types. Note that Security Badge Type 5 is presented in a white font and is only visible on darker backgrounds.

4. Font

Expand the Font section to:

  • Select a predefined font for buttons and input fields.

  • Upload a font of your choice.

  • Adapt the font size and style.

Upload only one font at a time in the Web Open Font Format (.woff, .woff2 file extensions).
The uploaded font then appears as a custom font in the Text and buttons and Input fields lists.

5. Colors

Expand the Colors section to change the color of:

  • Buttons (click Primary Color)

  • CANCEL PAYMENT button (click Secondary (Dismiss) Color) if button is placed next to the SUBMIT PAYMENT button

  • Entire background (click Page Background Color)

  • Payment Page form (click Content Background Color)

  • Input fields

  • Other payment form elements such as the horizontal line, the Spinner and the hamburger button (click Menu Icons Color)

6. Effects

Expand the Effects section to change the intensity of:

  • Payment Page shadow

  • Payment Page shadow color

Blur Effect and Opacity can only be used if you have uploaded a logo or a background picture in the General section, or defined a Color.

7. Custom CSS

Expand the Custom CSS to further personalize your style sheet and save it (i.e. export it to a theme).

8. Payment request (for preview only)

Expand the Payment request section to change the values of a potential payment request (e.g. requested-amount.value, requested-amount.currency, order-item.name, order-item.description). The Live Preview displays your modifications immediately.
If the order items are not visible, display them using the Miscellaneous section.

Save your settings

Click Export theme to save your settings as a .json file.

Customize your themes

Click Import theme to customize your saved themes.

Manage your Themes and Translations

Use the Payment Page design manager menu to edit and organize your themes and translations.

  1. Open the Payment Page Designer.

  2. Click Login.

  3. Use your credentials provided by Merchant Support to access the Payment Page design manager menu.

Make sure that only one user is editing a theme. If two users edit a theme at the same time, some changes might get lost.
A session timeout requires a relogin to the Payment Page design manager menu after 60 minutes of inactivity.

The Payment Page design manager menu is divided into two sections:

  • Translations

  • Themes

Translations

Expand the Translations section to:

  • Import a translation file. The translation file must be available in .json format.

  • Export the default translation file. The default translation file is exported to a .json file.

    Edit the default translation file and import it as a new translation file.

  • Edit imported translations.

    • Edit the translation file name. Double-click the file name or click the Edit button.

    • Edit the translations. Click Export to export the translations to a .json file.

    • Delete the translation file.

You can modify the translations to e.g.:

  • Meet local variations such as US or UK English.

  • Change button names.

You can only edit the languages available in the default translation file. You cannot add further languages.
Themes

Expand the Themes section to:

  • Create a new theme.

  • Import a theme. The theme file must be available in .json format.

  • Edit a theme.

  • Set the default theme.

  • Delete a theme.

Click the Theme preview button on the right of the theme name to see a preview. The theme is displayed as a .jpg and can be downloaded.
Imported Themes

Click the theme name to expand the theme’s properties to:

  • Edit the theme name. Double-click the theme name or click the Edit button.

  • Select a translation file.

  • Set the theme as default. The default theme is used for payment processes if not indicated otherwise in the request.

    The default theme can be identified by the asterisk symbol.

  • Activate or deactivate the theme. Only activated themes can be used in the request.

    Active themes can be identified by the tick symbol.

  • Change the theme settings. Click Style it to open the theme in the Payment Page Designer menu.

    You can toggle between the Payment Page Designer and the Payment Page design manager menu. Use BACK TO DESIGNER to switch to the Payment Page Designer menu. Use MANAGE in the Payment Page Designer menu to return to the Payment Page design manager menu. If Style it is unavailable in the Payment Page design manager menu, the theme is already open in the Payment Page Designer menu.

  • Save your changes. Save is available only if changes have been made.

  • Export the theme to a .json file.

  • Delete the theme.

Include a Theme in the Request
Field Name Data Type JSON Parent Description

theme

String

options ({ })

The name of the PPD theme used for a specific payment process.
Sample Request
{
   "payment":{
      "merchant-account-id":{
         "value":"7a6dd74f-06ab-4f3f-a864-adc52687270a"
      },
      "request-id":"{{$guid}}",
      "transaction-type":"purchase",
      "requested-amount":{
         "value":10.1,
         "currency":"EUR"
      },
      "payment-methods":{
         "payment-method":[
            {
               "name":"creditcard"
            }
         ]
      }
   },
   "options": {
        "theme": "test-theme"
  }
}
Payment Page Security
Payment Page Security Flow

All Payment Page integrations share a common backend-to-backend JSON workflow for the payment process:

Payment Processing with HPP and EPP

  1. Create a payment session (initial request).

  2. Redirect the consumer to the payment page (initial response URL).

  3. Highly recommended: Parse and process the payment response.

Payment Processing with Payment Page LEGACY in Seamless Mode

  1. Create a payment session (initial request).

  2. Render the Seamless payment form in your checkout page (initial response URL).

  3. Submit the payment.

  4. Highly recommended: Parse and process the payment response.

As part of this workflow:

  • The initial request is secured by basic access authentication (basic header with base64-encoded credentials).

  • The final payment response is base64-encoded and signed by HMAC SHA-256. This allows you to verify the authenticity of the final payment response.

For more information regarding Payment Page integration-specific payment processes, see HPP Integration, EPP Integration and Integrating Payment Page in Seamless Mode.
Response Verification

For Payment Page, response verification is optional but highly recommended.

Response verification requires:

  • the Secret Key you receive during merchant configuration.

  • the field entries response-base64, response-signature-base64 and response-signature-algorithm sent as form data with the final payment response

You can find the required form data included in the final payment response sent to the redirect target in your shop.

Response Verification
Name Description

response-signature-base64

Base64-encoded signature against which to verify the calculated security response signature.

response-signature-algorithm

"HmacSHA256" specifying the type of the message authentication code.

response-base64

Final response containing the payment data in a base64 encoded JSON format.

To verify the response, calculate the security response signature and check it against the signature data you receive with the final payment response.

We provide ready-made response verification examples for Java, PHP and C# below.

If the response signature verification fails, do not accept the payment and contact Merchant Support.
Response Verification Examples
Verifying the Response Signature (JAVA)
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import javax.xml.bind.DatatypeConverter;

...

private String merchantSecretKey = "merchantSecretKey";

public boolean isValidSignature(String responseBase64, String responseBase64Signature, String responseSignatureAlgorithm) throws Exception {
    Mac mac = Mac.getInstance(responseSignatureAlgorithm);
    mac.init(new SecretKeySpec(merchantSecretKey.getBytes("UTF-8"), responseSignatureAlgorithm));
    return responseBase64Signature != null && responseBase64Signature.equals(DatatypeConverter.printBase64Binary(mac.doFinal(responseBase64.getBytes("UTF-8"))));
}
Verifying the Response Signature (PHP)
<?php

/**
 * @param string $responseBase64
 * @param string $signatureBase64
 * @return bool
 */
function isValidSignature($responseBase64, $signatureBase64, $merchantSecreyKey)
{
    $signature = hash_hmac('sha256', $responseBase64, $merchantSecreyKey, true);
    return hash_equals($signature, base64_decode($signatureBase64));
}
Verifying the Response Signature (C#)
  …

  using
  System.Linq;

  using
  System.Security.Cryptography;

  using
  System.Text;

  …
  String merchantSecretKey = "key";

  Boolean isValidSignature(String responseBase64, String signatureBase64,
  String responseSignatureAlgorithm)

{
  if (responseBase64 == null || signatureBase64 == null || responseSignatureAlgorithm == null)
  {
    return false;
}

  byte[] response = Encoding.UTF8.GetBytes(responseBase64);
  byte[] expectedSignature = Convert.FromBase64String(signatureBase64);

  KeyedHashAlgorithm algorithm =KeyedHashAlgorithm.Create(responseSignatureAlgorithm);
  algorithm.Key = Encoding.UTF8.GetBytes(merchantSecretKey);
  algorithm.Initialize();

  byte[] computedSignature = algorithm.ComputeHash(response);
  Boolean result = computedSignature.SequenceEqual(expectedSignature);
  return result;
}
Browsers and Languages
Browsers
Browser Versions OS OS Version Supported

Chrome

62.0.3202 - latest version

Windows

7 / 8 / 8.1 / 10

✅

Firefox

47.0 - latest version

7 / 8 / 8.1 / 10

✅

Opera

48.0 - latest version

7 / 8 / 8.1

✅

Edge

40.15063 - latest version

10

✅

Safari

11.0 - latest version

macOS

-

✅
Languages

At the moment, Payment Page supports the following languages:

Code English Name

en

English

de

German

ar

Arabic

bs

Bosnian

bg

Bulgarian

zh

Chinese

hr

Croatian

cs

Czech

da

Danish

nl

Dutch

et

Estonian

fi

Finnish

fr

French

el

Greek

he

Hebrew

hi

Hindi

hu

Hungarian

it

Italian

ja

Japanese

ko

Korean

lv

Latvian

lt

Lithuanian

mk

Macedonian

no

Norwegian

pl

Polish

pt

Portuguese

ro

Romanian

ru

Russian

sr

Serbian

sk

Slovak

sl

Slovenian

es

Spanish

sv

Swedish

tr

Turkish

uk

Ukrainian
Payment Page Worfklow
Payment Page Workflow
Figure 1. Payment Page Workflow (Basic Payment)

REST API →