Choose a payment solution, or combine payment solutions, that best fit your business.

Hosted Checkout

The Hosted Checkout model allows you to collect payment details from your payer through an interaction hosted and displayed by the CommWeb payment gateway. With this model of integration, you never see or handle payment details directly because these are collected by the hosted payment interface and submitted directly from the payer's browser to the CommWeb payment gateway.

Hosted Checkout can be implemented as, either:

  • An embedded page - An embedded component within your existing merchant website.
  • A Hosted Payment Page - A web page hosted and displayed by the CommWeb payment gateway.
Key Benefits
  • Hosted Checkout is simple and quick to integrate.
  • You do not need to handle or store any payment details, thereby lowering PCI compliance costs.
  • You can use the theme offered by your payment service provider to display your Hosted Checkout interface. This allows you to leverage the brand of your payment service provider. A strong brand reduces payer's reticence to provide payment details.
  • You can customize the content of the Hosted Checkout interface to display your business information.
  • If you have subscribed to notifications, you can choose to receive those if the payment is successful.
  • Hosted Checkout is WCAG (Web Content Accessibility Guidelines) 2.0 Level AA compliant.
Information Flow

The payment flow for the Hosted Checkout model is illustrated below.

Hosted Checkout Integration Model

  1. The payer initiates the payment process for goods and services at your shop site. In response, your application submits a JavaScript request with the required data to the CommWeb payment gateway to display the chosen payment interface: an Embedded Page or Hosted Payment Page.
  2. The payer is presented with the payment interface. The display contents (like your business information and order details), as well as other aspects of the payment interface, are controlled by the data in your request.

    The payer enters the required information, and clicks "Pay".

    The CommWeb payment gateway collects and verifies the payment details and processes the payment.

    • If you are configured for a browser payment service such as PayPal , or a digital wallet service, these services display as a payment option alongside other card options. If the payer chooses to pay using one of these services,the payer will be redirected to the service provider's website to select the payment details.
    • If you are configured for the 3-D Secure Service, by default your payer will be prompted to authenticate before performing the payment. You can choose to bypass the authentication, see Bypass Security Features.
  3. If the payment is successful, the payer can obtain the payment details from one of these sources:

    • A CommWeb payment gateway-hosted receipt (in the embedded page or on a hosted page). This is the default behavior.
    • Your shop site.
    • Email notifications. You must subscribe to payer notifications to implement this.

If the payment is unsuccessful, Hosted Checkout displays the result, allowing the payer to retry the transaction with different payment details.

Hosted Session

Choose the Hosted Session model if you want control over the layout and styling of your payment page, while reducing PCI compliance costs. The Hosted Session JavaScript client library enables you to collect sensitive payment details from the payer in payment form fields, sourced from and controlled by CommWeb payment gateway. The gateway collects the payment details in a payment session and temporarily stores them for later use. You can then include a payment session in place of payment details in the transaction request to process a payment.

Key Benefits
  • Hosted Session is simple and quick to integrate.
  • You do not need to collect, store, or process any sensitive payment details thereby lowering PCI-compliance costs.
  • You maintain control over the styles and layout of your payment page.
  • You can customize the payer experience to suit your business.
Information Flow

The payment flow for the Hosted Session model is illustrated below.

Hosted Session Integration Model
  1. The payer initiates the payment process for goods and services at your shop site.
  2. The payer can choose to provide payments details using a credit/debit card, digital wallet, gift card, or make an Automated Clearing House payment.

    • Your payment page: Payment details are collected in form fields embedded in iFrames hosted by the CommWeb payment gateway.
    • Digital wallet: Card details are securely collected from the wallet interaction and sent to the CommWeb payment gateway.
  3. The CommWeb payment gateway collects the payments details in a payment session, which you can use in any operation referencing a session.

Direct Payment

If you need full control over the transaction, wish to manage your own payment pages or collect payment details, you must use the Direct Payment model. The payment details are sent directly to the CommWeb payment gateway to process the transaction. This merchant-managed model requires you to manage the security associated with collecting the payer's payment details in your application thereby increasing PCI compliance costs.

