All Packages  Index

Payment Extension for the Transfer Layer

Author: N. Asokan (ZRL) (until Oct 31, 1997)
Editor:  N. Asokan (ZRL) (until Oct 31, 1997), J.Brauckmann (SRB)
Reviewer: T. Beiler (SRB)
@version [CVS] @(#) $Id: index.html,v 1.1 1997/07/29 07:32:02 semper Exp $

---

Changes

• Original issue:
  How can the caller (e.g. commerce layer) pass certain relevant pieces of information to the payment block on the receiver side. Examples of such pieces of information are:
  • security attributes for the transfer,
  • identity of the payer,
  • limitations on the set of purses and payment systems to be used for the particular transaction,
  • limitations on currency for the particular transaction,
  These pieces are not always needed. But they might be; therefore, we must have a mechanism to pass them down when needed.
  Solution:
  The attributes that were given by the caller are present in a _offeredAttributes variable. In addition, a PaymentAttribute was defined, which can be put into the attribute set and which may contain the information requested in the above paragraph.
• Original issue:
  The transfer consists of two phases:
  • negotiation and parameter selection
  • the actual transfer
  If something goes wrong during the transfer, it must be possible to give specific feedback to the caller. For this, appropriate exception or error hierarchy must be defined.
  Solution:
  There is now one exception TXContextCommException that may be thrown by a transfer. Later, the payment extension of the txlayer may define a subclass of this to provide different exceptions for negotiation and transfer errors.

TODO

• There are places when the PaymentTransfer object must be written to stable storage. Since this is not payment specific, a method to write itself to stable storage must be provided by TransferTransaction