Payment 1 1 Mrel Spec

Payment API (PAPI)
For JavaTM 2 Platform, Micro Edition
JSR-229
Version 1.1.0 Maintenance Release
JSR-229 Expert Group jsr-229-eg@jcp.org
Java Community Process (JCP)

BenQ Mobile GmbH & Co. OHG , 2005
COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

Payment API Specification ("Specification") Version: 1.1.0 Release: 16-Jan-2006 Status: FCS Specification Lead: BenQ Mobile GmbH & Co. OHG ("Specification Lead") Copyright 2005,2006 BenQ Mobile GmbH & Co. OHG All rights reserved. SPECIFICATION LICENSE AGREEMENT BENQ MOBILE GMBH & CO. OHG ARE WILLING TO LICENSE THIS SPECIFICATION TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LICENSE AGREEMENT ("AGREEMENT"). PLEASE READ THE TERMS AND CONDITIONS OF THIS LICENSE CAREFULLY. BY DOWNLOADING THIS SPECIFICATION, YOU ACCEPT THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. IF YOU ARE NOT WILLING TO BE BOUND BY ITS TERMS, SELECT THE "DECLINE" BUTTON AT THE BOTTOM OF THIS PAGE AND THE DOWNLOADING PROCESS WILL NOT CONTINUE. The Specification is protected by copyright and the information described therein may be protected by one or more U.S. patents, foreign patents, or pending applications. Except as provided under the following license, no part of the Specification may be reproduced in any form by any means without the prior written authorization of the Specification Lead and its licensors, if any. Any use of the Specification and the information described therein will be governed by the terms and conditions of this license and the Export Control Guidelines as set forth in the Terms of Use on the Sun's website. By viewing, downloading or otherwise copying the Specification, you agree that you have read, understood, and will comply with all of the terms and conditions set forth herein. The Specification Lead hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under the Specification Lead's intellectual property rights that are essential to practice the Specification, to internally practice the Specification for the purpose of designing and developing your Java applets and applications intended to run on the Java platform or creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java.*" or "javax.*" packages or subpackages or other packages defined by the Specification; (vi) satisfies all testing requirements available from the Specification Lead relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any of the Specification Lead's source code or binary code materials; and (viii) does not include any of the Specification Lead's source code or binary code materials without an appropriate and separate license from the Specification Lead. The Specification contains the proprietary information of the Specification Lead and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from the Specification Lead if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification. TRADEMARKS No right, title, or interest in or to any trademarks, service marks, or trade names of Sun or Sun's licensors, the Specification Lead or the Specification Lead's licensors is granted hereunder. Sun, Sun Microsystems, the Sun logo, Java, Java Compatible, and the Java Coffee Cup logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. DISCLAIMER OF WARRANTIES THE SPECIFICATION IS PROVIDED "AS IS" AND IS EXPERIMENTAL AND MAY CONTAIN DEFECTS OR DEFICIENCIES WHICH CANNOT OR WILL NOT BE
JSR-229 Payment API

CORRECTED BY THE SPECIFICATION LEAD. THE SPECIFICATION LEAD MAKES NO REPRESENTATIONS OR WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE OR THAT ANY PRACTICE OR IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADE SECRETS OR OTHER RIGHTS. This document does not represent any commitment to release or implement any portion of the Specification in any product. THE SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION THEREIN; THESE CHANGES WILL BE INCORPORATED INTO NEW VERSIONS OF THE SPECIFICATION, IF ANY. THE SPECIFICATION LEAD MAY MAKE IMPROVEMENTS AND/OR CHANGES TO THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THE SPECIFICATION AT ANY TIME. Any use of such changes in the Specification will be governed by the then-current license for the applicable version of the Specification. LIMITATION OF LIABILITY TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL THE SPECIFICATION LEAD OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY FURNISHING, PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF THE SPECIFICATION LEAD AND/OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You will indemnify, hold harmless, and defend the Specification Lead and its licensors from any claims arising or resulting from: (i) your use of the Specification; (ii) the use or distribution of your Java application, applet and/or clean room implementation; and/or (iii) any claims that later versions or releases of any Specification furnished to you are incompatible with the Specification provided to you under this license. RESTRICTED RIGHTS LEGEND If this Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in the Software and accompanying documentation shall be only as set forth in this license; this is in accordance with 48 C.F.R. 227.7201 through 227.7202-4 (for Department of Defense (DoD) acquisitions) and with 48 C.F.R. 2.101 and 12.212 (for non-DoD acquisitions). REPORT You may wish to report any ambiguities, inconsistencies or inaccuracies you may find in connection with your evaluation of the Specification ("Feedback"). To the extent that you provide the Specification Lead with any Feedback, you hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis, and (ii) grant the Specification Lead a perpetual, nonexclusive, worldwide, fully paid-up, irrevocable license, with the right to sublicense through multiple levels of sublicensees, to incorporate, disclose, and use without limitation the Feedback for any purpose related to the Specification and future versions, implementations, and test suites thereof.
JSR-229 Payment API
JSR-229 Payment API
Content
Content ................................................................................................................................ 5 Preface................................................................................................................................. 7 Revision History ................................................................................................................. 7 Who Should Use This Specification ................................................................................... 9 How This Specification Is Organized ................................................................................. 9 Related Literature.............................................................................................................. 10 1 Introduction and Background................................................................................... 11 1.1 Introduction........................................................................................................ 11 1.2 Expert Group...................................................................................................... 11 1.3 Document Conventions...................................................................................... 12 2 Scope and Requirements .......................................................................................... 13 2.1 Scope.................................................................................................................. 13 2.2 Requirements ..................................................................................................... 13 2.3 MIDP vs IMP..................................................................................................... 14 3 Architecture.............................................................................................................. 15 3.1 Overview............................................................................................................ 15 3.2 General Architecture.......................................................................................... 15 3.3 Functional Overview.......................................................................................... 15 3.4 Actors and Roles................................................................................................ 16 3.5 Application Responsibilities .............................................................................. 18 3.6 Payment Module Responsibilities...................................................................... 18 3.7 Payment Adapter Responsibilities ..................................................................... 20 4 Package javax.microedition.payment....................................................................... 22 4.1 Overview............................................................................................................ 22 4.2 Design ................................................................................................................ 23 4.3 Interface TransactionListener ............................................................................ 23 4.4 Interface TransactionRecord.............................................................................. 24 4.5 Class TransactionModule................................................................................... 27 4.6 Class TransactionModuleException .................................................................. 32 4.7 Class TransactionListenerException.................................................................. 33 4.8 Class TransactionFeatureException................................................................... 34 4.9 Class TransactionPayloadException.................................................................. 34 4.10 Code Sample ...................................................................................................... 36 5 System Functions ..................................................................................................... 38 5.1 Overview............................................................................................................ 38 5.2 System Properties .............................................................................................. 38 6 Provisioning ............................................................................................................. 39 6.1 Overview............................................................................................................ 39 6.2 JAD Resource .................................................................................................... 39 6.3 JAR-Manifest Resource..................................................................................... 42 6.4 Update................................................................................................................ 47 6.5 Examples............................................................................................................ 49 7 Security..................................................................................................................... 51 7.1 Requirements ..................................................................................................... 51 7.2 Applications ....................................................................................................... 51 7.3 Provisioning Data .............................................................................................. 52 7.4 Storage ............................................................................................................... 52 7.5 Payment Module ................................................................................................ 53 7.6 Non-GUI Platforms............................................................................................ 53 7.7 Summary............................................................................................................ 54 8 Adapters ................................................................................................................... 55 8.1 Overview............................................................................................................ 55 8.2 Registered Adapters Namespaces ...................................................................... 55
JSR-229 Payment API

8.3 Standardizing New Adapters ............................................................................. 55 8.4 Experimental Adapters Naming Convention ..................................................... 55 9 Technology Compatibility Kit (TCK) ...................................................................... 56 10 Glossary.................................................................................................................... 57 Appendix A. Implementation Notes .............................................................................. 58 A.1 How To Handle Missed Transactions................................................................ 58 A.2 Management of Past and Missed Transactions .................................................. 58 A.3 Transaction Module Initialization...................................................................... 59 A.4 Provisioning Update .......................................................................................... 59 A.5 AMS/JAMs tasks.............................................................................................. 60 A.6 Implementing in Java......................................................................................... 60 Appendix B. More Responsibilities............................................................................... 61 B.1 Application Developer....................................................................................... 61 B.2 Application Provider.......................................................................................... 61 B.3 Price Manager .................................................................................................... 61 B.4 Payment Service Provider.................................................................................. 62 B.5 Payment Module Implementer........................................................................... 62 B.6 Payment Adapter Implementer .......................................................................... 62 Appendix C. Adapter Specifications ............................................................................. 63 C.1 Adapter: Premium Priced SMS.......................................................................... 63
JSR-229 Payment API
Preface
This document, Payment API Specification (JSR-229), specifies the optional application programming interface to enable payment for JavaTM 2 Platform, Micro Edition (J2METM).
Revision History
Date 01-Apr-2004 07-Apr-2004 16-Apr-2004 Version 0.1.0 0.2.0 0.3.0 Description Initial Draft - Renamed commit() into process() - Updated a few exception inconsistencies - Add support for localization in the Manifest - Changed notify() name and signature - Moved constants to TransactionRecord - Improved definition of SUCCESSFUL field - Added support for updating/upgrading the Manifest - Added support for updating <InstrumentName> blocks - Made price information optional in the Manifest - Added support for Pay-*-Cache in the Manifest - Cleaned up throw definition for trivial exceptions - New chapter 9 Actors Responsibilities - Added support for debug options in JAD - New chapter 7 Security - Changed signature for missed transactions handling - Duplicated Pay-Max-Payload-Size in JAR & JAD - Redefined SMS format and APPID definition - TransactionModule is not more to be a singleton - Updated JAD/JAR sample - Updated Java code sample - Added Pay-Debug-DemoMode options - Corrected sample code - de-static-fied methods in TransactionModule class - Changed definitions of pay-max-payload-size - Few definition consistency corrections - Added new methods to TransactionRecords - Few consistency and typo corrections - Changed 3-letters to 2-letters language codes (ISO639) - Added Pay-Language Property field in the Manifest - Precise relationships between Pay-Debug options - Integration of the Security aspects (draft) - Dummy mandatory test adapter - Changed TransactionRecord signature - Added Factory in TransactionModule - Removed CDC from the target platform list - Combined SMSN and SMSC adapters - Removed Dummy adapter (TCK issue!) Early Draft - Removed getFeatureProperty() method - Removed getFeatureIDs() method - Removed chapter 5 Property Field Name - Changed Definition of Pay-Feature
23-Apr-2004
0.4.0
30-Apr-2004 07-May-2004 14-May-2004 18-Jun-2004
0.5.0 0.6.0 0.7.0 0.8.0
02-Aug-2004
0.8.3
03-Aug-2004 14-Sep-2004
0.8.5 0.8.6
JSR-229 Payment API

