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

iTPS supports the following Payment products, product codes are expressed in brackets:

• Payment Order (xPx)

• Certified Payment Obligation (xPC)

• Payment Obligation (xPO)

• Conditional Payment Order (CPx)

• Conditional Payment Obligation (CPO)

• Certified Conditional Payment Obligation (CPC)

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). These products are initiated using the iTPS Tooledup Website and Managed using the iTPS Condition and Obligation Management Websites. We now define them in turn

Payment Order (xPx)

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 (xPC)

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

Payment Obligation (xPO)

The commitment from a Buyer to pay a Seller a specified amount on a specified date. There is no obligation on the Buyers Financial Institution to pay if there are insufficient funds available on the due date. The instruction is only revocable bilaterally, i.e. with the assent of the current Holder of the obligation. This product is only supported in the SFI Model, although it will be possible to build it into a procurement application using the CPI library.

Conditional Payment Order (CPx)

The Conditional Payment Order has the same core characteristics as the Payment Order product with the additional requirement that payment will not be released until evidence that all conditions attached to the payment have been met or waived. This product is also unilaterally revocable by the Buyer.

Conditional Payment Obligation (CPO)

The Conditional Payment Obligation has the same core characteristics as the payment Obligation product, with the additional requirement that payment will not be released until evidence that all conditions attached to the payment have been met or waived. As with the Payment Obligation, the Buyers Financial institution is not obliged to make the payment if, for instance, there are insufficient funds available in the Buyers account, and the product is bilaterally revocable.

Certified Conditional Payment Obligation (CPC)

This product has the same core characteristics as the Payment Obligation product, with the additional requirement that payment will not be released until evidence that all conditions attached to the payment have been met or waived. Since the Payment is certified the BFI is obliged to make the payment since 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: Tooled Up (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.

Condition Management

This appears as a separate website and is used to hold Payments in a Registry until all conditions have been met.

Obligation Management

This occurs when Payments are transferred from one institution to another. Under such circumstances a website is needed to manage payment transfers within a Registry until they are complete.

Architectural Overview

---

The product comprises of a number of distinct components. Each of these components has a distinct set of interfaces that may be categorised as public or private. Every bank implements both the Buyer's Bank and Seller's Bank roles. There is no concept of a separate deliverable for Buyer's Bank and Seller's Bank. The following table identifies the classification of each of the product components. This is necessary as some of the delivered components are not intended for use in an operational environment These components are however required for the Eleanor Reference Application (ERA) contract signed with Identrus, and will be delivered to provide customers with a `working' payments initiation solution for internal and interoperability testing.

Component	Category	Installation Directory
iWS 6.0 SP2 and iAS 6.5	Standard product	/opt/iws6 and /opt/ias6
ITTM 3.0.1	Standard product	/opt/ittm
ITPS 2.0 Core services	Private	/opt/ittm
IMQ for Java 2.0	Standard product	/opt/SUNWjmq
JMS Proxy	Private	/opt/ittm
Bank in a Box Back End	Public	/opt/itps-biab
Bank in a Box Admin Tool	Public	/opt/itps-biab
Condition Management Web site	Public	/opt/itps-cond
BFI web site	Public	/opt/itps-bfi
Obligation Management web site	Public	/opt/itps-om
CPI	Private	/opt/itps-cpi

The categories are:

•    Standard product - Provided as another product

•    Private - Supplied with no ability to directly extend

•    Public - Supplied as either source code or the ability to extend programmatically

Only private components are licensed for use in production environments. The diagram below illustrates how the components fit together for both the buyer and buyers bank (blocks on the left) and the seller and the sellers bank (blocks on the right).

Figure 1-4    Architectural Overview