Chapter 1   Introduction to Payment Initiation


This chapter provides an overview of iPlanet Trustbase Payment Services. It discusses a payment initiation model that is based upon the Identrus framework. It is a set of open specifications that allow the Banks and customer vendors to support implementation of an open network based Payment initiation solution. The chapter looks at some of the key features that go into making payments over an open network such as the Internet. It provides an overview of:

• Payment Initiation Products

• Payment Initiation Schemes

• Payment Initiation Processing Models

• Payment Initiation Reference Components of iPlanet Trustbase Payment Services

Payment Products

---

Every Payment Scheme includes a number of payment products. Each product has a particular set of features that are made up of a sequence of messages sent between the Buyer, Seller, Seller's Financial Institution and Buyer's Financial Institution.

Kinds of Payment products

Examples of payment products include:

• Payment Order

• Certified Payment Obligation

You need to consult your Payment Scheme specification for more details about which kinds of Payment products are supported by iPlanet Trustbase Payment Services (iTPS).

Payment Order

A Payment order is a revocable, unconditional electronic instruction from the Buyer requesting the Buyer's Bank to execute a credit payment to the Seller on a specific date for a specified amount.

Certified Payment Obligation

Where an Assured Payment is used, the Buyer requests the Buyer's Bank to underwrite (or assure) the payment to the Seller.

Payment Schemes

---

With the use of a payment scheme, a payment is secured by digitally signing payment instructions, providing authentication, message integrity, non-repudiation and confidentiality. The payment is efficient because parties have pre-established instructions with their banks for payment authorisation, routing and settlement that enables the Buyer to initiate a payment on-line, simultaneously with the purchase transaction, instead of through a separate, off-line step. Additional efficiencies are created through standardised payment processing procedures at the banks. In the case where the Seller requires assurance of payment, the Buyer can electronically request its bank, when initiating payment, to assume the responsibility to pay the Seller. This model does not create a new interbank payment system. It is a new channel or front end to initiate payments on existing, back office payment system.

In the early stages iPlanet Trustbase Payment Services will be supporting one kind of scheme:

Eleanor

You need to consult your Eleanor Documentation as to what payment products will be supported by this scheme.

Payment Processing Models

---

Depending on the particular e-commerce application different Payment Initiation models may apply. iPlanet Trustbase Payment Services supports the following Payment Initiation models.

Buyer to Buyer's Financial Institution

This is where the Buyer initiates a payment directly via the buyers bank. This is also referred to, within The Eleanor Payment Initiation Scheme as the Buyer's Financial Institution Model (BFIM)

Identrus Four Corner Model

The Identrus Four Corner model is utilised to provide enhanced payment initiation services to buyers and sellers. Two trading parties with no previous trading relationship can complete an online purchase or trade and simultaneously arrange for a secure, efficient and, optionally, bank certified payment because there exists the Identrus trust model, which contains pre-established banking relationships between businesses and their respective banks. This is also referred to, within The Eleanor Payment Initiation Scheme as the Sellers Financial Institution Model (SFIM)

The "Four Corner" model, as depicted below, forms the basis of the Identrus PKI network.

Figure 1-1    Identrus Four-Corner Model

Four Corner Payment Processing

Both the Buyer's Bank and the Seller's Bank needs to be Identrus scheme members. Both the Buyer and the Seller also need to be Identrus enabled by their banks. Within the Eleanor Scheme this is referred to as SFIM

Figure 1-2    Four Corner Payment Model

(SFIM)

The message flow is as follows:

