Home
Reference
Payments subsystem
In WebSphere Commerce, payment processing uses the Payments subsystem.
Payments subsystem
In WebSphere Commerce, payment processing uses the Payments subsystem.
Payment plug-ins
A payment plug-in is a self-contained software component that serves as a proxy for a payment back-end system.
SimplePunchout plug-in
The SimplePunchout plug-in is a sample plug-in that can be used by the Aurora starter store to demonstrate payment by using the punch-out model. When the SimplePunchout plug-in is used, a new browser window opens displaying the third-party payment website.

Reference
- WebSphere Commerce API reference
  WebSphere Commerce exposes two main programming APIs. The first and newest API is a REST interface, and most new classes are exposed here. The legacy Java API also contains new classes not suitable for REST, and can be browsed in Javadoc format.
- Cross-reference of data beans, EJB beans, and tables
  Data beans are grouped into several component groups.
- Cross-reference of commands, tasks, and tables
  URL commands, controller commands, task commands, view commands and tables are related to each other.
- Cross reference: Commands to beans to database tables
  Use this information when you are customizing a command and you want to know which tables are affected. You should also use this topic if you are modifying a table and want to know which commands and beans are affected.
- API changes between WebSphere Commerce Version 7.0.0.9 and WebSphere Commerce Version 8.0.0.0
  If you are migrating version 7.0 of WebSphere Commerce, review the API changes between releases.
- WebSphere Commerce database schema
  The WebSphere Commerce database model was designed for data integrity and optimal performance. WebSphere Commerce provides several hundred tables that store WebSphere Commerce instance data. To maintain data integrity, and to ease maintenance referential integrity, constraints are widely used in the database model. Indexes are used carefully on tables to avoid over-indexing and to provide a good balance between data retrieval and data manipulation activities (insert and update). The business rules are implemented at the application level rather than by using database trigger. Triggers, however, are used to facilitate data staging and optimistic locking. A limited number of SQL-based database stored procedures are used for data intensive activities.
- Payments subsystem
  In WebSphere Commerce, payment processing uses the Payments subsystem.
  - Payments subsystem
    In WebSphere Commerce, payment processing uses the Payments subsystem.
    - Payments subsystem architecture
      The Payments subsystem contains three main parts: Payment rules engine, Payment plug-in controller, and payment plug-ins.
    - Payment life cycle
      There are three stages to payment processing: validation, reservation, and finalization. The payment life cycle is related to the order life cycle stages: order capture, release to fulfillment, and shipping.
    - Payment plug-ins
      A payment plug-in is a self-contained software component that serves as a proxy for a payment back-end system.
      - LOC (Line of credit) plug-in
        The LOC plug-in enables merchants to use lines of credit as a payment method. It enables buyers to delay the payment settlement for orders and is intended to integrate with accounts receivable systems used by customers. The LOC plug-in mimics the function of an actual line of credit. By default, it does not connect to an accounts receivable system. To connect to an account receivable system, you must write your own version of the plug-in.
      - SimpleOffline plug-in
        The SimpleOffline plug-in enables payments to be processed offline, or manually. Offline payments do not involve any direct communication with a payment back-end system. Instead, the SimpleOffline plug-in records events that have already happened outside of WebSphere Commerce. Transactions are recorded and maintained in the WebSphere Commerce database.
      - Paymentech plug-in
        The Paymentech plug-in allows the Payments plug-in controller to communicate directly with the Paymentech gateway by using the plug-in.
      - SimplePunchout plug-in
        The SimplePunchout plug-in is a sample plug-in that can be used by the Aurora starter store to demonstrate payment by using the punch-out model. When the SimplePunchout plug-in is used, a new browser window opens displaying the third-party payment website.
  - Extended data in payments or credits
    Some payment plug-ins require extra protocol data or keywords to communicate with a back-end system. This extra protocol data called extended data is in addition to the standard attributes defined in the PaymentInstruction definition. Extended data is any data other than the currency, amount of the payment instruction, and the payment method name. For example, credit card number, expiration, and billing address are extended data.
  - Payment rules provided in WebSphere Commerce
    Payment rules specify the payment actions that should occur for the payment methods a store accepts for its goods or services. Payment actions and credit actions are determined in terms of current-to-target state movements. payment rules define what target state a payment should be in by defining the actions needed to move a payment from its current state to the target state.
  - Payment configuration files
    Use these files when configuring the Payments subsystem and payment plug-ins.
  - Payment plug-in specification
    Review the following overview of the payment plug-in specification to better understand how you can use payment plug-ins.
- Dynamic caching
  In general, caching improves response time and reduces system load. Caching techniques are used to improve the performance of World Wide Web Internet applications. Most techniques cache static content (content that rarely changes) such as graphic and text files. However, many websites serve dynamic content, containing personalized information or data that changes more frequently. Caching dynamic content requires more sophisticated caching techniques, such as those provided by the WebSphere Application Server dynamic cache, a built-in service for caching and serving dynamic content.
- Data Load utility configuration file schema
  The Data Load utility contains several configuration files. You can use the configuration file schema to understand and customize the data load configuration files.
- WebSphere Commerce web services
  WebSphere Commerce provides many web services.
- Utilities
  Utilities help you to accomplish administrative or configuration tasks, for example, loading data, publishing a store.
- Shopping flow URLs
  WebSphere Commerce shopping flow URLs are organized by subsystem.
- Ant targets
  A WebSphere Commerce instance can be created from the command line. The command-line utility uses Apache Ant to create the objects required. The targets are divided into several high-level groups that correspond to the environment that is to be configured.
- Glossary

SimplePunchout plug-in

The SimplePunchout plug-in is a sample plug-in that can be used by the Aurora starter store to demonstrate payment by using the punch-out model. When the SimplePunchout plug-in is used, a new browser window opens displaying the third-party payment website.

Note: SimplePunchout plug-in can be used only to demo or sample punch-out payment support of IBM® WebSphere Commerce. It is used against a payment gateway simulator; it cannot be used to connect to real payment gateways such as PayPal.

Methods

The SimplePunchout plug-in follows the Payment plug-in specification and implements the PunchoutPlugin interface.

The SimplePunchout plug-in implements the following APIs:

Note: approveAndDeposit is classical payment API; the other methods are unique to the PunchoutPlugin interface.

approveAndDeposit(PluginContext, FinancialTransaction, boolean): This method is used to "approve and deposit" the amount for the order, it only locally set the payment processing to pending. Later in the PunchoutPaymentCallBackCmd, the payment status will be updated to success or fail according to the result from the third-party system.

getAuthenticationURL(PluginContext, PaymentInstruction): This method builds the URL for the third-party payment system that is used to punch-out (or to redirect to).

initAuthenticationSession(PluginContext, PaymentInstruction): This method is used to initialize the authentication session.
Note: Since SimplePunchout plug-in works with the simulator and does not need an authentication session, this method is not used by the SimplePunchout plug-in.

preprocessProviderResponseData(PluginContext, Map): This method is used to parse the unique ID - corresponding to the PPCPAYINST_ID on WebSphere Commerce side - from the third-party payment system's call-back URL.

processProviderResponse(PluginContext, PaymentInstruction, Map): This method is used to check whether this callback request is a real and valid request from the correct third-party payment system, and then parses the result of the payment processing.