 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 229: Payment API
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: Enabling application developers to initiate mobile payment transactions in J2METM applications. Please direct comments on this JSR to the Spec Lead(s) Team
The following updates were made to the original request: 2009.07.06: The Maintenance Lead changed to Sun Microsystems. Specification Lead: Jean-Yves Bitterlich E-Mail Address: jean-yves.bitterlich@sun.com Telephone Number: +49 89 46008 1097 Fax Number: - 2005.10.17: The Maintenance Lead changed from Siemens AG to BenQ Corporation. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Siemens Name of Contact Person: Jean-Yves Bitterlich E-Mail Address: jean-yves.bitterlich@siemens.com Telephone Number: +49 89 722 58563 Fax Number: +49 89 722 35087 Specification Lead: Jean-Yves Bitterlich E-Mail Address: jean-yves.bitterlich@benq.com Telephone Number: +49 89 722 58563 Fax Number: +49 89 722 35087 Initial Expert Group Membership:
Supporting this JSR: Motorola Section 2: Request
2.1 Please describe the proposed Specification:The purpose of this JSR is to define the following:
Both will allow 3rd party developers to build applications with control of features and services that are chargeable.
The JSR API may include methods for 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target Java platform is the J2ME. This optional package will run on both configurations CDC and CLDC. 2.3 What need of the Java community will be addressed by the proposed specification?The only way to gain revenue for a J2ME application developer until now was either to sell the application or be paid per download. This JSR will provide a solution to allow J2ME application developers to gain revenue at a finer grained basis controlled directly from within J2ME applications, i.e. pay per level, and pay per feature... By having a standard payment API, 3rd party developers? productivity will be increased. 2.4 Why isn't this need met by existing specifications?Neither the CLDC and CDC nor any available profile or API specifications do not cover payment. In particular the focus of JSR-182 (Payment API for the Java platform) is different: while the proposed JSR will define an API between a (mobile) application and a payment facility, JSR-182 concentrates on handling of payment interactions with web-based services. Therefore, JSR-182 could be used to implement one of the payment methods as supported by this proposal (i.e. JSR-182 is one possible payment instrument). 2.5 Please give a short description of the underlying technology or technologies:This JSR focuses on the definition of a generic API that covers any payment methods (e.g. premium priced SMS or others), which themselves are based on different existing communication bearers (e.g. http, GSM). 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Package: javax.microedition.payment 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?Probably no. 2.9 Are there any internationalization or localization issues?No (interface does not deal with text). 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.11 Please describe the anticipated schedule for the development of this specification.Community Draft: E-Q2/2004 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.It is anticipated that a combination of email discussion, feedback on regular drafts, conference calls and face-to-face meetings will work well. 2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Due to the optional package character of this request, RI and TCK will be delivered as standalone products. 2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Early information on license terms as defined in the JCP process: Siemens will license to all interested parties. TCK and RI will be available separately for license, independent
implementations will be allowed. 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.- JSR 30: Connected, Limited Device Configuration Specification (CLDC) 3.2 Explanation of how these items might be used as a starting point for the work.Due to the optional package character of the request, considerable cross references towards configurations and profiles the package is based on are expected. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
