How It Works

Onsite Checkout integrates into your website using a lightweight JavaScript implementation.

By tagging webpage elements with key data attributes, such as item and promotion code, the checkout can dynamically render the appropriate purchase experience.

Depending on configuration, Onsite Checkout renders in either:

• Embedded mode
• Overlay Pop-Up mode

Integration Overview

JavaScript Integration

JavaScript snippets added to your website enable Call-To-Actions to be tagged with meaningful attributes which define how the Checkout behaves.

These attributes:

• Determine which checkout mode is rendered
• Define the item being purchased
• Define the promotion code being used
• Control country, currency and customer information

Benefits of Attribute-Based Integration

• Full control over checkout appearance and behaviour
• Flexible user experience customisation
• Alignment with existing website branding and UI requirements

Supported Data Attributes

Data Attribute	Requirement status	Description
data-itemcode	Mandatory	Defines the item being purchased
data-promotioncode	Mandatory	Defines the promotion code being used
data-country	Mandatory	Defines the recipient country. If omitted, the customer country is IP-detected automatically
data-currency	Mandatory	data-currency Mandatory Defines the payment currency. If omitted, the currency defaults based on the customer’s country
data-email	Optional	Defines the customer email address. When supplied, the email field is suppressed within the checkout

Validation

Before rendering the checkout, standard validation checks are performed, including:

• Item validation
• Promotion validation
• Offer validation

If validation fails:

• A user-friendly error message is displayed

Supported Behaviour

Checkout Behaviour

Irrespective of which mode is used:

• Customer progression through the purchase journey behaves consistently

Offer Behaviour

Onsite Checkout assumes the customer has already selected their desired offer before entering the checkout.

As a result:

• Multiple offers are not displayed within the interface Promotion codes used with Onsite Checkout must therefore support:
• A single choice per item/currency combination

Exception

The exception to this rule is:

• Rolled-up payment functionality

This allows multiple choices to be consolidated into a single price point.

Offer Retrieval

Offer retrieval follows the same logic used within Checkout.

Offers are dynamically derived based on:

• Item
• Promotion code
• Ship-to country
• Currency

Once retrieved:

• The resulting offer is rendered within Onsite Checkout

Payment Journey

Email Address Collection

Once the offer has been established:

• Customers input their email address

If the email address is supplied through the data-email attribute:

• The email field is suppressed

Payment Methods

Available payment methods are dynamically displayed based on:

• The payment codes associated with the selected choice

Apple Pay Support

Apple Pay is supported in Express mode.

When customers select:

• Pay by Apple Pay

they are:

• Redirected to their wallet to confirm payment
• Redirected to the order success page following completion

Standard Apple Pay is not supported.

Credit and Debit Card Support

When customers select:

• Credit or Debit Card

they are directed to a secondary screen to enter:

• Address details
• Payment details

Both Apple Pay Express and Credit/Debit Card processing are supported through the existing Payment Widget solution.

Supplementary messaging, including automatic renewal notices, is also supported where applicable.

PayPal Support

PayPal is supported as a payment method within Onsite Checkout.

When customers select:

• PayPal

A PayPal authentication pop-up window is displayed, prompting them to log in to their PayPal account.

Customers are required to enter:

• Email address or mobile number
• Password

Once authenticated:

• The customer proceeds through the PayPal payment flow.

Supporting Components

Address Entry

Address entry functionality is supported through:

• Loqate predictive address lookup

Payment Components

Payment handling is supported through:

• Payment Widget

Data Protection Components

Data protection questionnaires are supported through:

• Existing CMS questionnaire configuration

Order Processing

Order Service / Proxy

Orders submitted through Onsite Checkout are processed through the same Order Service / Proxy layer used by Checkout.

This enables:

• Centralised order processing logic
• Consistent backend behaviour

Transaction Types

The following transaction types distinguish Onsite Checkout orders from other platforms:

• Onsite Checkout – Embedded
• Onsite Checkout – Overlay

These differentiate Onsite Checkout from:

• Checkout
• Payment Widget
• TIGA

Till Receipts

Orders submitted through Onsite Checkout are categorised under:

• Acquisition journey type This aligns with the existing till receipt configuration structure.

User Journey

Address Confirmation

Following confirmation:

• Address details are automatically formatted into a read-only accordion view

Edit Functionality

Customers can edit:

• Email address
• Delivery address

Using the Edit option within the accordion component.

Once changes are submitted:

• Customers are returned to the Onsite Checkout form

Billing Address

Customers can define a billing address separate from the delivery address.

Example:

• Billing address = home address
• Delivery address = office address

This functionality also uses the predictive address lookup solution.

Data Protection

Customers can:

• Define data protection preferences

Brand-Level Questionnaires

Brand-specific questionnaires can be configured independently for each brand.

Order Success Screen

Following successful order submission:

• Customers are shown the order success screen