- English no more mandatory for descriptions - Now symmetric language translations - Renamed field TRANSACTION_UNSUCCESSFUL - Changed signature of process(): now returning handle - Added new chapter 10: TCK - Added Provisioning Info Update examples - Changed Pay-Update-URL scheme definition - Refined Payment Instruments terminology - Renamed field Pay-Instruments in Pay-Adapters - Renamed field Pay-Instruments-Title in Pay-Providers - Registering text/vnd.sun.pay.provision at IANA - Changed TransactionRecord class to Interface - Removed createTransactionRecord() method - Enhanced chapter 3.6 with Method Selection - Add chapter 3.7 Payment Adapter Responsibilities - Add chapter Trust Relationships in chapter 3.4 - Moved Actors Responsibilities to Appendix B Public Draft - Text reviewed for typos and similar errors - Text clarifications - Removed provider-specific update mechanism - SMS format can now be freely defined in the Manifest - Removed APPID concept in SMS definition - Removed Pay-Feature-<n>-Lang-<lc> - Removed Pay-Languages - Fixed Payload size defined across all payment adapters - Removed Pay-Max-Payload-Size - Added two more parameters to process() method - License Terms changed to Pre-FCS terms - Added new Pay-Update-Stamp property - Updated UML Diagram - Add chapter 8.4 Standardizing New Adapters - Diagrams and text reviewed and clarified - Changed Prefix definition for the SMS-adapter - Removed CREDITC adapter pseudo-definition - Samples (JAD/JAR) remastered - Add chapter 7.1 Security Design - Text reviewed for typos and similar errors - Update issues clarified - Specified SMS <Prefix> format - Changed Cache fieldname to Pay-Cache - Changed TxModule to use Object and not MIDlet - Add clarification about Update Policies in A.4 - Add Expiration-Date support in Pay-Cache Proposed Final Draft - Few clarifications - Reviewed by Language Service - Plastic Roaming note in chapter 7.4 - Reorganized and Reviewed chapter 6 Security - License Terms changed to Pre-FCS terms Final Release - Removed dead references - Enhanced description when no adapter is present - Moved PPSMS adapter specification into Appendix C - Updated Inconsistency on page 27 - Reviewed Licensing terms and Copyright - Added new Chapter System Functions - Added system prop. microedition.payment.version - Clarified Transaction Module Initialization on page 59 - Add optional Reason in past transactions Maintenance Release
22-Sept-2004
0.8.7
27-Sept-2004 15-Nov-2004
0.8.8 0.8.9
14-Jan-2005
0.9.0
02-Feb-2005
0.9.1
04-Feb-2005 17-Feb-2005 04-Mar-2005 29-Mar-2005 13-Apr-2005 01-Sept-2005 08-Sept-2005 09-Nov-2005
0.9.2 0.9.3 0.9.4 0.9.5 1.0.0 1.0.1 1.0.2 1.0.3
16-Jan-2006
1.1.0
JSR-229 Payment API
Who Should Use This Specification

The audience for this document is the Java Community Process (JCP) expert group defining this API, implementors of the Payment API, and application developers targeting the Payment API.
How This Specification Is Organized

The topics in this specification are organized according to the following chapters: Chapter 1: Introduction and Background Chapter 2: Scope and Requirements Chapter 3: Architecture Chapter 4: Package javax.microedition.payment Chapter 5: System Functions Chapter 6: Provisioning Chapter 7: Security Chapter 8: Adapters Chapter 9: Technology Compatibility Kit (TCK) Appendix A: Implementation Notes Appendix B: More Responsibilities Appendix C: Adapter Specifications
JSR-229 Payment API
Related Literature
The JavaTM Language Specification by James Gosling, Bill Joy, and Guy L. Steele. AddisonWesley, 1996, ISBN 0-201-63451-1 The JavaTM Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm and Frank Yellin. Addison-Wesley, 1999, ISBN 0-201-43294-3 Connected, Limited Device configuration (JSR-30), Sun Microsystems, Inc. J2ME Platform Specification (JSR-68), Sun Microsystems, Inc. Mobile Information Device Profile 2.0 (JSR-118), Sun Microsystems, Inc. Information Module Profile- Next Generation (JSR-228), Siemens AG and Nokia.
10
JSR-229 Payment API
1 Introduction and Background

1.1 Introduction
The Payment API specification defines an optional package1 for the Java 2 Platform, Micro Edition (J2ME). The specification has been produced in response to Java Specification Request 229 (JSR-229), and specifies the architecture and associated APIs that enables an open, thirdparty, application development environment for payment transactions.
1.2
Expert Group
This specification was produced by the Payment API Expert Group (PAPI-EG). The following companies and representants, listed in alphabetical order, are members of the PAPI-EG: Aplix Corporation: Esmertec AG: Gemplus Corporation: In-Fusio SA: Iopsis Software Inc.: Matsushita Electric Industrial Co, Ltd: Nokia Corporation: BenQ Mobile GmbH & Co OHG: Siemens AG: Sun Microsystems, Inc.: Symbian Ltd: T-Mobile International AG & Co. KG: Michael Leone Claus Rasmussen Remy Cricco Thomas Landspurg Ash Parikh Kyoko Ohshima, Kristian Woodsend Vikas Chawla, Jaakko Halme, Jari Otranen Jean-Yves Bitterlich2 Michael Becker, Jochen Sauter Lei Liu, John Pampuch Jonathan Allin Robin Jewsbury
Sony Ericsson Mobile Communication AB: Pr Anders Aronsson
As well as the following individuals: Andrew Beacock, Roderick Farrugia, Damon Hart-Davis, Pavel Lahoda
1 2
The definition and usage of a J2ME optional package is defined in JSR-68, J2ME Platform Specification Specification leader
JSR-229 Payment API
11
1.3
Document Conventions
1.3.1 Definitions
This document uses http://www.ietf.org/) Term MUST MUST NOT SHOULD definitions based upon those specified in RFC-2119 (See
TABLE 1-1 Specification Terms
Definition The associated definition is an absolute requirement of this specification. The definition is an absolute prohibition of this specification. Indicates a recommended practice. There may exist valid reasons in particular circumstances to ignore this recommendation, but the full implications must be understood and carefully weighed before choosing a different course. Indicates a non-recommended practice. There may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Indicates that an item is truly optional.
SHOULD NOT
MAY
1.3.2 Formatting Conventions

This specification uses the following formatting conventions.
TABLE 1-2 Formatting Conventions
Convention Courier New Italic
Description Used in all Java code including keywords, data types, constants, method names, variables, class names, and interface names. Used for emphasis and to signify the first use of a term.
12
JSR-229 Payment API
2 Scope and Requirements

2.1
Scope
A generic, optional API to initiate payment transactions in a secured manner to transparently expedite the chargeable service requests, which are originated from J2ME applications, with external operator charging service delivery, payment service protocols, pricing management and implementation logic The syntax for the description of the associated payment provisioning data, enabling API implementers to support different payment adapters
The scope 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 includes methods for: Requesting a payment transaction Requesting feature and service price management Payment service availability
The definition of provisioning data ensures that service providers and payment service providers can select a suitable set of payment adapters provisioned for applications on application deployment time. The following types of payment adapters are primarily addressed: Operator charging 3rd-party payment service providers
This JSR enables application developers to initiate mobile payment transactions from MIDP applications. It is an optional package for the J2ME CLDC configuration and targeted at MIDP and IMP devices. The scope of this JSR is to provide a generic payment initiation mechanism that hides the actual payment architecture and complexity from the developers. This JSR does not define and imply any concrete payment implementation and mechanism, but is generic enough to support different implementations. It is up to the implementing party to realize the API based on one or more technical solutions enabling the application-initiated payment. The JSR also does not define any user behavior or user interface, but leaves them open to be defined by the actual implementation of the API.
2.2
Requirements
The requirements listed in this chapter are additional requirements beyond those found in Connected, Limited Device Configuration (JSR-30) and in either Mobile Information Device Profile 2.0 (JSR-118) or Information Module Profile- Next Generation (JSR-228). The Payment API is an optional package that runs on the CLDC configuration and either the MIDP profile (JSR-118) or the IMP profile (JSR-228). As such, the API specified in this document defines no requirements for the software (besides those relating to the availability of the configuration and the profiles themselves). However, the implementation of the payment module or of a particular payment adapter may have additional requirements if implemented in Java. A Java-based implementation of the Premium-Priced SMS(PPSMS)-based payment adapter may
JSR-229 Payment API
13

require JSR-120 or JSR-205, a stored value account-based payment may require the FileConnection API, and other 3rd-party payment services may have their own requirements. Such requirements are defined on a case-by-case basis.
2.3
MIDP vs IMP
This specification requires MIDP or IMP. Both profiles are very similar and differ mainly in that MIDP supports a graphical user interface subsystem whereas IMP does not. The consequence is that IMP cannot directly interact with the end user as MIDP could. Because of the similarity of both profiles, the following specification has been written for MIDP and refers to MIDlets, although the reader may indistinctly also apply it to IMP and IMlets, making the corresponding changes where appropriate. However, the specification also integrates notes where differences apply. The reader may also refer to chapter 7.5 and Appendix A for further information.
14
JSR-229 Payment API
3 Architecture
3.1 Overview
This chapter addresses issues that both implementers and developers will encounter when implementing and developing the Payment API and payment adapters. While not comprehensive, this chapter does reflect the most important issues agreed on by the PAPI-EG.
3.2
General Architecture
As stated before, the goal of the PAPI-EG is to create an open, third-party application development environment for payment-enabled Java applications. It will not define or imply any concrete implementation for the core payment module or any of the payment adapters. The following picture illustrates the relative position of the components on the terminal side in a payment transaction. Although it does not imply any concrete implementation, it suggests a flexible architecture. An implementer can also choose to integrate only one particular payment adapter or even only one instance of that particular adapter and combine the Payment API, the payment module and the corresponding payment adapter into one software component. However, the specification always refers to the following figure.
Java application
Payment API
MIDP /IMP
__ Payment module Payment Payment _adapter adapter
CLDC Native platform

It is up to the implementer to define the final architecture of the payment module and payment adapters, as well as whether those components are implemented in Java or any other languages.
3.3
Functional Overview
The overview of the decomposition into subsystems and functionalities is shown in the following figure. The purpose of the decomposition is to define a minimal set of functionalities and roles associated with different terminal and server components and actors needed to deploy JSR-229 services.
JSR-229 Payment API
15
End user
Application developer
Provides application Delivers application
Application provider /merchant
Interacts with
Implements
Provisions application Contracts Price manager
Application Provisions application Requests payment Pay API Payment module Pay. adapter Terminal
Notify & forward payload
Provisions Payment service provider
Commits payment Implements
Provides Manufacturer
Standardizes payment method Implementer (JSR/module/ methods)
Provides
Legend: <Role> <Component>
3.4
Actors and Roles
A description of the actors, as shown in the previous diagram, is given below. However, practice will show that some roles may be combined as, for instance, the role of the price manager can be combined with either the payment service provider or the application provider.
Description
Application: Java applications contain business logic for chargeable features. Those features are charged using the API methods provided by this JSR. They are also responsible for persisting their internal state: e.g., after a payment has been made successfully for a certain feature, it is desirable to have that feature still enabled after the application restarts. Java applications must contain provisioning data as part of the JAR-Manifest file that is injected by the merchant at application deployment time. Payment module (or transaction module): Implements functionality needed to manage one or more payment adapters and one or more instances of each adapter. It contains provisioning data interpreters and dispatches the provisioning information among the registered payment adapters. It will also interact with the end user (if any) when needed and dispatch function calls and parameters to the Payment API to the corresponding payment adapter implementation. Payment adapters (or payment methods): Implement terminal-side logic needed to process a payment based on the applications request, the users choice and the provisioning information. It contains provisioning data interpreters and communication protocol implementations. It also supports forwarding a (limited) payload along with the payment transaction to the application
16
JSR-229 Payment API

