Scenario: Payment Problem

From SWS Challenge Wiki

Contents

[edit]

Service Compositions

The Payment Problem represents an extension of Purchase Order Mediation v2 scenario with an example of purchase order payment initiation procedure. The aim of this scenario is to show how semantic Web technologies can contribute in overcoming problems of goal-based web service compositions.

After receiving an ACK of the purchase order Blue's goal is to initiate purchase order payment by sending a message in the form of UNIFI ISO 20022 Payments Standard Initiation - Customer Credit Transfer Initiation V02 (payment instruction) to its Financial Department (FD). The payment instruction must be compiled with all necessary data from various sources (Blue’s and Moon’s addresses, bank accounts and bank identifiers, PO amount, etc). Under certain circumstances payment instruction must be authorized by Blue's Management Department (MD). Upon payment instruction dispatch Blue expects to receive from its FD UNIFI ISO 20022 Payments Standard Initiation - Payment Status Report V02 message (payment status report).

[edit]

Scenario Details

There are three steps that must be accomplished in order to compile and send a payment instruction:

  1. Moon's banking information must be retrieved (unconditional step). For this step Moon's Financial Information Provider service is used.
  2. The payment should be authorized by Blue's authorization system (conditional step). For this step Blue's Management Department service is used.
  3. The payment must be processed by Blue's payment system (unconditional step). For this step Blue's Financial Department service is used.

Main components taking part in payment instruction completion and processing are depicted in Figure 1.

SWS Challenge - Payment Problem Scenario Overview
Figure 1. SWS Challenge - Payment Problem Scenario Overview

Blue has an internal policy that payments under 2000 Euro can be authorized automatically by using only the Financial Department service (in that case second step could be removed). For payments over 2000 Euro, Financial Department service will reject payment instruction, unless accompanied by an otherwise optional authorization code, which can only be obtained by making a request to the Management Department service. The inputs to the Management Department service are same as those to the Financial Department service, except that an Authority must be designated. This service returns either an authorization code or a denial code. If denial code is returned, the service may be called again, but not with the same Authority as in previous call. The Authority can be any Blue employer by with proper legitimacy, based on the amount of money up to which an authorization can be given.

For example, Jackie Brown can authorize the amounts up to 2000 Euro, and Cathy Johnson up to 3000 Euro. Furthermore, Blue has a policy that the least senior Authority, as determined by increasing amount of money up to which an authorization could be made, should be requested first. The complete list of Authorities and designated amounts can be found in Table 1.

Authority Designated amount
(1) Jackie Brown 2000
(2) Cathy Johnson 3000
(3) Arnold Black 10 000
(4) Peter Petrelli 50 000
Table 1. Authorities and designated amounts
[edit]

Interactions between Blue and Integrator

The messages used in this scenario are simplified versions of the original UNIFI ISO 20022 specification. UNIFI ISO 20022 Payments Standard Initiation defines a set of messages used in financial industry. To describe context of messages we provide simplified Customer Credit Transfer InitiationV02 and PaymentStatusReportV02 as Simplified UNIFI ISO20022 Payment Initiation XML Schema. Within the UNIFI ISO 20022 specification the information is also given using an XML Schema but we have removed some fields to make the messages less complex. The original specification can be found at UNIFI ISO 20022 web page.

A purchase order payment initiation process is initiated by the buyer (Blue) when it sends an PO Payment Initiation message to the endpoint exposed by an Integrator (this one has to be provided by Challenge participant). The PO Payment Initiation message must be confirmed by a Payment Status message. During the compilation process of PO Payment Initiation message the Integrator can make a number of invocations towards Financial Department and Management Department exposed services (implemented and published by Challenge organizers) in order to authorize payment and finally initiate payment processing. The complete list of Message Exchange controls can be found in Table 2.

Table 2. Message Exchange Controls - Blue and Integrator
Name Time to Respond to Message Time to Respond to Message Action
(1) Payment Initiation synchronous - immediately (message 2) no action required
(2) Payment Status no acknowledgment no action required
(3) Payment Initiation Request synchronous - immediately (message 4) no action required
(4) Payment Initiation Response no acknowledgment no action required
(5) Authorization Request synchronous - immediately (message 6) no action required
(6) Authorization Response no acknowledgment no action required


  1. We define elements of Payment Initiation based on simplified UNIFI ISO 20022 in Payment Initiation XML Schema. We provide two examples of Payment Initiation message, one below threshold and other above threshold , which can be used for testing purposes. Challenge participant must build an endpoint to which Payment Initiation messages can be sent. The testbed includes appropriate emulator page allowing to send Payment Initiation to an Integrator implementation and to receive Payment Statuses.
  2. We define elements of Payment Status based on simplified UNIFI ISO 20022 in Payment Initiation XML Schema document. An example of the Payment Status message which should be sent from Integrator in response to Payment Initiation is available at Payment Status message. The Integrator must send this status message back to Blue in synchronous mode, once it receives Payment Initiation message, but after completion of Payment Initiation process(step 1).
  3. We define elements of Payment Initiation Request again based on UNIFI ISO 20022 in simplified Blue's Financial Department XML Schema document. We also provide an example of a Payment Initiation Request, which can be used for testing purposes. The endpoint of Blue to which these messages should be sent from the Integrator is available as a Financial Department Web Service.
  4. We define elements of Payment Initiation Response in Blue's Financial Department XML Schema document. An example of the Payment Initiation Response message which should be sent in response to Payment Initiation Request is available as Payment Initiation Response. The Integrator receives this message as a response to the step 3 message.
  5. We define elements of Authorization Request based on UNIFI ISO 20022 in simplified Blue's Management Department XML Schema document. We also provide an example of a Authorization Request, which can be used for testing purposes. The endpoint of Blue to which these messages should be sent from the Integrator is available as a Management Department Web Service.
  6. Finally, we define elements of Authorization Response in Blue's Management Department XML Schema document. An example of the Authorization Response message which should be sent in response to Authorization Request is available as Authorization Response. The Integrator receives this message as a response to the step 5 message.
[edit]

Interactions between Integrator and Moon

In order to successfully compile Payment Initiation message Integrator must fetch Moon's financial data which consist of bank account number, currency code and SWIFT code. The complete list of Message Exchange controls can be found in Table 3.

Table 3. Message Exchange Controls - Integrator and Moon
Name Time to Respond to Message Time to Respond to Message Action
(1) Banking Information Request synchronous - immediately (message 2) no action required
(2) Banking Information Response no acknowledgment no action required


  1. We define elements of Banking Information Request in Moon's Financial Information Provider XML Schema. We provide an example of Banking Information Request, which can be used for testing purposes. The endpoint of Moon to which these messages should be sent from the Integrator is available as a Moon's Financial Information Provider Web Service.
  2. Finally, we define elements of Banking Information Response in Moon's Financial Information Provider XML Schema document. An example of the Banking Information Response message which should be sent in response to Banking Information Request is available as Banking Information Response message. The Integrator receives this message as a response to the step 1 message.
[edit]

Assumptions

  • Presented scenario deals only with PO payment initiation. It is assumed that actual processing of PO payment is hidden behind Accounting Department system.
[edit]

Quick Links

Web Services


XML Schemas


Sample Messages

Retrieved from "http://sws-challenge.org/wiki/index.php/Scenario:_Payment_Problem"