Summary | Proposal | Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 182: JPay - Payment API for the JavaTM Platform
This JSR has been Dormant
Section 1. Identification
Submitting Member: Siemens
Name of Contact Person: Karsten Luettge
E-Mail Address: karsten.luettge
Telephone Number: +49 (0) 30 386 23429
Fax Number: +49 (0) 30 386 44255
Specification Lead: Karsten Luettge
E-Mail Address: karsten.luettge
Telephone Number: +49 (0)30 386 23429
Fax Number: +49 (0)30 386 44255
Initial Expert Group Membership:
Supporting this JSR:
Section 2: Request
2.1 Please describe the proposed Specification:
This JSR requests the creation of the Payment API for the Java Platform (JPay) specification. The JPay API will support payments in an open, Web-like environment.
In particular, the JPay API will allow Java applications (typically Web applications or Java enabled content servers) to utilize a 3rd party's payment service to charge users for using the application or accessing the content. The payment service could be for instance a Parlay gateway providing the Parlay Content Based Charging function or an implementation of the emerging PayCircleTM Payment Web Service specification.
The payment service will conduct payments between the content provider, who runs the Java application, and a consumer, who uses the application. The JPay API will provide the application programmer with local access to the payment functionality provided by the 3rd Party's payment service.
The functionality to be provided to the application programmer via the JPay API will be as close as possible to the Parlay 4, 3GPP/OSA Rel-5 and ETSI/OSA 2 Content Based Charging API and to PayCircle's Payment Web Service specification. It will provide access to these APIs, independent of a particular implementation or distribution technology. It will provide means to
JPay will be derived from the above mentioned specification according to the Java Realization Rulebook, that has been created by Parlay's Java Realization Workgroup.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
The JPay specification is targeted for the Java 2 Platform, Standard Edition (J2SE) and the Java 2 Platform, Enterprise Edition (J2EE). It shall be implementable as a local service provider, or preferrably as a J2EE connector. In particular, a JPay connector shall support HTTP servlets as the typical implementation technology for Web applications.
2.3 What need of the Java community will be addressed by the proposed specification?
The JPay API will allow application providers to charge their users for application usage by utilizing a 3rd party's payment service.
The JPay API will be part of a Java technology instantiation of the ETSI/OSA, Parlay and 3GPP/OSA specifications. In particular, it will provide such an instantiation of the ETSI/OSA/Parlay Content Based Charging API.
2.4 Why isn't this need met by existing specifications?
There exists no Java API to represent a Content Charging or Payment API at present.
2.5 Please give a short description of the underlying technology or technologies:
It is anticipated that the proposed API would be implemented on a local client to access external payment services in a controlled and secure way, in particular over the public internet.
The API shall allow implementations according to the J2EE connector architecture. In particular, a J2EE connector implementing the API shall be usable from within a HTTP servlet.
The proposed API shall be independent of the underlying communication protocol. However, special attention shall be given to support at least the Parlay Content Based Charging API, or to the PayCircleTM Payment Web Service specification.
It is essential that the JPay API seamlessly interoperates with other Java technology instantiations of the ETSI/OSA, Parlay and 3GPP/OSA specifications.
It is highly desired that the JPay API seamlessly interoperates with the JAIN APIs including but not limited to:
However, the JPay API shall not depend on any JAIN API, but rather allow a self-contained implementation as well.
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
The specification will be provided directly in, and in subpackages of:
javax.payment or javax.jain.payment
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
2.8 Are there any security issues that cannot be addressed by the current security model?
For further study.
2.9 Are there any internationalization or localization issues?
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
2.11 Please describe the anticipated schedule for the development of this specification.
- Expert group creation as soon as the JSR is approved (possibly at JAIN community meeting April 22nd - April 26th 2002)
2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.
- Technical sessions hosted during PayCircle, JAIN, ETSI, Parlay and/or 3GPP meetings.
Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.
- PayCircle XML Spec Draft
3.2 Explanation of how these items might be used as a starting point for the work.
The UML model of Parlay 4/3GPP/OSA Rel-5/ETSI/OSA 2 Content Based Charging would form the basis of the JPay API. The Parlay UML-to-JAIN SPA "Java API Realization" rulebook and automation scripts would be used to rapidly create a Community Review draft of the JPay API.
Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
In addition to the development of the JPay specification, the Expert Group will deliver the following:
- A "JPay API User Guide" describing the API in some detail. The guide should contain example applications together with associated sequence diagrams and Java code.