provider through the payment service provider. This entity may conduct the actual payment transaction with a remote (network service) counterpart. Implementer: A third party implementing the payment module and/or payment adapter(s) in conformance with this JSR. Manufacturer: Actor integrating the payment module and pre-installing a set of payment adapters on particular devices. Payment service provider (PSP): A provider supporting the server side of one or more payment adapters. It provides provisioning information for the price manager. Depending on the type of payment method implemented by the adapter, this actor is also the confirming part for a successful payment. Usually there will be as many payment service providers as instances of that given payment adapter. For instance: PSPs corresponding to a credit card adapter will include VISAPSP, AMEX-PSP and MasterCard-PSP. Price manager: This actor is responsible for setting the prices. Its price information is always upto-date and informs the payment service provider whenever prices or any related information have changed. Application provider/merchant: Entity that receives payment-enabled applications from the developer and delivers them. During the deployment phase, the merchant injects provisioning data into the JAR application and signs it to protect provisioning data integrity. This actor acts as an application server and has a commercial relationship with the price manager from whom it gets the latest price-related provisioning information. This entity may also implement network-side application logic (e.g. a high-score server). Application developer: Java applications can implement business logic for chargeable features that use JSR-229. A payment request must then be fulfilled by the underlying implementation. The developer has a business relationship with the merchant who performs application distribution and revenue sharing. It shall be noted that the model here does not exclude the possibility of having a developer to act as an individual merchant, but then the set of requirements for the merchant role also applies.
Trust Relationships
The end users trust the payment module of their terminal device that the implementation and thereby any application will never make any payment transaction without the users acknowledgment. They trust the payment module and the underlying payment adapters that any private or critical information (credit card numbers, PIN, etc.) will never be made public nor transferred to any network servers if not part of the standardized or proprietary payment protocol. Application developers trust the application providers that their application will not be altered and will be available for download. They also trust them for correct settlement. They trust the manufacturer for correct and safe (as defined by this application) implementation. The application provider trusts the price manager for correct settlement. The payment service providers trust the manufacturers that their terminals are safe and are fully compliant with this specification. They trust the price manager that the provisioning information (in particular prices and URLs) is forwarded to the application provider without tampering. The manufacturer trusts the (implementer of the) payment adapter that it correctly implements the payment protocol it has been designed for and does not include any malicious functionality.
JSR-229 Payment API
17

The price manager trusts the payment service provider for correct settlement.
3.5
Application Responsibilities
Status/History
Applications are responsible for managing their internal state regarding purchased features. The application must store state information for persistent storage to allow the end user to continue using a purchased feature when the application is started next time. Such application-specific state information might be, for example, the last game level for which a payment request has been issued. Only the application itself can take care of it because the representation/meaning of a feature is part of the applications logic. Security issues related to storing the applications internal state are discussed in chapter 7.
3.6
Payment Module Responsibilities
Responsibilities refer here to functionalities that are provided by the payment module component but are not directly accessible by Java applications. These functions, such as price update, can be offered to the end user directly by the payment module by providing an appropriate user interface.
Provisioning Mapping
Java applications are provided including provisioning data for the different payment adapters. It is the payment modules task to load the payment provisioning data from the JAR-Manifest Resource file, find possible syntax errors (and, if so, signal them to the end user) and map them to the appropriate payment adapter. Moreover, provisioning data is linked to a particular application or the suite it may belong to, and cannot be (re)used for another application. It is up to the implementation to decide when to map: it might be parsed at download/installation time by the AMS3 (a.k.a. JAM4) or at application startup by the AMS or even during the applications runtime at TransactionModule construction time. In case there is nothing to map (i.e. provisioning information provided along with the application does not match any of the locally installed payment adapters (if any)), the user will have no means by which he will be able to submit a payment request using that application. The user must be informed and be offered to choose to continue with this application or not. This confirmation dialog must be shown at TransactionModule construction time (refer to section A.3).
Method Selection
The Payment API is payment adapter agnostic. Therefore, if several payment adapters are installed, it is the responsibility of the payment module to offer the user (if any) a selection dialog or system to choose the optimal payment method under the current circumstances. It is also the responsibility of the payment module to inform and manage accordingly in case no payment adapter is present.
3 4
Application Management Software as defined by J2ME Java Application Management as introduced by MIDP1.0
18
JSR-229 Payment API

On MIDP devices, a dialog MUST be shown, listing all payment methods (i.e. provisioning information for that particular application is available and correct). The dialog MUST also indicate the date of the latest update as well as the update stamp (as defined by Pay-UpdateStamp in chapter 6.3) of that update. On IMP devices that do not have facilities for user interaction, there might be no payment options (e.g. only one payment method available). Another possibility is to implement a system based on profiles.
Pricing Updates
Price updates for some features must be performed by the payment module implementation. Initial price information is delivered with an application and updates must override these values. It is up to the implementation, in combination with the user, how often or when price updates should be conducted. In case of MIDP, it is required for the payment module implementation to show a graphical user interface element to request a price update. Such an item can be, for example, a menu item shown by the payment module. In case of IMP, this can be controlled via the security policy instead. Moreover, the date of the latest price (and thereby provisioning) update must be logged as described in the next section. Hiding the update and persistency mechanisms from the application has the advantage that information is handled consistently and in one place.
Application processed() Payment API Payment module process() <FeatureTitle> <This feature is decribed here in more detail>. Are you sure you want to buy this feature for EUR 0.50 using Premium Priced SMS? Last update date: <date> Last update stamp: <stamp> Yes No Other method Update
Retrieve up-to-date provisioning information
The figure above depicts a typical user interface workflow. The application initiates a payment request to the payment module by calling the process() method. It then interacts with the user by showing a dialog and asks the end user for payment confirmation. The user can choose first to update all prices or change the payment method before confirming or denying the payment request. After processing the payment requests (e.g. with the help of the correct payment adapter), the payment module then asynchronously delivers back to the application the state of the payment request using the processed() listener interface .
Transaction and Update History

The payment module is the core component of the client-side payment framework and is responsible for managing different payment adapters as well as necessary user interactions. Moreover, it must keep a history of the latest provisioning update as well as all missed transactions and a reasonable number of past transactions (refer to chapter A.2).
JSR-229 Payment API
19

Applications can retrieve the list of missed and past transactions initiated by them by accessing the payment module via the API defined in this specification. The end user should be able to retrieve the date and information about the latest provisioning update as well as the list of all missed and past transactions independently from the application they originated from. This functionality can be co-located with the configuration options of the payment module and the associated payment adapters. It will not be offered by the API defined in this specification as Java applications MUST NOT access the list of missed and past transactions that were issued by other applications. Although it is only for information purposes, it is highly recommended to offer this feature to end users. The API as defined by this JSR does not provide the means to implement such functionality and, furthermore, it should not be provided as a public Java API to avoid spyware applications retrieving all the users past transactions.
Error Display and Interaction

In MIDP, if the payment module encounters errors, it should display them to the user.
Dynamic Payment Adapter Management (Optional)

Optionally the payment module can support payment adapter plug-ins. Plug-ins are payment module implementations for payment service provider-dependent protocols and/or adapters. For example, an operator may provide payment module plug-ins to support proprietary operator charging interfaces. The payment module is then responsible for downloading, checking, installing and registering that particular plug-in. Payment plug-ins need to be signed by the device manufacturer (or any entity trusted by the device manufacturer).
3.7
Payment Adapter Responsibilities
Conducting Payment
A payment adapter is responsible for conducting payment transactions. Therefore, the implementation of such a payment adapter will focus on at least one particular payment method. All payment methods MUST involve an interaction between this adapter and servers in the network. Although some payment methods would not need to interact with a server (i.e. are smartcard based, like GeldKarte, Moneo, etc.), the payload, as defined by this Payment API, still has to be propagated through the network. As part of the payment transaction, the payment adapter is also responsible for forwarding a payload (if any is defined by the application), limited to 132 bytes5, to the application provider through the payment service provider.
Payment Authentication
Particular payment adapters involve non-repudiation mechanisms and may also need to interact with the user to authenticate the user to the payment system. The architecture designed in this specification clearly leaves this task to the implementation of the payment adapter. A credit-cardbased adapter may ask the user for the card number and expiration date every time it is used. It may also need an X.509 certificate or access to a smartcard to authenticate itself to the credit card operator in the network. All these are considerations that are specific to the adapter (plugin) and therefore are outside the scope of this document.
5
1 byte is 8 bits wide.
20
JSR-229 Payment API
Error Display and Interaction

In MIDP, if any payment adapter encounters errors, it should display them directly to the user.
JSR-229 Payment API
21
4 Package javax.microedition.payment
4.1 Overview
This package provides the payment application programming interface:
Summary Interfaces TransactionListener TransactionRecord Class TransactionModule Exceptions TransactionModuleException TransactionListenerException TransactionFeatureException TransactionPayloadException
This application programming interface has been designed to allow for an asynchronous handling of payment transactions. This is achieved by an emit/notify mechanism, respectively represented by the TransactionModule class and TransactionListener interface. It is also part of the design that no basic TransactionException class has been specified. This prevents an application developer from using a general catch(TransactionException) to (not) handle all payment-related exceptions. It is also part of the design that the developer must set a listener for transaction notifications. If this is omitted, a TransactionListenerException is thrown where appropriate.
22
JSR-229 Payment API
4.2
Design
The following UML diagram details the previously defined classes and interfaces and also shows the interaction between those classes:
4.3
Interface TransactionListener
4.3.1 Summary
Declaration public interface TransactionListener Description A listener type for receiving notifications of transaction records that have been generated by the payment module once a transaction has been processed. When the payment module (together with the corresponding payment adapter) has been able to process a payment transaction, the application is notified by having the command processed() method called on the TransactionListener that had been set using the setListener() method of the TransactionModule class.
Summary Method void processed(TransactionRecord record)
JSR-229 Payment API
23
4.3.2 Details
processed
public void processed(TransactionRecord record) Description: Called by the payment module (as interfaced by the TransactionModule) to indicate that a transaction-related event has occurred. The parameter record holds (by its getState() method) one of the values defined in the TransactionRecord interface: TransactionRecord.TRANSACTION_SUCCESSFUL, TransactionRecord.TRANSACTION_FAILED, TransactionRecord.TRANSACTION_REJECTED. The record is identifiable through the transaction ID that has been returned by the process() method call. Refer to chapter 4.4 for more information about the meaning of the TransactionRecord.TRANSACTION_* fields. Parameters: record - the original TransactionRecord containing the feature ID, the final state (TransactionRecord.TRANSACTION_* value) and timestamp. This record is created by the payment module.
4.4
Interface TransactionRecord
4.4.1 Summary
Declaration public interface TransactionRecord Description The payment module manages a list of past transactions for each application. Each of these transactions is atomically represented by an object implementing the TransactionRecord interface. Summary Fields static int TRANSACTION_SUCCESSFUL static int TRANSACTION_FAILED static int TRANSACTION_REJECTED Methods int getFeatureID() int getTransactionID() int getState() long getFinishedTimestamp() boolean wasMissed()
24
JSR-229 Payment API
4.4.2 Details
Field TRANSACTION_SUCCESSFUL
public static final int TRANSACTION_SUCCESSFUL = 0 Description: This value indicates that the payment module has been able to process the payment successfully. The application is thereby assured that the payment transaction of a given feature will be booked. The meaning of successfully processed is payment method dependent: most payment adapters will be able to guarantee a 100% reliable payment transaction (every actor gets the predicted part of a given transaction). Others, like Premium Priced SMS-based payment, will not be able to achieve this level of reliability due to the inherent limitations imposed by the design of the SMS infrastructure. However, the meaning of TRANSACTION_SUCCESSFUL is that the application MUST consider the payment as being done and should offer the paid feature to the user.
Field TRANSACTION_FAILED
public static final int TRANSACTION_FAILED = 1 Description: This value indicates that the payment module has not been able to finish the payment due to some error or problem. The application is thereby aware that the payment could not be fulfilled. This value also includes the case where the payment module could not find any payment adapter corresponding to the users selection to process this transaction. This case only covers technical errors which made the processing impossible but it does not cover rejection of a transaction request by the user: the latter is covered by the following field TRANSACTION_REJECTED.
Field TRANSACTION_REJECTED
public static final int TRANSACTION_REJECTED = 2 Description: This value indicates that the payment module has not been allowed by the user to process the payment transaction. The user has chosen the No option when asked by the payment module to confirm agreement to pay for a given feature. In the case of IMP, the payment module was preconfigured to deny transactions.
getFeatureID
int getFeatureID() Description: This method returns the feature ID of this particular transaction record.
JSR-229 Payment API
25

