Package org.broadleafcommerce.common.payment

Class PaymentTransactionType

java.lang.Object
org.broadleafcommerce.common.payment.PaymentTransactionType
All Implemented Interfaces:
Serializable, BroadleafEnumerationType
public class PaymentTransactionType extends Object implements Serializable, BroadleafEnumerationType
The PaymentTransactionType is used to represent the types of operations/transactions that could occur against a single payment. In the Broadleaf core framework, these types appear on the org.broadleafcommerce.core.payment.domain.PaymentTransaction.
Author:
Jerry Ocanas (jocanas), Phillip Verheyden (phillipuniverse), Elbert Bautista (elbertbautista), Jerry Ocanas (jocanas), Phillip Verheyden (phillipuniverse), Elbert Bautista (elbertbautista)
See Also:

  • Field Details

    • AUTHORIZE

      public static final PaymentTransactionType AUTHORIZE
      Funds have been authorized for capture. This might appear as a 'pending' transaction on a customer's credit card statement

    • CAPTURE

      public static final PaymentTransactionType CAPTURE
      Funds have been charged/submitted/debited from the customer and payment is complete. Can ONLY occur after an amount has ben AUTHORIZEd.

    • AUTHORIZE_AND_CAPTURE

      public static final PaymentTransactionType AUTHORIZE_AND_CAPTURE

      Funds have been captured/authorized all at once. While this might be the simplest to implement from an order management perspective, the recommended approach is to AUTHORIZE and then CAPTURE in separate transactions and at separate times. For instance, an AUTHORIZE would happen once the Order has completed checkout but then a CAPTURE would happen once the Order has shipped.

      NOTE: Many Gateways like to refer to this as also a SALE transaction.

      This should be treated the exact same as a CAPTURE.

    • SETTLED

      public static final PaymentTransactionType SETTLED
      Can ONLY occur after a payment has been CAPTUREd. This represents a payment that has been balanced by the payment provider. This represents more finality than a CAPTURE. Some payment providers might not explicitly expose the details of settled transactions which are usually done in batches at the end of the day.

    • REFUND

      public static final PaymentTransactionType REFUND

      Funds have been refunded/credited. This can ONLY occur after funds have been CAPTUREd or SETTLED. This should only be used when money goes back to a customer. This assumes that there will be a parent AUTHORIZE_AND_CAPTURE, CAPTURE, or SETTLED transaction that this can be tied back to.

      NOTE: This can also be referred to as a "follow-on credit"

    • DETACHED_CREDIT

      public static final PaymentTransactionType DETACHED_CREDIT

      Some payment processors allow you to issue credit to a customer that is not tied to an initial AUTHORIZE or AUTHORIZE_AND_CAPTURE transaction. Most payment gateways disable this feature by default because it is against card association (e.g. Visa, MasterCard) rules. However, there may be legitimate instances where you had a sale transaction but are not able to issue a refund (e.g. closed account of original payment etc...) Please contact your payment gateway provider to see how to enable this feature.

      NOTE: This can also be referred to as a "blind credit" or "stand-alone credit"

    • VOID

      public static final PaymentTransactionType VOID

      Void can happen after a CAPTURE but before it has been SETTLED. Payment transactions are usually settled in batches at the end of the day.

    • REVERSE_AUTH

      public static final PaymentTransactionType REVERSE_AUTH
      The reverse of AUTHORIZE. This can ONLY occur AFTER funds have been AUTHORIZEd but BEFORE funds have been CAPTUREd.

    • UNCONFIRMED

      public static final PaymentTransactionType UNCONFIRMED

      This applies to payment types like "PayPal Express Checkout" and Credit Card tokens/nonce where a transaction must be confirmed at a later stage. A payment is considered "confirmed" if the gateway has actually processed a transaction against this user's card/account. There might be instances where payments have not been confirmed at the moment it has been added to the order.

      For example, there might be a scenario where it is desirable to show a 'review confirmation' page to the user before actually hitting 'submit' and completing the checkout workflow (this is also the desired case with gift cards and account credits).

      It is important to note that all "UNCONFIRMED" transactions will be confirmed in the checkout workflow via the ValidateAndConfirmPaymentActivity. That means that any unconfirmed CREDIT_CARD transactions will be "Authorized" or "Authorized and Captured" at time of checkout. If the Order Payment is of any other type, then the activity will attempt to call the gateways implementation of: PaymentGatewayTransactionConfirmationService.confirmTransaction(org.broadleafcommerce.common.payment.dto.PaymentRequestDTO)

    • PENDING

      public static final PaymentTransactionType PENDING

      Some implementations may wish to defer any Authorization or Authorize and Capture transactions outside the scope of the checkout workflow. For example, some may wish to take all orders up front (possibly just doing AVS and CVV checks during checkout) and opt to process the users card offline or asynchronously through some other external mechanism or process. In this scenario, you may create an Order Payment with a transaction that "marks" it with the intention of being processed later. This allows the ValidateAndConfirmPaymentActivity to correctly compare the equality of all the successful payments on the order against the order total.

      NOTE: This differs from UNCONFIRMED because at the time of checkout, the checkout workflow will try to AUTH or SALE any UNCONFIRMED transactions on all the payments.

  • Constructor Details

    • PaymentTransactionType

      public PaymentTransactionType()

    • PaymentTransactionType

      public PaymentTransactionType(String type, String friendlyType)

  • Method Details