Key Benefits
  • Provides full control on the entire payment experience. You have the flexibility to customize your payment solution.
  • Integrates with any application, website, call centre, billing, Interactive Voice Response (IVR)
  • Allows you to communicate directly to the CommWeb payment gateway and then receive a real-time response to the API call. This is a synchronous connection and the payer does not leave your application, which means your session is not broken with the payer.
  • Supports advanced CommWeb payment gateway operations such as captures, refunds, voids, and queries where the payer is not directly involved.
Information Flow

The information flow for Direct Payment is illustrated below:

Direct Payment Integration Model

  1. A payer decides to make a purchase and provides their card details directly to your application or website. You may choose to combine collected card details with details stored on a previously stored token. See Multiple Sources of Card Details.
  2. Your application or website formulates the transaction request and sends it using an HTTPS POST or PUT over the Internet to the CommWeb payment gateway via DirectAPI.

    Depending on your business needs, you may pass additional fields in the transaction request. See Additional Functionality.

    Before performing the payment transaction, you can submit a rate quote request for dynamic currency conversion (DCC) to retrieve the payer's currency and the order amount in that currency.
    At this stage, you can also authenticate the payer using the . Note that if the payer accepts the DCC offer, then you must provide the DCC information in the authentication request.
  3. The CommWeb payment gateway passes the transaction to your acquiring bank for processing.
  4. The acquirer returns a response and the CommWeb payment gateway generates a transaction response and passes it to your application or website, in response to your API call. The transaction response indicates if the transaction was successful, and also includes other response data.
  5. Your application or website displays a receipt or other confirmation or error page based on the result of the transaction.


Batch allows you to securely and reliably submit batches of operations (Captures, Refunds, etc) to the CommWeb payment gateway for processing without direct payer interaction. For example, you can trigger authorizations using an online shopping cart and then perform captures using Batch.

Once submitted, you can periodically request a batch status to determine the current state of the batch processing including a count of the total uploaded, processed, and erred operations as well as time and date stamps on processing actions. The same batch status is also visible to your payment service provider via the Batch Status Search screen in Merchant Manager.

After a batch has completed processing, you can request a response file that contains the result of each of the uploaded operations.

Key Benefits
  • Processes multiple operations securely and efficiently — you are able to securely process multiple operations by submitting a batch rather than processing each operation individually.
  • Removes the need for installing a local application — you need not install an application on your system. This removes the cost of deploying, updating, and maintaining applications.
  • Removes PA-DSS compliance obligation — providers of payment applications to third parties must comply with Payment Application Data Security Standard (PA-DSS) requirements. Removing the need for an application installed on your system, removes the cost of meeting the PA-DSS compliance obligation.
  • Supports both small and large merchants — the feature supports the needs of both small merchants (who mainly require a solution that is easy to use and does not require integration), and large merchants (who want to efficiently process large transaction volumes).
  • Reduces PCI compliance costs when used with Tokenization — when used with Tokenization, you are able to realize the combined benefits of Tokenization and Batch processing.
Information Flow

The information flow for Batch is illustrated below:

Batch Integration Model

  1. Your integration aggregates payer operations into a batch and uploads the batch of operations using HTTPS PUT over the Internet to the CommWeb payment gateway via the CommWeb payment gatewayBatch service. See Creating a Batch Request.
    You may choose to combine collected card details with details stored on a previously stored token. See Multiple Sources of Card Details.
    You may also pass additional fields in the Batch Request depending on your business need. See Supported Features.
  2. Before the batch is processed you will need to validate the batch contents by sending a Message Integrity Code (MIC) comprising of a SHA-1 digest of the batch contents so that any missing or corrupt records are detected. See Sending a Batch Request.
  3. Once validated, each operation in the batch is processed.
  4. During processing you can poll for the status of the batch to determine the number of records processed and the overall status. See Retrieving Batch Status.
  5. Once the status indicates that the batch processing is complete you can request a batch response. The batch response includes the response values as specified in the original uploaded batch header. Downloading the Batch Response.

Copyright © 2023 Commonwealth Bank of Australia