Returns: An integer value representing a feature identification number as defined in the provisioned resource file.
getTransactionID
int getTransactionID() Description: This method returns the transaction ID of this particular transaction record. It is the same identifier as returned before when the process() method was called. Returns: An integer value representing the unique identifier of this particular payment transaction. The identifier is platform-unique.
getState
int getState() Description: This method returns the final state of this particular transaction as managed by the payment module. The final state value is one of the following: TransactionRecord.TRANSACTION_SUCCESSFUL, TransactionRecord.TRANSACTION_FAILED, TransactionRecord.TRANSACTION_REJECTED. Returns: The final state of the transaction as one of the constants defined in this class.
getFinishedTimestamp
long getFinishedTimestamp() Description: This method returns the timestamp by which the transaction has been acknowledged by the payment module. It is usually the time when the final state (successful, failed or rejected) is set, i.e. shortly before the payment module will call the processed() method of the transaction listener. Returns: A value representing the number of milliseconds since January 1, 1970, 00:00:00 GMT at which time the transaction was acknowledged.
wasMissed 26
JSR-229 Payment API

boolean wasMissed() Description: This method returns a boolean value telling if the transaction has been successfully processed by the transaction listener in a former session. Returns: The boolean value.
4.5
Class TransactionModule
4.5.1 Summary
Declaration public class TransactionModule Description The TransactionModule class represents the communication interface between the application and the payment module. It has been designed to support asynchronous payment handling. Each call of process() has to return immediately. To convey the result of a payment transaction, an event is generated subsequently and the corresponding record is passed through the processed() method of the TransactionListeners interface to the registered listener. Summary Constructor TransactionModule(Object object) Methods void setListener(TransactionListener listener) int process(int featureID, String featureTitle, String featureDescription) int process(int featureID, String featureTitle, String featureDescription, byte[] payload) TransactionRecord[] getPastTransactions(int max) void deliverMissedTransactions()
4.5.2 Details
Constructor TransactionModule
public TransactionModule(Object object) throws TransactionModuleException
JSR-229 Payment API
27
Description: Constructs a TransactionModule object and verifies that the provisioning information for the payment module and that for the payment adapters (that are present on the device) have been provided correctly. Should there be found anything missing or incorrect, a TransactionModuleException is thrown. This also covers the case where multiple payment adapters are present and the provisioning information for one or more payment adapters cannot be verified. Please refer to section A.3 for complementary information. A java.lang.NullPointerException is thrown if the argument passed as Object is null. Parameter: object - Object referring to the application itself (MIDlet, IMlet, etc.). Throws: TransactionModuleException - The payment module thereby signals that it refused a connection from the TransactionModule class. Reasons may be, for instance, that the provisioning data is corrupt or incomplete, that there are too many applications linked to that payment module or that the user chooses not to continue because there are no matching provisioning information for any locally installed adapters (if any). The payment module should interact with the user to show the reason.
setListener
public void setListener(TransactionListener listener) Description: Set the listener for asynchronous events. The transaction event listener is removed if listener is set to null. Parameter: listener - if not null, this method sets the listener to which asynchronous payment events will be sent. If set to null, the current listener is removed.
process
public int process(int featureID, String featureTitle, String featureDescription) throws TransactionModuleException TransactionFeatureException TransactionListenerException Description:
28
JSR-229 Payment API

Initiate the payment transaction for the feature as identified by the parameter featureID. The parameter featureID MUST be a valid feature ID from the provisioning information, as defined in the JAR-Manifest. The method will return immediately after having tested and passed all values to the payment module. If the payment transaction could not be initiated (null or empty featureTitle or featureDescription, no more space available for new transaction records, payment module not ready, missing/bad provisioning, etc.), the method throws a TransactionModuleException exception with the corresponding error description. Otherwise, the payment module will notify the application through the registered listener whenever the payment has been fulfilled (or not) or if the user has rejected the request. Before calling process(), a transaction listener MUST be set for the TransactionModule object. This design ensures that the application will be notified about the payment process. If process is called without a listener being set, a TransactionListenerException is thrown. If any of the featureTitle or featureDescription parameters are set to null or are empty strings, a TransactionModuleException is thrown. By calling the process() method, the payment module MUST interact with the end user (if any interaction is feasible) by displaying the featureTitle, the featureDescription, the price of the feature, the date and time of the latest update, the date and time as defined by the Pay-Update-Stamp field in the JAR-Manifest, and by asking for confirmation. It may also ask the user to choose between different instances of payment adapters if several are available and are supported by the application developer (as described and provided in the resource file). It MUST be clear to the user that the prices shown are subject to changes and that the prices shown have been validated and made public on the date given by the Pay-Update-Stamp field. In the case of a deployment with a JSR-228 IMP 2.0 implementation, please refer to chapter 7.5. Parameter: featureID - the identifier of a given feature, as provided in the provisioning data. featureTitle - a very short description of the feature itself. It SHOULD only be a few words clearly defining the feature (example may be Level 1, Next Level, 3 Balls, etc). The text SHOULD be written in the language currently used by the platform, as described in the system property microedition.locale. If this parameter is not set (null or empty), a TransactionModuleException is thrown. featureDescription - a longer description of the feature. It SHOULD be considered that the text is meant to be shown/used on a device with few capabilities. As for featureTitle, the text SHOULD be written in the language currently used by the platform. If this parameter is not set (null or empty), a TransactionModuleException is thrown. Returns: A platform-wide unique positive identifier for this particular payment request. This identifier can either be ignored or be used by the application as a handle to identify the request in the implementation of the processed() listener whenever multiple requests are processed concurrently. Throws: TransactionModuleException - Refer to the TransactionModule constructor. TransactionFeatureException - The payment module signals that the feature ID that has been passed as parameter is not defined in the provisioning data. The application developer SHOULD correct this issue before the application is delivered to the end user.
JSR-229 Payment API
29

TransactionListenerException - The payment module could not find any registered TransactionListener, which MUST be set prior to payment processing.
process
public int process(int featureID, String featureTitle, String featureDescription, byte[] payload) throws TransactionModuleException TransactionFeatureException TransactionListenerException TransactionPayloadException Description: This method is similar to the previously defined method process(int featureID, String featureTitle, String featureDescription) but allows passing a payload to the payment module. This payload is forwarded to the payment adapter that will process the payment. The payment adapter MUST then forward that payload to the payment service provider. The payload can be used by the application developer to send application-specific information: a game developer might use it to send high scores or statistics, another application might use it to send a service activation code. There are no constraints on the format. The size is limited only by the size supported by payment adapters (e.g. SMS-based payments have a very limited payload size. See chapter 8). In any case, the process() method will throw a TransactionPayloadException exception if the payload is not accepted by the payment adapter for any reason (payload too large, payload format not accepted). Please refer to the description of the process(int featureID, featureTitle, String featureDescription) method. Parameters: featureID - the ID of a given feature, as provided in the provisioning data. featureTitle - a very short description of the feature itself. It SHOULD only be a few words clearly defining the feature (example can be Level 1, Next Level, 3 Balls, etc). The text SHOULD be written in the language currently used by the platform, as described in the system property microedition.locale. If this parameter is not set (null or empty), a TransactionModuleException is thrown. featureDescription - a longer description of the feature. It SHOULD be considered that the text is meant to be shown/used on a device with few capabilities. As for featureTitle, the text SHOULD be written in the language currently used by the platform. If this parameter is not set (null or empty), a TransactionModuleException is thrown. payload - a byte array containing data that has to be sent along with the transaction to the payment service provider. If this parameter is set to null, this method will behave exactly like process(int featureID, String featureTitle, String featureDescription). The size of the payload is limited to 132 bytes. The developer should be aware that some Unicode characters are 16-bit and are therefore stretching the original string (i.e. the length of the payload may increase). Returns: String
30
JSR-229 Payment API

A platform-wide unique positive identifier for this particular payment request. This identifier can either be ignored or be used by the application as a handle to identify that request in the implementation of the processed() listener whenever multiple requests are processed concurrently. Throws: TransactionModuleException - The payment module hereby signals that it refused a connection from the TransactionModule class. Refer to the TransactionModule constructor. TransactionFeatureException - The payment module signals that the feature ID that has been passed as parameter is not defined in the provisioning data. However, it is the application developers responsibility to align feature IDs used in the application with the feature IDs in the provisioning data. TransactionListenerException - The payment module could not find any registered TransactionListener which is mandatory for processing a payment. TransactionPayloadException - The payload exceeds the maximum 132 bytes and cannot be handled by the transaction module (or the corresponding payment adapter).
getPastTransactions
public TransactionRecord[] getPastTransactions(int max) Description: This method returns an array of TransactionRecord objects representing the list of transactions that have been processed and about which the application has been notified. This implies that, as soon as the payment module has successfully returned from a processed method call, the corresponding transaction is considered as being past. The number is limited by the parameter max. The list is ordered from the latest acknowledged transaction (array[0]) to the oldest one (array[length-1]). The list will contain only transactions that have been generated/requested by the current application. Parameter: max - specifies that the latest max number of transactions will be returned. If max is equal to Integer.MAX_VALUE then all transactions that have been stored by the transaction module will be returned. If max is equal to 0, then null is returned. Returns: An array of TransactionRecord or null if max is set to 0 or if no transactions have been initiated.
deliverMissedTransactions
public void deliverMissedTransactions() throws TransactionListenerException Description: This method requests the payment module to again generate all missed transactions on the processed() listener interface. Consequently, this method can only be called once the listener
JSR-229 Payment API
31

has been set using the setListener() method (if this is not the case, a TransactionListenerException is thrown and missed transactions remain pending for delivery). Two or more subsequent calls to this method will not duplicate missed transactions. A transaction is considered as being missed by the application if the payment module has been requested to process a payment but could not notify (i.e. either could not call the processed method or the processed method did not return) the application once it could have provided an answer: this situation might occur when the application is shut down or the device has crashed after an asynchronous process has been initialized by the application. This method gives the application the opportunity to handle pending transactions correctly. The list will contain only transactions that have been generated/requested by the current application. Please refer to chapter A.1 for more information about the handling of missed transactions. The order in which such transactions are delivered is from the latest acknowledged transaction to the oldest one. Throws: TransactionListenerException - The payment module could not find any registered TransactionListener which MUST be set prior to delivery of missed transactions.
4.6
Class TransactionModuleException
4.6.1 Summary
Declaration public class TransactionModuleException extends Exception Description TransactionModuleException is an exception thrown whenever an error related to the payment module occurred. This might be due to problems with the initialization or some other internal error of the payment module. Summary Constructors TransactionModuleException() TransactionModuleException(String message)
4.6.2 Details
Constructors TransactionModuleException
public TransactionModuleException() Description: Constructs a new exception with no details message. public TransactionModuleException(String message) Description:
32
JSR-229 Payment API

Constructs a new exception with the specified details message. Parameters: message Message details
4.7
Class TransactionListenerException
4.7.1 Summary
Declaration public class TransactionListenerException extends Exception Description TransactionListenerException is an exception thrown whenever the application tries to process a transaction but the payment module has not detected any listener (i.e. no listener has been set before using the setListener() method) Summary Methods TransactionListenerException() TransactionListenerException(String message)
4.7.2 Details
Constructors TransactionListenerException
public TransactionListenerException() Description: Constructs a new exception with no detail message. public TransactionListenerException(String message) Description: Constructs a new exception with the specified detail message. Parameters: message Message details
JSR-229 Payment API
33
4.8
Class TransactionFeatureException
4.8.1 Summary
Declaration public class TransactionFeatureException extends Exception Description TransactionFeatureException is an exception thrown whenever the application tries to process a transaction for a particular feature or to retrieve information about a given feature but the payment module was unable to locate the given feature ID from the resource file. Summary Methods TransactionFeatureException() TransactionFeatureException(String message)
4.8.2 Details
Constructors TransactionFeatureException
public TransactionFeatureException() Description: Constructs a new exception with no detail message. public TransactionFeatureException(String message) Description: Constructs a new exception with the specified detail message. Parameters: message Message details
4.9
Class TransactionPayloadException
4.9.1 Summary
Declaration public class TransactionPayloadException extends Exception Description
34
JSR-229 Payment API

