1. Extending Oracle Commerce
  2. Enable Split Payments
  3. Understand split payments

Understand split payments

Depending on the needs of your store, you may want to enable shoppers to split order payments across multiple payment types.

Some online stores require a shopper to use a single payment method to pay for an order. For example, the shopper supplies a credit card at checkout, and uses it to pay for the entire order. In this situation, the order involves a single transaction, which includes information about the payment method (the credit card) and the amount charged to it (in this case, the total for the order), and so on.

Some shoppers, though, may want to split the cost of an order across two or more payment methods, or across multiple instances of a payment method (such as two different credit cards), or even a combination of both (such as a gift card and two credit cards). For example, if a shopper has a $50.00 gift card and an order’s total cost is $85.00, the shopper may want to pay $40.00 using the gift card, and charge the remaining $45.00 to a credit card. Or a shopper may want to charge part of an order to one credit card, and the rest to another.

Some of the payment widgets (such as the Payment Details widget) support split payments in a limited way. They allow the use of multiple gift cards, or one or more gift cards plus one other payment method (such as a credit card, an invoice, or cash.) To support more complex scenarios, Commerce provides the Split Payment widget. This widget provides user interface controls that the shopper can use to break down the order cost into multiple parts, with each part associated with a different payment method instance. The widget also provides a single payment setting the shopper can switch to. The single payment setting supports the same options as the standard payment widgets (a single payment method, multiple gift cards, or gift cards plus one other method).

The Split Payment widget can be used with built-in payment gateway integrations (such as CyberSource) and payment gateway integrations you create (as described elsewhere in this manual), but requires customization in order to work with web checkout systems such as Amazon Payments. See Integrate with a Web Checkout System for information about processing payments using one of these systems.

Understand the Payment Options settings

The Setup tab in the Payment Processing settings of the administration interface has a Payment Options drop-down that controls certain aspects of how payments are processed in Commerce. This drop-down has two options:

  • Allow Partial Payment/Early Persist – This setting should be used with storefronts built with the Open Storefront Framework, as well as Storefront Classic applications that use the Split Payment widget. With this setting, when the shopper submits the order, the payments are processed in sequence, one payment at a time. The order is saved in the PENDING_PAYMENT state until the entire cost of the order has been authorized. If all authorizations succeed, the order is then sent to the order management system for processing. If any authorization fails, the successful authorizations are saved with the order. The shopper can correct the payment details, or leave the order in the PENDING_PAYMENT state and return later to specify payments for the remaining amount and resubmit the order.
  • Full Payment Required – With this setting, when an order is submitted, all of the payments are processed at the same time. If authorization for any method fails, an error is displayed, and the successful authorizations are voided. The shopper must re-enter all payments and resubmit the order. If all of the payments are successfully authorized, the order is sent to the order management system for processing.

For additional information about these options, see Implement robust order capture.

For a registered shopper, partially paid orders are persisted and appear in the shopper’s order history. The shopper can retrieve a partially paid order from the list and complete it. If the Order Payment Initiated email is enabled in the administration interface, an email is sent to the shopper when the order is created. The email includes the order ID. The shopper can use this ID to help locate and retrieve the order, or supply the ID to a customer service agent, who can then complete the order in the Agent Console.

For an anonymous shopper, the shopper must complete a partially paid order before the session times out, because the shopper has no way to access the order when returning to the site later. However, if the Order Payment Initiated email is enabled, the shopper is sent an email with the order ID when the order is created, and can supply this ID to a customer service agent for completing the order.

In addition to the drop-down, the Setup tab in the Payment Processing settings has a Price Hold Period setting that specifies the amount of time the shopper is given to provide missing payment information before an order is canceled. If a partially paid order is not completed before the price hold period expires, the order is marked for cancellation and is subsequently removed. To handle the actual removal of orders, a scheduled service is run. This is the same service used in account-based commerce to remove orders that have been approved but not paid for after the specified amount of time. See Set the frequency of canceled order clean up for information about configuring this service.

Partial payments must be enabled if any of the payment methods you support requires the shopper to take action while the payment is being processed. For example, if you have a credit card gateway integration that supports 3D-Secure, when the payment is processed, the shopper must authenticate with the card provider. Enabling partial payments ensures that payments are processed sequentially, preventing the authentication pages for multiple payments from displaying simultaneously or overwriting each other.