1. Buyer sends signed payment information to Seller
   1. The Buyer contacts the seller, and places an order.

   2. The Seller provides some payment information for the Buyer to sign with its certificate, which has been supplied by its Identrus bank (Buyer's Bank)

   3. Buyer signs payment information and sends to the Seller.

2. Seller sends message to Seller's Bank
   1. Seller verifies buyer signature.

   2. Seller creates the product (i.e. Payment Order) selected by the communication between itself and the buyer.

   3. Seller signs the Payment Order message with its certificate, supplied by its Identrus bank.

   4. Sends the message to its bank.

3. Seller's Bank sends message to the Buyer's Bank
   1. Seller's Bank verifies certificate and signature of seller's message.

   2. Seller's Bank informs its legacy systems of the received message.

   3. Seller's Bank finds the location of Buyer's Bank from the Buyer's certificate.

   4. Sends message to the Buyer's Bank.

4. Buyer's Bank sends message to the Seller's Bank
   1. Buyer's Bank verifies the Seller's Bank signature and certificate.

   2. Buyer's Bank verifies the Buyer's signature and certificate and also its authority.

   3. Buyer's Bank informs its legacy systems of the received message.

   4. Sends the appropriate response back to the Seller's Bank

5. Seller's Bank sends response to the Seller
   1. Seller's Bank verifies the Buyer's Bank signature and certificate

   2. Seller's Bank informs its legacy systems of the received response.

   3. Re-signs response

   4. Sends response back to the Seller.

6. Seller informs Buyer of result.
   1. Seller verifies the signature and certificate of its bank

   2. Sends the results of the response message back to the Buyer.

Three Corner Payment Processing

The Three-Corner Model (3CM) is a special case of the SFIM where the Buyer and Seller accounts are held at the same bank. The Buyer's Bank needs to be an Identrus scheme member. Both the Buyer and the Seller needs to be Identrus enabled by their bank.

Figure 1-3    Three Corner Payment Overview

The message flow is as follows:

1. Buyer sends signed payment information to Seller
   1. The Buyer contacts the Seller, and places an order.

   2. The Seller provides some payment information for the buyer to sign with his/her certificate, which has been supplied by its Identrus bank (Buyer's Bank)

   3. Buyer signs payment information and sends to the Seller.

2. Seller sends message to the Bank
   1. Seller verifies buyer signature.

   2. Seller creates the product (i.e. Payment Order) selected by the communication between itself and the buyer.

   3. Seller signs the Payment Order message with its certificate, supplied by its Identrus bank.

   4. Sends the message to its bank.

3. Bank sends response to the Seller
   1. Bank verifies certificate and signature of seller's message.

   2. Bank verifies the Buyer's signature and certificate and also its authority.

   3. Bank informs its legacy systems of the received message.

   4. Sends response back to the Seller.

4. Seller informs Buyer of result.
   1. Seller verifies the signature and certificate of its bank

   2. Sends the results of the response message back to the Buyer.

      
      

      ---

      Note	More Information about how each payment scheme defines its Models and Payment products can be found at http://www.identrus.com Examples of supported Schemes include: Eleanor Payment Reference Specification

      ---

      
      

Payment Reference Components

---

In order to initiate a payment around a banking system a number of components are required. The iPlanet Trustbase Payment Services are made up of the following components:

iPlanet Trustbase Payment Services

This comprises of a set of services that are configured within iPlanet Trustbase Transaction Manager and acts as the main banking server to route Payment Messages.

Bank in a Box Back End

Bank in a Box package allows you to test interfacing with legacy systems.

Bank in a Box Admin Tool

In addition to the Back End there is an Admin tool that provides a web interface to the Bank in a Box Back End.

The Seller's Website: Tooledup (SFIM)

This is an example application, in conjunction with the supplied Corporate Payment Initiation Library (CPI) API, that demonstrates how a customer can purchase goods and services through a vendor website that initiates a payment instruction, coupled with the ability to view and cancel a history of payment instructions

Buyers Website (BFIM)

This example, in conjunction with the supplied Corporate Payment Initiation Library (CPI) API, enables a buyer to initiate and cancel payment instructions directly with its bank. This is used when the buyer runs procurement systems or the seller is not a member of the Payment scheme.

Corporate Payment Initiation Library (CPI) API

The Corporate Payment Initiator (CPI) Library API is a Java library providing Eleanor messaging and associated services.