Reference > Payments subsystem > Payments subsystem > Payments subsystem architecture
Payments subsystem advantages
The Payments subsystem offers many advantages compared to the WebSphere Commerce Multipayment Framework.
- Payment plug-ins
- Payment plug-ins are easier to develop and test than payment cassettes.
- You do not need to use payment cassettes.
- It is not necessary to use the payment task commands (such as DoPayment and DoDeposit) and policy commands to perform transactions. The use of many of these commands is not supported with the payment plug-ins.
- Query APIs can implement query logic, if required.
- Plug-ins do not have to issue database commands to process or store data.
- As a J2EE component, a plug-in implements a component-oriented design.
If you are currently using payment cassettes, consider these advantages and evaluate whether the payment processing would be better served by the use of payment plug-ins instead.
- Clustering
- Unlike WebSphere Commerce Payments Multipayment Framework, payment plug-ins are supported in a clustered environment (clustering with horizontal clones, or clustering with vertical clones).
- Coexistence
- Multiple plug-ins can be used to communicate with various payment back-end systems.
- Compatibility with earlier versions
- If integrate with payment cassettes, you can use the WCPayments plug-in.
- Easier migration
- Migration is easier:
- There are no database tables that need to be migrated for a payment plug-in when new versions of payment plug-ins are provided.
If you migrate from WebSphere Commerce Payments Multipayment Framework to a payment plug-in, then data must be migrated from the WebSphere Commerce Payments database to the database tables used by payment rules.
- Payment plug-ins do not use cassette administrative or financial objects associated with the use of the WebSphere Commerce Payments Multipayment Framework.
- There are no PSPL files (documents that define a payment cassette's Web page) to deal with if you are writing a plug-in.
- Order functions
- Payments can be processed for multiple releases of an order. For example, when part of an order ships to one address, and the rest of the order ships to another address. Additionally, more than one payment transaction can occur in an order. For example, you can charge a credit card for the part of an order that ships immediately, and charge the remaining items a week later when the backordered items ship. Customers can also use multiple payment methods or multiple payment instructions for an order. For example, a credit card can be used to pay for part of the order and a check for the balance.
- payment rules
- Payment actions are not hard-coded. The actions are based on the order life cycle and the configuration. payment rules run different actions at different times based on the payment methods used by the store. If the provided rules do not suit the needs, you can also configure other payment rules by using XML files and updates to business policy tables. Payment methods can be associated with the provided payment rules, and the core behavior of payment actions can be configured in terms of what actions should be taken to reach target states for the payment.
- Refunds
- Payments can be processed to issue refunds for returns on one or more orders. For example, a single refund transaction can occur for orders 1234 and 4567, rather than two transactions. In this example, if the two orders were placed using different credit cards, then the refund will be credited to the credit card used to pay for the first order. By default, the credit card used to pay for the first order is used as the refund method.
- Edits
- You can use WebSphere Commerce Accelerator to edit or update payment amounts and other payment information. For example, if a credit card is reported as stolen, then new credit card information can be added.
Related concepts
Payments subsystem architecture
Related tasks
Migrate to the WCPayments plug-in