This class is a value object container for credit-related transactions.
This Interface is a value object container representing a financial transaction.
This interface is a value object container for payment-related transactions.
This interface is a value object containing detailed information required by plug-ins to process financial transactions (FinancialTransaction).
This interface is implemented by a payment plug-in.
This interface extends the interface of Plugin , in order to support new APIs for online Plugins such as PaymentechPlugin.
This interface is the plug-in metadata and configuration.
This interface contains most of the constants use by Payment Plug-in Controller and plug-ins for the different transactions and other needs.
This interface is the request context used in financial transactions and queries.
This interface is implemented by payment plug-ins that support financial queries.
This class is a value object container that aggregates non-standard protocol data required in financial transactions(FinancialTransaction).
This class represents a data attribute with a name, a value, and an encryption flag.
This class defines standard translated messages and the utility to retrieve them.
This Exception is thrown when a plug-in finds out that the payment approval (authorization) has expired.
This exception is thrown by a plug-in when it experiences a connectivity problem while communicating with the payment back-end system.
This exception is thrown by a plug-in when it cannot find required information from PluginConfiguration.
This exception is thrown whenever a transaction against the back-end system fails with a financial error.
This exception is thrown when a type of financial transaction is not supported by the plug-in implementation.
This class is thrown when an unexpected error happened in the plug-in implementation.
This exception is thrown either by the Payment Plug-in Controller or by the plug-in.
This exception is thrown to indicate the PaymentInstruction is invalid.
This exception is thrown when a financial transaction cannot be processed against a PaymentInstruction.
This class is the base exception for the plug-in exception hierarchy.
This Exception is thrown if a plug-in times out waiting for a response.
Contains the IBM payment plugin specification.
A payment plug-in is a stateless session bean that externalizes payment services for a particular payment back end, payment processor, or payment service provider (PSP).
The service comprises the basic financial transactions expected in the implementation of a payment protocol. Examples include transactions for credit cards, electronic checks, gift certificates and credit lines.
A plug-in implementation consists of the following:
Plug-in deployment descriptor
The plug-in deployment descriptor should follow this schema: descriptor.xsd.
Here is an example: descriptor.xml.
For details on each attribute of the plug-in deployment descriptor, please refer to PluginConfiguration.
Payment Plug-in Controller
Payment plug-in API methods are invoked by the IBM Payment Plug-in Controller (PPC). The Payment Plug-in Controller provides a unified view of all payment protocols being implemented by plug-ins by means of a simple facade. Merchants can use Payment Plug-in Controller to access multiple payment back ends through a simple and unique API. Merchants use the Payment Plug-in Controller to process orders and refunds. The Payment Plug-in Controller is the IBM WebSphere Commerce solution for multiple payment protocols in business-to-consumer (B2C) and business-to-business (B2B) shopping flows.
The Payment Plug-in Controller provides the following facilities to plug-in implementations:
Dynamic plug-in and back-end system selection
When dealing with financial transactions for orders and returns, the Payment Plug-in Controller needs to determine which plug-in will process those requests. Since multiple plug-ins can be configured in a single environment. A selector called payment system name is used in every request to the Payment Plug-in Controller. The Payment Plug-in Controller uses the payment system name to determine, based on configuration, which plug-in implementation will process the request.
A plug-in can also implement multiple payment protocols and communicate with multiple payment back-end systems by itself. With that purpose, the payment system name is also passed in the PaymentInstruction. The PaymentInstruction is available directly or indirectly in each and every plug-in API method.