> For the complete documentation index, see [llms.txt](https://docs.verifone.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verifone.com/psdk-latest/psdk-user-guide-and-training/psdk-training-videos/psdk-classes.md). # PSDK Classes {% embed url="" %} **Transcript**: Before we go through the classes, it’s important to understand how the Payment SDK is structured.

All PSDK classes are asynchronous, so every API call returns immediately after being invoked. The actual result of the operation is delivered later through callbacks. To receive these callbacks, you must register listener objects with the main PaymentSDK instance. These listeners act as notification handlers, providing updates about the transaction flow and the final status of each operation. Internally, all asynchronous calls are queued and executed sequentially, following standard Android communication patterns for background task handling. This ensures thread safety, proper synchronization and predictable execution order across different SDK components.

These classes are the most important ones for semi and slim integrations, you will use them during the app development phase in the labs. Please note that this isn't a comprehensive list, you can find the complete list in the documentation. Let's learn how PaymentSDK, CommerceListener2, CommerceListener Adapter, TransactionManager, BasketManager and Merchandise work. Now you might encounter classes with a 2 at the end. Always make sure to use those, as they are the most updated ones.

The PaymentSDK is the most important class because it is the main entry point for the SDK. When creating an application, the first thing you need to do is to create an object of this class, as it is responsible for establishing a connection between the POS app and the payment application. This class exposes an API known as initializeFromValues(), which enables the establishment of a connection between the POS app and the payment application. This can be used with On device and Off device. We also have initialize() API, a simplified version that only works with on device integration, where you don't need to set different properties and call them, you just pass the listener and everything is taking care of by PSDK.

In the Payment SDK, listener classes handle notifications from the payment application during a transaction, which is why they are called notification classes. We have 2 main ones: CommerceListener2 and CommerceListenerAdapter. To use CommerceListener2 you need to create an object of this class and register it with the PaymentSDK. This class has a set of callbacks that are pure virtual functions. The SDK calls them periodically to report progress or status. You need to implement all of them to your code when using CommerceListener2. During transactions, the payment application will send notifications to the callbacks. Through them, we will know the outcomes of the events.

The **CommerceListenerAdapter** is a similar class. However, there is a significant difference: this class features a set of virtual functions which are not pure. Therefore, you are able to implement only the methods you require, as opposed to **CommerceListener2**, where you must implement all of them. You ultimately have the choice of using either one. Additionally, it is a class derived from the previous one. **TransactionManager** is another important class because it exposes all the methods for transaction: login, logout, start a session, start a payment, and others you can see listed here.

There is a specific order in which these methods need to be called. To do this effectively, please refer to the [**PSDK State Transitions**](https://docs.verifone.com/V9zKsMIuf2KYcUBMtuix/psdk/reference-material/code-labs/getting-started) table found in the documentation to initiate the payments. It is important for you to follow this table as it illustrates how the State Transitions can occur. To understand it correctly, look at the Actions columns to see the APIs, and the callbacks which you can identify since they start with the word 'handle.'

The third column indicates when you can call the Action; for instance, Login can only occur when it is in a state of not being logged in. The fourth column shows the state when the API is being handled. As an example, for Login, the state is 'logging in'. Finally, the last column shows what happens when the Action is completed; for example, the action of logging in is complete once 'logged in' is achieved. Now, let's discuss the BasketManager and Merchandise classes.

You can initiate a transaction in two ways. You can either add the amount to the POS app or select from a list of items in an inventory. To start a transaction using the latter method you need to use both the BasketManager and Merchandise classes. BasketManager enables you to create a basket and add items. It will then transmit the cart details to the payment application.

The Merchandise class, on the other hand, will allow you to define the merchandise items that will be used by the BasketManager. Use the different objects in the class to define the items you need. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verifone.com/psdk-latest/psdk-user-guide-and-training/psdk-training-videos/psdk-classes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.