TransactionPayloadException is an exception that is thrown whenever the payload that has been passed by the application to the transaction module exceeds the maximum 132 bytes. Summary Methods TransactionPayloadException() TransactionPayloadException(String message)
4.9.2 Details
Constructors TransactionPayloadException
public TransactionPayloadException() Description: Constructs a new exception with no detail message. public TransactionPayloadException(String message) Description: Constructs a new exception with the specified detail message. Parameters: message Message details
JSR-229 Payment API
35
4.10 Code Sample

4.10.1 Typical Payment
Sample source code using the Payment API
package com.benq.mobile.payment.test; import import import import import import javax.microedition.lcdui.*; javax.microedition.midlet.MIDlet; javax.microedition.payment.TransactionListener; javax.microedition.payment.TransactionModule; javax.microedition.payment.TransactionRecord; javax.microedition.payment.TransactionModuleException;
/** * Test MIDlet taken from spec sample. */ public class MyGame extends MIDlet implements TransactionListener, CommandListener { private private private private TransactionModule txModule; int alevel = 0; int nblevel = 0; int MAX_LEVEL = 3;
private Display display; private Command exit; public MyGame() { // Welcome to MyGame display = Display.getDisplay(this); Form formMain = new Form("MyGame"); exit = new Command("Exit", Command.EXIT, 1); formMain.addCommand(exit); formMain.setCommandListener(this); display.setCurrent(formMain); txModule = new TransactionModule(this); } catch(TransactionModuleException e) { /* The payment module thereby signalsthat it refused a * connection from the TransactionModule class. Reasons * may be, for instance, that the provisioning data is * corrupt or incomplete or that there are too many * applications linked to that payment module. The * payment module should interact with the user to show * the reason. */ // print error message: e.toString(); } catch(Exception e) { // print error message: e.toString(); } try { txModule.setListener(this); } catch(Exception e) { // print error message: e.toString(); } } public void startApp() { while (nblevel <= MAX_LEVEL) { // Payment required for level level try {
36
JSR-229 Payment API

try { txModule.process(alevel, "Next Level", "Gives access to the next level of this game."); synchronized(this) { try { wait(); // wait until callback is called } catch (InterruptedException ie) { // Handle exception } } } catch (Exception e) { // Handle exception } // Start level level Form formLevel = new Form("Level " + nblevel); display.setCurrent(formLevel); try { Thread.sleep(5000); } catch (InterruptedException e1) { // print error message: el.getMessage() } // Level finished nblevel++; } } public void processed(TransactionRecord record) { switch(record.getState()) { case TransactionRecord.TRANSACTION_SUCCESSFUL: // Payment transaction successful break; case TransactionRecord.TRANSACTION_REJECTED: // Why? You have to pay to play! break; case TransactionRecord.TRANSACTION_FAILED: default: // Technical problem - try again! break; } synchronized(this) { notify(); // notify waiting thread } } protected void pauseApp() {} protected void destroyApp(boolean arg0) {} public void commandAction(Command command, Displayable displayable) { if (command == exit) { destroyApp(true); notifyDestroyed(); } } } // End of class definition
This code is provided here as an example of the usage of the Payment API, as defined by this specification. Sample JAD and JAR-Manifest files that match this code sample can be found in chapter 6.5.1.
JSR-229 Payment API
37
5 System Functions
5.1 Overview
This chapter defines a few extensions to the underlying platform.
5.2
System Properties
The PAPI defines the following additional property values that MUST be made available to the application using java.lang.System.getProperty: System Property microedition.payment.version Description The version of the Payment API implemented in the device. The version MUST match the version major and minor of the specification that was used to implement it. If the implementation matches this specification, then this system property MUST return 1.1. The format is <major>.<minor> and follows the same rules defined for Pay-Version (refer page 39 and page 42).
38
JSR-229 Payment API
6 Provisioning
6.1 Overview
Provisioning data is delivered as part of a JAR-Manifest resource file. However, some paymentrelated information shall be delivered as part of the JAD resource file and allows a user to have some basic information before downloading a given application. This minimum information includes that the given application is payment-enabled, and lists which payment adapters are expected so it can run. At least one of them should be supported by the platform: a particular implementation might allow the downloading of missing payment adapters after the application has been installed or started. However, the user should be aware that the usage of this particular application is dependent on the availability of those payment adapters. With respect to the MIDP specification, the provisioning data provided in the JAD and the JARManifest (i.e. the features included) is global to the entire MIDlet-suite. Modification of the MIDlet-suite implies redefinition of the features and therefore of the behavior of a given MIDlet. As stated in chapter 7, this specification has been defined to take advantage of security features and control mechanisms as provided by MIDP2.0. In order to protect the provisioning information, the MIDlet (and thereby the JAR-Manifest) MUST be protected through the signature of the JAR application by an authority recognized by the platform certificate authority. However, in order to facilitate the development of applications, a debug mode has been defined in which the signature and certification are not required. This debug mode is taken into consideration only on development platforms such as the Java Wireless Toolkit, emulators, simulators and similar.
6.2
JAD Resource
? M* Attribute description The version number of the JAR-Manifest fields used to configure the payment module. The format is <major>.<minor>. Current version is 1.1 and defines the JAD and JAR-Manifest payment-specific field format, interdependencies and behavior of the payment module. The list of registered payment adapters (<RegAdapter>) supported by the application provider. The list is commaseparated and MUST contain only registered adapters (see adapter namespace in chapter 8.2). At least one of these adapters should be supported by the payment module. There MUST NOT be duplicates of adapters for this property.
Attribute name Pay-Version
Pay-Adapters
M*
Pay-Debug-DemoMode
A boolean attribute allowing the developer to fake the behavior of a payment module
JSR-229 Payment API
39

running normally. All payment-related functionalities will always succeed. If set to yes, the demo mode is activated and no real payments are performed, but the payment module will behave as if successful processing of payments has taken place. If set to no, the demo mode is deactivated. This is the default value of this property field. This property will affect the demo mode of the payment module independently of the value of other Pay-Debug-* properties. This means that if PayDebug-DemoMode is set to no, none of the other Pay-Debug-* will be activated. This also means that, in order to use other Pay-Debug-*, this property needs to be set to yes. Pay-Debug-FailInitialize O This debug option causes a TransactionModuleException to be thrown in the constructor of the TransactionModule class. This debug option allows developers to simulate the behavior of a payment module not being able to initialize. The consequence is that the application will not be able to create a TransactionModule object because the constructor will always return an exception. Value is either yes or no. yes means that the payment module will behave erroneously. If this option is not defined, the default value is no. If Pay-Debug-DemoMode is set to no, this feature will be ignored. Pay-Debug-FailIO O This debug option allows developers to simulate the behavior of a payment adapter not being able to send the payment request. The payment module will always return records with a final state set to TransactionRecord.TRANSACTIO N_FAILED. All other payment-related interactions will always succeed. Value is either yes or no. yes means that the payment module will behave erroneously. If this option is not defined, the default value is no. If Pay-Debug-DemoMode is set to no,
40
JSR-229 Payment API

this feature will be ignored. Pay-DebugMissedTransactions O This debug option supports developers in testing the portion of code responsible for handling missed transactions. All other payment-related interactions will always succeed. If this property is set, the method deliverMissedTransactions will ignore any other missed transactions that might exist. Format is <n>: where n is the positive number of artificially generated missed transactions, the payment module will generate when the application is started. If Pay-Debug-DemoMode is set to no, this feature will be ignored. Pay-Debug-RandomTests O Randomly choose either to succeed or to generate one of the previously defined debug error simulations: Pay-DebugFailInitialize and Pay-DebugFailIO. Value is either yes or no. If this option is not defined, the default value is no. If Pay-Debug-DemoMode is set to no, this feature will be ignored. Pay-Debug-AutoRequestMode O This debug option supports developers and JSR229-Implementation developers in turning off UI-based confirmation requests. Value is either accept or reject. If this option is not defined, the user will be asked. The payment module and adapters SHOULD behave according to the value of the property as if the user did accept or reject the payment request. If Pay-Debug-DemoMode is set to no, this feature will be ignored. Pay-Debug-NoAdapter O This debug option supports developers in testing the API behaviour when no payment adapter is present (or registered to the payment module). Value is either yes or no. If this option is not defined, the default value is no. If Pay-Debug-DemoMode is set to no,
JSR-229 Payment API
41

this feature will be ignored. [M]: Mandatory, [O]: Optional, [M*]: Mandatory if any of the other M or M* marked fields is present. In other words, properties marked with [M*] should be either all present or all absent. All Pay-Debug-* properties are relevant only on development platforms (Java Wireless Toolkit, Reference Implementation, Emulators, Simulators, etc.). On a real/commercial device, these options MUST be ignored by the payment module both when loaded directly or through any provisioning update. If Pay-Debug-DemoMode is set, the payment module will work in demo mode in order to support the application developer in testing his application without having to spend money. In this demo mode, the payment module does not forward any payment request to payment adapters and behaves as if everything completed successfully (best case): no exceptions besides those related to parameters (payload size, null-pointer, etc.). Depending on the activated Pay-Debug-* feature, the payment module will generate the corresponding error. Moreover, Pay-Debug-* have higher priorities than the Pay-Debug-RandomTests option. If Pay-Debug-DemoMode is not set (or set to no), the other Pay-Debug-* properties will be ignored. The consistency of the provisioning information (JAD and JAR-Manifest) must conform to this specification in both cases where Pay-Debug-DemoMode is set and not set. As stated in the legend of the previous table, the fields marked with [M*] are all mandatory if any [M*] field is present. Otherwise all fields must be omitted.
6.3
JAR-Manifest Resource
? M Attribute description The version number of the JAR-Manifest fields used to configure the payment module. The format is major.minor. Current version is 1.1. See description of the same field in the JAD file. If the version is not supported by the implemented payment module, then all payment-relevant fields MUST be discarded.
Attribute name Pay-Version
Pay-Update-Stamp
This field MUST contain the past on which the current information was generated. defines the date at which information starts to be valid.
date in the provisioning It thereby the current
This one-line field contains a date and timeof-day and optionally the timezone field. The format MUST follow the primary
42
JSR-229 Payment API

standard notation as defined by ISO 8601:20006. If no timezone is specified, then Universal Time (UTC) is assumed:
YYYY-MM-DD HH:MM[:SS][[+|-] HH[:MM]]
This (and always at least the latest) stamp, along with the date and time of the latest update, MUST be stored by the payment module. On MIDP, both dates (stamp and date of latest update) MUST be shown to the user with other payment transaction information such as featureDescription, featureTitle and price of the feature, when displaying payment requests. It should be clear to the user that the prices shown are subject to changes and that the price shown has been validated and made public on the date given by this field. Pay-Update-URL M A URL pointing to the latest version of the provisioning information. Only Pay-* and signature fields of the retrieved provisioning data are taken into consideration. Other fields MUST be ignored. The format of the content MUST be compliant with this JARManifest description and allows the payment module to update payment-related information. Such retrieved information will be parsed by the payment module and, if verified to be compliant, will replace the previous information stored. If the download did not succeed or the retrieved provisioning is not compliant (see also chapter 6.4), an error message MUST be presented to the user, all of the retrieved provisioning information MUST be ignored and the payment module MUST use the previous provisioning. In any case, the user MUST confirm the information shown (old or new) before the payment is processed by the selected adapter. Format is <application-providerurl>. It includes the leading scheme according to RFC 2396. The scheme MUST be supported by the underlying platform. The AMS MUST verify that it supports the specified scheme before launching the application. More information about updates can be found in chapter A.4. The returned MIME-type MUST be: text/vnd.sun.pay.provision. If it is not, the
6
The specification can be ordered at http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780
JSR-229 Payment API
43

user SHOULD be informed and the retrieved provisioning MUST be ignored. The downloaded file SHOULD have a .jpp extension. Refer to chapter 6.4 for more information about provisioning update. Pay-Cache O This field specifies the cache policy of the Pay-<ProviderTitle>-Tag-<m> fields. Format is Date>]. [yes|no|<Expiration-
If the value is no, then the payment module MUST initiate an update of the provisioning data, at the latest before payment is conducted, the first time the corresponding payment adapter is used (i.e. only after the process method is called). The provisioning update MUST contain all price information needed and may still contain this field set to no. In this case, all Pay-<ProviderTitle>-Tag-<m> are only valid for the current runtime session of that application and MUST be discarded as soon as the application is stopped. If the value is yes, then the payment module uses the value specified in this description file (if any) or retrieves them once and leaves it up to the end user to update the payment information in the future. If the value is <Expiration-Date>, the payment module MUST compare the current date with the <ExpirationDate>. If the expiration date is in the past, the payment module MUST behave as if Pay-Cache was set to no, otherwise MUST behave as if Pay-Cache was set to yes. The format of <ExpirationDate> is the same as for Pay-UpdateStamp. This field is optional and the default value is yes. Pay-Providers M A list of names identifying payment providers supported by the application provider, as defined within the Pay<ProviderTitle>-* fields. Each name corresponds to an instance of a particular adapter. These titles SHOULD be meaningful names as these are the names to be presented to the end user at adapter instance selection time. They also have to be short enough as they will be shown on small
44
JSR-229 Payment API

displays (as specified by MIDP2.0). The list is comma-separated. Moreover, each of these titles MUST respect MIDP2.0s BNF specification for attribute names (attrname): any Unicode except CTLs or separators. (page 437 MIDP2.0) <ProviderTitle>s and <RegAdapter>s are different in the way that <RegAdapter>s are predefined, and are registered namespaces specified by this specification; whereas <ProviderTitle>s are defined by the application provider. Semantically, <ProviderTitle>s are instances of <RegAdapter>s. There MUST NOT be duplicates of <ProviderTitle>s for this property. Pay-Feature-<n> M Describes the price tag to which the feature identified by the positive integer <n> is linked. These <n> numbers MUST start from 0 with no gaps in between. The format is: <m>. <m> refers to the price tags defined for each instance of payment adapters (see Pay<ProviderTitle>-tag-<m>. <m> is a positive integer <n>. These numbers MUST start from 0 with no gaps in between. The number of features is limited by the maximum number of features supported by each payment adapter. Please refer to chapter 8. Pay-<ProviderTitle>-Info M This field defines the currency in which prices have to be shown as well as other adapter-specific configuration parameters. Format is: <RegAdapter>, <ISO4217CurrencyCode>, <PaymentSpecificInformation> <RegAdapter> MUST only be one of the predefined named adapters (see adapters namespace in chapter 8.2). There MUST be exactly one of these fields in each <ProviderTitle> definition block. The format of <PaymentSpecificInformation> is defined in the specification of each adapter. Pay-<ProviderTitle>-Tag-<m> O The format is <Price>[, PaymentSpecificPriceInformation>]. <
<Price> is a double (using point . as a decimal separator; thousand separators not
JSR-229 Payment API
45

allowed). It represents the price of a particular feature. There should be as many tags as there are different <m> values defined in all Pay-Feature-<n>. There should also be as many Pay-*-tag-* for each Pay-<ProviderTitle> section. These fields are optional. If not supplied, the payment module MUST retrieve the missing information described here by using the Pay-Update-URL field value. [M]: Mandatory, [O]: Optional The payment module is responsible for parsing the provisioned information in the JAR-Manifest and rejecting incomplete or non-compliant provisioning. An error message SHOULD be presented to the user.
46
JSR-229 Payment API
6.4
Update
Provisioning information can be fully updated. Please refer to chapter A.4 for more information about update policies. The provisioning information that is loaded from the URL specified in the Pay-Update-URL field defined in the JAR-Manifest MUST respect the following: If downloaded and if MIME-types and extensions are relevant in the download protocol, the MIME-type MUST be text/vnd.sun.pay.provision and the file extension SHOULD be .jpp. It contains all fields marked as mandatory in the JAR-Manifest file (as defined in chapter 6.3). All fields defined as optional in the JAR-Manifest (as defined in chapter 6.3) are also optional. It is correctly signed (i.e. have Pay-Signature-RSA-SHA1) as defined below. It contains all of the following mandatory fields:
Attribute name Pay-Certificate-<n>-<m>
? M
Attribute description Base64 encoding of a certificate without line breaks <n>: a number equal to 1 for first certification path in the descriptor or 1 greater than the previous number for additional certification paths. This defines the sequence in which the certificates are tested to see if the corresponding root certificate is on the device. <m>: a number equal to 1 for the signers certificate in a certification path or 1 greater than the previous number for any subsequent intermediate certificates.
Pay-Signature-RSA-SHA1
Base64 encoding without line breaks of the signature of this provisioning: i.e. of all other fields provided in this provisioning. The order in which all other properties are processed is the same as the order in which those lines appear in the provisioning information stream. In this process, empty lines, Pay-Certificate-<n>-<m> and Pay-Certificate-* and PaySignature-* are ignored.
[M]: Mandatory, [O]: Optional
JSR-229 Payment API
47

The signature mechanism, algorithms and certificate paths used are those already in use by the underlying MIDP or IMP platforms to verify a signed JAR. As such, all rules defined in Mobile Information Device Profile 2.0 (JSR-118) and in Information Module Profile - Next Generation (JSR-228) are to be followed in respect to the modification described in this chapter. As such, the certification and verification processes follow all standards referred to in chapter 4 Trusted MIDlet Suites using X.509 PKI of JSR-118 and the corresponding chapter 6 Trusted IMlet Suites using X.509 PKI of JSR-228. Please refer to the description of the fields MIDlet-Jar-RSASHA1 and MIDlet-Certificate-<n>-<m> in those specifications for the handling of the fields defined above, as well as for the rules on certificate expiration and/or revocation. Once the signature has been approved and the Pay-Version accepted, the provisioning information can be taken into account by the payment module. Only Pay-* are read and PayDebug-* (if any present) are to be ignored.
48
JSR-229 Payment API
6.5
Examples
6.5.1 Development JAD and JAR-Manifest

The following JAD and JAR-Manifest files may be used as a base for the development of payment-enabled applications: JAD:
[] Pay-Version: 1.1 Pay-Adapters: PPSMS Pay-Debug-DemoMode: yes Pay-Debug-FailInitialize: no Pay-Debug-FailIO: no Pay-Debug-MissedTransactions: no Pay-Debug-RandomTests: no Pay-Debug-AutoRequestMode: accept
JAR-Manifest:
[] Pay-Version: 1.1 Pay-Update-Stamp: 2004-11-15 02:00+01:00 Pay-Update-URL: http://<update-site>/thisgame.manifest.jpp Pay-Providers: Test Pay-Feature-0: 0 Pay-Test-Info: PPSMS, EUR, 001, 01 Pay-Test-Tag-0: 2.40, 4321, 0x123456789abcdef0, 1
6.5.2 JAD and JAR-Manifest

For example, an application whose provider supports SMS and a proprietary (X-TEST) payment adapter would provide the following JAD and JAR-Manifest files: JAD:
[] Pay-Version: 1.1 Pay-Adapters: PPSMS, X-TEST MIDlet-Permissions: javax.microedition.payment.process.jpp MIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate> MIDlet-Jar-RSA-SHA1: <base64 encoded Jar signature>
JAR-Manifest:
[] Pay-Version: 1.1 Pay-Update-Stamp: 2004-11-15 02:00+01:00 Pay-Providers: SMS1, Test1Card, Test2Card Pay-Update-URL: http://<update-site>/thisgame.manifest.jpp Pay-Cache: no
JSR-229 Payment API
49

Pay-Feature-0: 0 Pay-Feature-1: 0 Pay-Feature-2: 1 Pay-SMS1-Info: PPSMS, EUR, 928, 99 Pay-SMS1-Tag-0: 1.20, 9990000, 0x0cba98765400 Pay-SMS1-Tag-1: 2.50, 9990000, 0x0cba98765401, 2 Pay-Test1Card-Info: X-TEST7, EUR, c4d21, soap://<soap-site-1>/ Pay-Test1Card-Tag-0: 1.21 Pay-Test1Card-Tag-1: 2.46 Pay-Test2Card-Info: X-TEST , USD, 8DiU, soap://<soap-site-2>/jsr229
7
6.5.3 Update Example

MIME-type: text/vnd.sun.pay.provision
[] Pay-Version: 1.1 Pay-Update-Stamp: 2004-11-16 03:30+01:00 Pay-Providers: SMS1, Test1Card, Test2Card Pay-Update-URL: http://<update-site>/thisgame.manifest.jpp Pay-Cache: no Pay-Feature-0: 0 Pay-Feature-1: 0 Pay-Feature-2: 1 Pay-SMS1-Info: PPSMS, EUR, 928, 99 Pay-SMS1-Tag-0: 1.30, 9990000, 0x0cba98765400 Pay-SMS1-Tag-1: 2.80, 9990000, 0x0cba98765401, 2 Pay-Test1Card-Info: X-TEST, EUR, c4d21, soap://<soap-site-1>/ Pay-Test1Card-Tag-0: 1.21 Pay-Test1Card-Tag-1: 2.46 Pay-Test2Card-Info: X-TEST, USD, 8DiU, soap:// <soap-site-2>/jsr229 Pay-Test1Card-Tag-0: 1.22 Pay-Test1Card-Tag-1: 2.48 Pay-Certificate-<n>-<m>: <base64 encoded encoding of a certificate> Pay-Signature-RSA-SHA1: <base64 encoded signature of all other lines>
Here, X-TEST represents a fictitious payment adapter that has not been specified and is used only for the purpose of the examples.
50
JSR-229 Payment API
7 Security
Security in the context of mobile payment as defined in this JSR is about securing the provisioning information, the application and its state against modification (except, of course, by developers and providers themselves). It is also about guaranteeing that the terminal owner acknowledges all payment transactions and not about hiding any content. The JSR-229 has been defined and designed to take advantage of security features and control mechanisms as provided by MIDP2.0.
7.1
[REQ-1] [REQ-2] [REQ-3] [REQ-4] [REQ-5] [REQ-6]
Requirements
Tamper resistance of payment-enabled provisioning information Protecting the terminal owner against over-payment Tamper resistance of payment-enabled state information Tamper resistance of payment-enabled application code Protecting the payment service provider against fraudulent access Protecting the application provider against fraudulent access
A more exhaustive enumeration of the security requirements for JSR-229 is:
The following chapters address these requirements.
7.2
Applications
The following permission is defined for the JSR-229 payment functionality: Permission name: javax.microedition.payment.process
To request a payment transaction, a MIDlet (or IMlet) requires this permission to access the implementation of TransactionModule.process(). If the permission is not granted, then this method MUST throw a SecurityException. Otherwise, the implementation must display the payment method selection and transaction confirmation dialog. The following policies for the different domains are to be applied on the different platforms: On GUI-enabled platforms (eg. MIDP): o o o o Untrusted: Trusted 3rd party: Manufacturer: Operator: Disabled Allowed Allowed Allowed
JSR-229 Payment API
51
On non-GUI platforms (eg. IMP): o o o o Untrusted: Trusted 3rd party: Manufacturer: Operator: Disabled Allowed Allowed Allowed
This permission is used to protect the implementation from untrusted applications. It cannot be overruled by any means, in particular not by the user.
7.3
Provisioning Data
The provisioning information is provided through the following channels, all of which need to be secured as they contain sensitive data for the payment module: the JAD file, the JAR-Manifest file included in the applications JAR file, through the update mechanism of the entire JAR-Manifest file.
All cases are addressed by content signing mechanisms. For the last case, the content may be retrieved by any means and the payment module will use the signature verification mechanism to verify the integrity of the downloaded update. The MIDlet must therefore be protected through the signature of the JAR application by an authority recognized by the platform certificate authority. The signature and certificates MUST be present in the application descriptor (JAD) as attributes, as defined by the MIDP2.0 and IMP2.0 security frameworks. MIDP2.0 and IMP2.0 define rules on how to handle properties that are in both JAD and JARManifest: if the MIDlet suite is not trusted the value from the descriptor file will override the value from the manifest file. If the MIDlet suite is trusted then the values in the application descriptor MUST be identical to the corresponding attribute values in the JAR-Manifest. However, payment-related fields defined in chapter 6.3 MUST be read from the JAR-Manifest and MUST NOT be overloaded by those from JAD in case values are different. This ensures that provisioning data is protected against any external modifications, as tampering with paymentrelated properties will be detected by trusted applications and have no effect on untrusted applications that are not allowed to use payment functionalities.
7.4
Storage
There is an issue that arises particularly in the context of applications using this payment JSR. Such applications need to store their state internally, including the payment history for paid features (e.g. how many balls remain to play before asking again for a payment?). Such state information could be stored using the RMS API. However, experience shows that many manufacturers are fully compliant with the RMS specification but leave the records on a file in the file system (FAT or alike). These record files are then accessible by anyone using a native file browser and might be manipulated or copied onto another device. This makes it possible to misuse the payment functionality. Although it is already part of the MIDP (respectively IMP) specification that RMS records are bounded to the MIDlet-suite (respectively IMlet-suite) that generated those records and thereby cannot be accessed by any other MIDlet-suite (respectively IMlet-suite), the original specification leaves it open to the implementer what happens to those records on the native platform (if any).
52
JSR-229 Payment API

In order to support JSR-229 application developers, it is recommended that Payment API JSR implementer to implement the RMS package (javax.microedition.rms) in such a way that external (downloaded and resident, Java and non-Java) applications are not able to retrieve or insert data from or to that storage. Nevertheless, it is still the application developers decision to make the tradeoff between the security and the complexity needed to store the applications internal state. One may also choose to store this state information using alternative storage APIs, such as that provided by the optional FileConnection API of JSR-75 PDA Optional Packages for the J2ME Platform or by the optional package JSR-177 Security and Trust Services API (SATSA). JSR-177 provides more complex mechanisms to store information securely (i.e. RMS with encryption and Security Element). (U)SIM8 could alternatively be used to store such state information to allow plasticroaming, i.e. allowing thereby a user to switch his handset while continuing using his application credits. In this case, JSR-177 is also the API to consider.
7.5
Payment Module
Continue Confirmation Dialog In case where there is no matching between provisioning information and locally installed payment adapters, the payment module must display a warning-dialog for the user to confirm whether to continue or not. User Dialog In order to prevent applications from generating payments undetected, the payment module must display a payment method selection and transaction confirmation dialog. Authentication Another question that arises is user authentication to the payment module. However, this issue is left to the implementer of the payment module. Some platforms, such as mobile phones, are already designed to be used as personalized devices and would not need any additional user authentication. Other platforms may have to introduce an intermediate step where the user authenticates to the payment module before being able to use any payment adapters.
7.6
Non-GUI Platforms
Throughout this specification, it is a requirement for a terminal owner to acknowledge all payment transactions. However, the platform may not necessarily have a GUI system through which an end user (if there is one) could possibly interact and thereby acknowledge a given transaction. This is the case for platforms supporting IMP (Information Module Profile). In order to use the process() method of the TransactionModule class, the application MUST be granted a permission to perform the requested transactions. This mechanism is based on a policy mechanism enforced in the platform implementation.
Universal Subscriber Identity Module
JSR-229 Payment API
53
7.7
Summary
Here follows a summary of the coverage of the security mechanisms mapped onto the requirements listed at the beginning of this chapter.
Tamper resistance of pament-enabled provisioning information [REQ-1]: Only signed applications are allowed to use JSR-229. Modification of the provisioning information which is located in JAR/Manifest would modify the JAD-signature and hence be detected by the payment module. The application is then not allowed to run. Protecting the terminal owner against over-payment [REQ-2]: a. Only signed applications are allowed to use the JSR-229 API: Provisioning (in particular prices and update links) have been verified and are therefore under control of the payment module, On GUI-enabled devices, it is controlled by having the end user confirm every payment transaction through a user dialog. If the platform does not possess a GUI, please refer to chapter 7.6, Authentication of the end user is left to the implementer, neverthess platform targeted by JSR-229 are already designed to be used as personalized devices.
b.
c.
Tamper resistance of Payment-enabled state information [REQ-3]: Different applications may have different requirements for storing their current state. Therefore, it is the application developers responsibility to choose a storage facilities corresponding to his needs: JSR-75, JSR-177 or the RMS-API may be used for this purposes. Tamper resistance of Payment-enabled application code [REQ-4]: It is outside the scope of this specification and is a general Java MIDP issue. Protecting the Payment Service Provider against fraudulent access [REQ-5]: This specification does not specify any particular payment mechanism. This requirement is an integral part of the specification of every single payment method, which specifies payment adapters and payment service servers. Protecting the Application Provider against fraudulent access [REQ-6]: In the role of a service provider (network-side application logic), application providers are being notified about a successful payment transaction in order to give access to a given content or service. This requirement is out of scope of this specification and is part of the application logic and must be specified between the different actors: payment service provider, application provider and possibly the application developer.
54
JSR-229 Payment API
8 Adapters
8.1 Overview
This chapter defines general rules about payment adapters including adapter naming rules that must be followed by any new adapters.
8.2
PPSMS
Registered Adapters Namespaces

Premium Priced SMS: payment model where the value of a transaction is determined by the premium priced number to which an SMS is sent and/or by the content of the body of that SMS. Specification of this adapter is located in Appendix C.1.
In order to avoid namespace fragmentation, the following namespace is reserved:
Registered names MUST NOT begin with X- (capital X) as they are reserved for experimental adapters.
8.3
Standardizing New Adapters
Proposal for new payment adapters may be submitted to the maintenance lead during the maintenance phase. These submissions will be reviewed and finalized together with the PAPI-EG, the submitting part and any other concerned parties. The new adapter will then be integrated into this specification. After the maintenance phase is closed, new payment adapters may only be integrated in this specification as part of a new JSR Proposal defining thereby a new release of this specification.
8.4
Experimental Adapters Naming Convention
All adapters not explicitly defined or registered in this specification are considered to be experimental. The namespace for experimental adapters MUST be preceded by X- (capital X). As soon as such an adapter is officially registered, both namespaces (with and without the leading X-) are reserved.
JSR-229 Payment API
55
9 Technology Compatibility Kit (TCK)

Due to the particularity of this specification in respect to security, the following concerns MUST be respected: An implementation of this JSR is considered to have successfully passed TCK testing only if all tests have passed without having any Pay-Debug-* option activated. The TCK has been designed to ensure that this requirement is respected on production implementations. However, implementations under development are treated differently (i.e. all tests but Pay-Debug-* test will pass).
Please refer also to the documentation provided together with the delivered TCK.
56
JSR-229 Payment API
10
MCC
Glossary
Mobile Country Code: every mobile (GSM) operator is given a unique identifier pair (MCC, MNC). The MCC is a 3-digit code identifying the country in which this mobile (GSM) operator is registered. Mobile Network Code: every mobile (GSM) operator is given a unique identifier pair (MCC, MNC). The MNC is a 2 or 3-digit code identifying the network of a given country in which this mobile (GSM) operator is registered. Mobile Originated message. An SMS or MMS message that was originated on a mobile phone. Mobile Terminated. An SMS or MMS message that was terminated (sent to) a mobile phone. The message may have originated from another mobile phone or from a server, PC or other fixed device. Record Management Store, as defined for J2ME application to store and retrieve application-specific data. Short Message Service. Defined by the GSM standard; allows end users to exchange short messages. SMS are also used to push and send system information such as WAP provisioning or, in this context, payment transactions.
MNC
MO, SMS-MO MT, SMS-MT
RMS SMS
JSR-229 Payment API
57
Appendix A. Implementation Notes

This chapter addresses some possible implementation issues.
A.1 How To Handle Missed Transactions

If the application was stopped, has crashed or has been interrupted by the user after a process() call, the application will not be able to receive the corresponding notification from the payment module. After the payment transaction has been accepted and acknowledged by the payment adapter, the payment module calls the processed() method of the registered listener. However, if the application is not available anymore, no listener is registered. In order to prevent information loss, a protection mechanism is supported by this Payment API: A transaction for which a payment adapter has returned an answer is marked as being missed (as delivered by the deliverMissedTransactions() trigger method) until the call to the processed() method has been completed successfully. As soon as it has been notified, that transaction will be available in the list of past TransactionRecords as delivered by the getPastTransactions() method. After a crash, an application can recover and retrieve missed transactions by calling the deliverMissedTransactions() at startup time soon after having set the transaction listener. The method triggers the payment module to deliver all transactions that could not (and otherwise will not) be notified to the application. Missed transactions are then delivered through the processed() listener.
A.2 Management of Past and Missed Transactions

The implementation of the payment module, which is responsible for managing active, past and missed transactions, must respect the following rules: All missed transactions MUST be stored. If there is no more space left, the payment module MUST throw a TransactionModuleException whenever the process() method is called. The payment module SHOULD hold a reasonable number of past transactions. Past transactions that failed SHOULD contain a human readable text description of the reason of the failure. This text description can then been shown when listed to the user (as explained in section 3.6 Transaction and Update History, page 19). The payment module MUST relate missed transactions to the running application (or MIDlet-suite). It will therefore have to implement a method to identify a given MIDletsuite. The AMS3/JAM MUST remove all missed transactions and SHOULD keep passed transactions when the MIDlet-suite that generated them is uninstalled from the platform. If missed transactions are still pending, the user MUST be notified about them and asked for confirmation before deletion. The storage facility for past and missed transaction records must be secure, i.e. no other application should be able to read transactions that were not generated by the given application, and transaction records should not be accessible by other platform-native
58
JSR-229 Payment API

applications (if any). The existence of such storage is implementation-dependent and may use the solution used for the RMS, as explained in chapter 7.4.
A.3 Transaction Module Initialization

When the TransactionModule constructor is called for the first time from an application, it will check that the payment module is available and ready: it will verify that it has all necessary provisioning data and that every payment adapter has been provisioned correctly by the resource file. If this is not the case, exceptions and error messages have to be presented to the user, as described in chapter 4.5. There is a particular case if the intersection is empty between the provisioned adapters and the locally installed adapters (also the case when no adapters are locally available), i.e. the user will have no means by which he will be able to submit a payment request using that application: On MIDP devices, the TransactionModule MUST warn the user about this situation and ask for confirmation whether to continue running this application. The application MUST then run normally if the user accepts to continue and the constructor MUST throw a TransactionModuleException if the user chooses not to continue. On IMP devices, the TransactionModule MUST return a TransactionModuleException.
This confirmation-dialog can be bypassed by the Pay-Debug-AutoRequestMode property. As defined in section 6.2, the dialog is skipped and the TransactionModule (constructor) should behave according to the value of the property as if the user did accept of reject the confirmation.
A.4 Provisioning Update

There are two cases where the provisioning update is required: The user chooses to update the provisioning information directly from a system menu. The application is not fully provisioned when the application is started: if Pay-Cache is set to no or set to a date that has expired, or if the Pay-<ProviderTitle>Tag-* are not all present.
The current specification offers to update the complete JAR-Manifest provisioning. This is specified in chapter 6.4. In order to retrieve a complete, up-to-date JAR-Manifest, the implementation must download the content from the link specified in the Pay-Update-URL field. If it should happen that Pay-<ProviderTitle>-Tag-* tags are missing, an update is initialized to retrieve such provisioning information. If the update process fails (e.g. due to connection problems) or if the retrieved update does not provide the required information, i.e. the update still does not contain all required Pay-<ProviderTitle>-Tag-*, a TransactionModule-Exception MUST be thrown either in the constructor of the TransactionModule class or latest when its process() method is called. The update mechanism allows the following policies to be implemented: User Initiated Update: The user basically always has the right to initiate an update, including in any of the following cases. Always Update: Implemented by setting Pay-Cache:no in the JAR-Manifest and Pay-Cache:no in every provisioning update.
JSR-229 Payment API
59

Update Only Once: Implemented by setting Pay-Cache:no in the JAR-Manifest and Pay-Cache:yes in every provisioning update. Never Update: Implemented by providing all payment-related properties with values and not setting Pay-Cache (or setting it to yes) in the JAR-Manifest. In the case of a userinitiated update, the provisioning update must have Pay-Cache:yes. Update after Expiration Date: Implemented by providing an expiration date to the PayCache property. In case of a user-initiated update, the provisioning update may contain Pay-Cache set to any value: yes, no, <Expiration-Date>.
A.5 AMS/JAMs tasks

The payment-specific information provided in the JAD file should be used by a platform-specific implementation of an AMS (or Java application manager) to decide which action to take. This includes preventing the download or start of the application described by the JAD file if found incorrect, missing, or not supported.
A.6 Implementing in Java

The following has to be taken into consideration in the case where parts of the Payment API architecture are implemented in Java: Using protected Java API: if the implementation accesses Java API which needs particular permissions as defined by MIDP2.0 Permission framework, then it may happen that the end user may be confused by permission dialogs. This must be avoided. For example, an implementation where there is a JSR-205 (Messaging API) based payment adapter, is likely to confuse the end user by having first a payment method selection and transaction confirmation dialog followed by the JSR-205 Messaging API permission dialog. The end user would have twice to confirm a payment: first to pay, second to send the SMS.
60
JSR-229 Payment API
Appendix B. More Responsibilities

As extracted from the functional overview in chapter 3.3 and 3.4, and from this specification, here is a summary of the responsibilities of all actors involved in a payment as defined by this specification.
B.1 Application Developer

The responsibilities of an application developer can be summarized as follows: Store application state when necessary: if the application/feature logic makes it possible to buy multiple features (same or different) at once (i.e. using only one call to the process() method), then the application MUST store the state of what has not yet been consumed at a secured place. Please refer to chapter 7.4. The Security and Trust Services API (SATSA) API can also be used if the underlying platform supports JSR177. Accordingly handle all exceptions. Have a contract with an application provider to redistribute that application. Hand over the application to an application provider along with JAD and JAR-Manifest resource files. Although it may not contain all payment-specific fields, the JAR-Manifest MUST at least contain the following fields: Pay-Version, Pay-Feature-<n>.
B.2 Application Provider

The responsibilities of an application provider can be summarized as follows: Must provide the application with the missing fields according to the information delivered by the price manager. Before signing and distributing the application, it MUST verify that all URLs related to payment are correct and point to resources according to the contractual relationship with its price manager(s). Must distribute the application for the end users.
B.3 Price Manager

The responsibilities of a price manager can be summarized as follows: Must collect all price changes from the payment service providers, as needed in the case of a full provisioning update. Must provide access to the latest provisioning information at the location specified in the Pay-Update-URL field in the distributed applications JAR-Manifest file.
JSR-229 Payment API
61
B.4 Payment Service Provider

The responsibilities of a payment service provider can be summarized as follows: Must support the price manager in updating the full provisioning content. Must provide the server-side counterpart of the terminal-side payment adapter.
B.5 Payment Module Implementer

The responsibilities of a payment module implementer can be summarized as follows: The payment module MUST only be accessed by authorized users. It means that either the platform on which the payment module is implemented already authenticates the user (e.g. PIN on mobile phones) or that the payment module needs an additional user authentication mechanism. Other combinations such as platform authentication with an additional time-out mechanism are recommended. For every application, the payment module MUST allocate persistent memory to store all corresponding missed transaction records. The number of missed transaction records to support is platform-dependent. When the application is uninstalled, this persistent memory is to be released accordingly. Refer to chapter A.2. Before accepting a new transaction to be processed (call to the process() method), the payment module must check that it has enough storage left to store this particular transaction in the missed queue. If this is not the case, the payment module MUST throw a TransactionModuleException.
B.6 Payment Adapter Implementer

The responsibilities of a payment adapter implementer can be summarized as follows: If the payment adapter does require the end user to enter critical data (such as credit/debit card or account information), it shall retrieve this information directly from the user or from any user-specific storage (smartcards or similar), and the UI MUST be distinguishable from a UI generated by applications. The implementer is aware that payloads with a size that exceeds 132 bytes is not accepted by any type of payment adapter and hence will be rejected using a TransactionPayloadException. The implementation of adapters that could complete a payment transaction locally (for example payment terminals based on smartcards (GeldKarte, Moneo, etc.)) MUST still support and implement the forwarding of payload to a payment service provider. In turn, the payment service provider may forward it, for example, to the content provider or the application developer (for example to centrally compile highscores or similar).
62
JSR-229 Payment API
Appendix C. Adapter Specifications

This section lists the specification for payment adapters that are part of this specification. It currently defines the Premium Priced SMS (PPSMS) adapter. Future adapters may be included in this section. This definition MAY be reused in other adapter specifications, as long as the specified syntax is not modified and the usage does not overlap with the adapters already defined.
C.1 Adapter: Premium Priced SMS

This chapter describes how the PPSMS MUST be implemented to conform to the requirements of its specific wireless network environment.
C.1.1 Payment Model

Premium Priced SMS defines a payment model where the value of a transaction is determined by the premium priced number to which the SMS is sent and/or by the content described in the body of that SMS. This adapter specification is valid for any combination of SMS-MO (Mobile Originated) and SMS-MT (Mobile Terminated) needed to validate the payment. In any case, the adapter MUST send exactly one 8-bit SMS. This adapter is implemented as part of the RI (Reference Implementation) and is used as a reference adapter by the TCK (Technology Compatibility Kit).
C.1.2 Provisioning Data Specification

Adapter Namespace: PPSMS Attribute name Pay-<ProviderTitle>-info Attribute description As defined in chapter 6.3, the format is <RegAdapter>, <ISO4217CurrencyCode>, <PaymentSpecificInformation>. <PaymentSpecificInformation> format is in this case: <MCC>, <MNC> <MCC>: Mobile Country Code, a 3-digit code as provided by your mobile operator9, <MNC>: Mobile Network Code, a 2 or 3-digit code as provided by your mobile operator. Pay-<ProviderTitle>-tag-<m> The format is <Price>, <PremiumPricedSMSNumber>,<Prefix>[, <NbSMS>] See Pay-<ProviderTitle>-tag-<m> definition in chapter 6.3.
The list of all MCC and MNC codes can be found in the ITU-T Rec. E212 (11/98) or at the following location: http://www.itu.int/ITU-T/inr/forms/files/mnc-1203.pdf
JSR-229 Payment API
63

<PremiumPriced-SMSNumber>: A (phone) number to which the payment SMS will be sent. This number should be provided by the payment service provider in the provisioning information. <Prefix>: Representation of a byte array that will be prepended to any payment SMS before being sent out to the payment service provider. This can be freely defined by the payment service provider together with the application provider. The array MUST NOT exceed (140-132=) 8 bytes in length. The representation is recognized as being hexadecimal if preceded with 0x, otherwise as an ASCII string. The string representation MUST follow the attrvalue BNF rule of the MIDP specification. Hence the hexadecimal representation MUST NOT exceed 16 hexadecimal characters and MUST have an even number of hexadecimal characters. The ASCII string representation MUST NOT exceed 8 characters. This prefix might also be left empty, indicating to the PPSMS adapter that there is no prefix. The hexadecimal representation is case-insensitive. <NbSMS>: This optional field indicates the number of payment SMS that MUST be sent all together to generate the price indicated by <Price>. If not present, the default value is 1. As such: <NbSMS> * [SMS-sent] = <Price>.
C.1.3 Packet Format

The format of the SMS that is sent to the SMS-Center is defined to be the concatenation of the prefix defined in the JAR-Manifest and the payload (if any) passed by the application: [<Prefix>]<Payload>
C.1.4 Limitations
Due to the specified format, the following limitations arise: Attribute Format Restriction Adapter Reliability Limitation 8-bit SMS. Payload is also to be 8-bit encoded. Due to the specifics of payment via SMS and the SMS infrastructure, it is not possible to include an acknowledgement for a payment. Therefore the PPSMS payment adapter implementation MUST return to the payment module immediately after having been able to send that SMS to a given Premium Priced SMS
64
JSR-229 Payment API

number. Consequently, the meaning of TRANSACTION_SUCCESSFUL is biased and only means that there is very high (but not 100%) probability that the payment will be processed correctly by the network infrastructure. Application developers requiring 100% reliability should select payment adapters that do offer such a level of reliability using the Pay-Adapters field in the JAD resource file.
C.1.5 Sample JAR-Manifest

[] Pay-SMS-Info: PPSMS, Pay-SMS-Tag-0: 1.20, Pay-SMS-Tag-1: 2.00, Pay-SMS-Tag-2: 2.13, GBP, 310, 20 990001, AP82LVL1 990002, AP82LVL2, 2 990003, 0x123456789abcdef0, 1
C.1.6 Complex Sample JAR-Manifest

The following example is the typical provisioning case where the application covers multiple PPSMS operators as it might be supplied by content providers. The payment adapter will then select only those provisioning sections that apply to the running platform, i.e. where MNC and MCC apply.
[] Pay-Version: 1.1 Pay-Update-Stamp: 2004-11-15 02:00+01:00 Pay-Providers: SONERA, RADIOG, DNSDNA Pay-Update-URL: http://<update-site>/thisgame.manifest.jpp Pay-Cache: no Pay-Feature-0: 0 Pay-Feature-1: 0 Pay-Feature-2: 1 # If users operator is Pay-SONERA-Info: PPSMS, Pay-SONERA-Tag-0: 1.20, Pay-SONERA-Tag-1: 2.50, # If users operator is Pay-RADIOG-Info: PPSMS, Pay-RADIOG-Tag-0: 1.21, Pay-RADIOG-Tag-1: 2.49, # If users operator is Pay-DNSDNA-Info: PPSMS, Pay-DNSDNA-Tag-0: 1.41, Pay-DNSDNA-Tag-1: 1.99, Sonera, MNC=928, MCC=99 EUR, 928, 99 9990000, 0x0cba98765400 9990000, 0x0cba98765401, 2 RadioG, MNC=747, MCC=88 EUR, 747, 88 34501, 0xf9b500 34502, 0xf9b501, 3 DNSDNA, EUR, 380, 19076501, 19023202, MNC=380, MCC=77 77 _DNS _DNS
JSR-229 Payment API
65
- last page -
66
JSR-229 Payment API

Payment 1 1 Mrel Spec

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Payment 1 1 Mrel Spec

Transféré par

Droits d'auteur :

Formats disponibles

Payment API (PAPI)

For JavaTM 2 Platform, Micro Edition

Version 1.1.0 Maintenance Release

JSR-229 Expert Group jsr-229-eg@jcp.org

Java Community Process (JCP)

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

30-Apr-2004 07-May-2004 14-May-2004 18-Jun-2004

0.5.0 0.6.0 0.7.0 0.8.0

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

04-Feb-2005 17-Feb-2005 04-Mar-2005 29-Mar-2005 13-Apr-2005 01-Sept-2005 08-Sept-2005 09-Nov-2005

0.9.2 0.9.3 0.9.4 0.9.5 1.0.0 1.0.1 1.0.2 1.0.3

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

Who Should Use This Specification

How This Specification Is Organized

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

1 Introduction and Background

Sony Ericsson Mobile Communication AB: Pr Anders Aronsson

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

TABLE 1-1 Specification Terms

1.3.2 Formatting Conventions

Convention Courier New Italic

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

2 Scope and Requirements

The scope of this JSR is to define the following:

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

__ Payment module Payment Payment _adapter adapter

CLDC Native platform

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

Provides application Delivers application

Application provider /merchant

Provisions application Contracts Price manager

Notify & forward payload

Provisions Payment service provider

Commits payment Implements

Standardizes payment method Implementer (JSR/module/ methods)

Legend: <Role> <Component>

Actors and Roles

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

JSR-229 Payment API

COPYRIGHT BENQ MOBILE GmbH & Co OHG Maintenance Release

Payment Module Responsibilities