Payments subsystem
Overview
The Payments subsystem connects to Payment Service Providers by using payment plug-ins.
If you migrate from a previous release of WebSphere Commerce, you can continue to use the WebSphere Commerce Multipayment Framework in one of two ways.
- Compatible mode
- If you use compatible mode, then we will not use the Payments subsystem. You will use WebSphere Commerce Multipayment Framework in the same way as in previous releases.
- WCPayments plug-in
- Use a payment plug-in as a bridge to WebSphere Commerce Payments and cassettes.
See
- Merchant feature
Manage store-specific properties from the Payment perspective.
- Add a new payment or refund method
If you are adding a new payment method or refund method, update the WebSphere Commerce database tables that contain information about the payment methods or refund methods that the store will use. The business policy tables do not contain information about the type of payment or refund actions or rules the Payments subsystem will use. They identify the payment and refund methods. The payment and refund actions are defined by configuring XML files.
- Customize the business flow for payment processing
If the business flow provided by payment rules does not meet the business needs, you can customize the business flow used for payment processing.
- Use other payment protocol data to find orders
As provided, WebSphere Commerce enables you to perform an advanced search for orders using the payment account information as the search criteria. For example, on the Find Orders page in the WebSphere Commerce Accelerator, you can search orders and include the cardholder account number as part of the search criteria.To search on other types of payment protocol data, or to include other payment protocol data with the account number as part of the search criteria, modify the order search JSP file used to perform order searches. The following examples describe how to substitute some other field for account, and how to add a second field to be used in addition to the account field.
- Create a payment plug-in
- Payment financial transaction state
When the Payment plug-in controller calls a payment plug-in to perform a financial transaction, the plug-in can return one of the three possible transaction states: Success, Failure, Pending. A pending state indicates that a particular transaction has not yet finished for a payment or credit transaction. It could mean that a plug-in uses an offline protocol to handle transactions, thereby some external intervention or action by a human must take place to move the payment or credit into another state. Offline processing typically requires human interaction to process transactions over the phone or by using a swipe machine. A payment or credit can also be in pending state for other reasons, such as when timeouts occur on the network or processing over the network is extremely slow. The pending state applies to both the payment and the payment transaction. If a pending approval transaction exists, then another payment approval cannot be issued until the prior pending approval transaction is successful.
- Plug-in exception handling and transaction roll-back
If a payment transaction fails, and that failure results in a WebSphere Commerce transaction roll back, then the payment transaction data is not in the WebSphere Commerce database.
- 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
This section provides an overview of payment plug-ins the payment plug-in specification.
- WCPayments plug-in
TheWCPayments plug-in implements the Payment plug-in specification to process payment actions (financial transactions). TheWCPayments plug-in acts as a bridge to WebSphere Commerce Payments Multipayment Framework and the use of payment cassettes.
- Replacement commands for WebSphere Commerce Payments Multipayment Framework commands
The payments commands interface names are in API information package com.ibm.commerce.payment.commands. If you customized or extended a WebSphere Commerce Payments Multipayment Framework command do not move the customized code to the replacement command.
- LOC plug-in financial transactions
Payment plug-ins can perform payment actions differently. The following table describes how the LOC plug-in performs financial transactions (payment actions). This information might be useful to plug-in writers who are modeling plug-ins after the LOC plug-in. In summary, the payment actions performed by the LOC plug-in involve checking the presence of data in the payment instruction.
- SimpleOffline plug-in financial transactions
The SimpleOffline plug-in performs several financial transactions (payment actions). Plug-in writers who are modeling plug-ins after the SimpleOffline plug-in could model the financial transactions in a similar way.
- SimpleOfflinePlugin.xml
This file contains a list of the unique parameters required for each payment method supported by the plug-in.
- 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.
Related concepts
Payments subsystem architecture
Payment events and task commands
Related tasks
Migrate to the WCPayments plug-in