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)

See Also:

#AUTHORIZE}, #CAPTURE}, #AUTHORIZE_AND_CAPTURE}, #SETTLED}, #REFUND}, #DETACHED_CREDIT}, #VOID}, #REVERSE_AUTH}, #UNCONFIRMED}, #PENDING} The following is a depiction of the possible state flows for an Order Payment and the hierarchical relationship of all its transactions: +-------------+ | UNCONFIRMED | +-+-----------+ | | +--------------------+ +-+ PENDING (Optional) | +-+----------------+-+ | | | +-----------+ | +-----------------------+ +-+ AUTHORIZE | +----------------+ AUTHORIZE_AND_CAPTURE | +-+---------+ +-+---------------------+ | | | +-------------------+ | +------+ +-+ REVERSE_AUTHORIZE | +-+ VOID | | +-------------------+ | +------+ | | | +---------+ | +--------------------+ +-+ CAPTURE | +-+ SETTLED (Optional) | +-+-------+ +-+------------------+ | | | +------+ | +--------+ +-+ VOID | +-+ REFUND | | +------+ +--------+ | | +--------------------+ +-+ SETTLED (Optional) | +-+------------------+ | | +--------+ +-+ REFUND | +--------+ +-------------+ | UNCONFIRMED | +-+-----------+ | | +-----------------+ +-+ DETACHED_CREDIT | +-+---------------+, Serialized Form

Field Summary

Fields

Modifier and Type	Field and Description
static PaymentTransactionType	AUTHORIZE Funds have been authorized for capture.
static PaymentTransactionType	AUTHORIZE_AND_CAPTURE Funds have been captured/authorized all at once.
static PaymentTransactionType	CAPTURE Funds have been charged/submitted/debited from the customer and payment is complete.
static 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.
static PaymentTransactionType	PENDING Some implementations may wish to defer any Authorization or Authorize and Capture transactions outside the scope of the checkout workflow.
static PaymentTransactionType	REFUND Funds have been refunded/credited.
static PaymentTransactionType	REVERSE_AUTH The reverse of AUTHORIZE.
static PaymentTransactionType	SETTLED Can ONLY occur after a payment has been CAPTUREd.
static 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.
static PaymentTransactionType	VOID Void can happen after a CAPTURE but before it has been SETTLED.

Constructor Summary

Constructors

Constructor and Description
PaymentTransactionType()
PaymentTransactionType(String type, String friendlyType)

Method Summary

Methods

Modifier and Type	Method and Description
boolean	equals(Object obj)
String	getFriendlyType()
static PaymentTransactionType	getInstance(String type)
String	getType()
int	hashCode()

Methods inherited from class java.lang.Object

clone, finalize, getClass, notify, notifyAll, toString, wait, wait, wait

Field Detail

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 Detail

PaymentTransactionType

public PaymentTransactionType()

PaymentTransactionType

public PaymentTransactionType(String type,
                      String friendlyType)

Method Detail

getInstance

public static PaymentTransactionType getInstance(String type)

getType

public String getType()

Specified by:

getType in interface BroadleafEnumerationType

getFriendlyType

public String getFriendlyType()

Specified by:

getFriendlyType in interface BroadleafEnumerationType

hashCode

public int hashCode()

Overrides:

hashCode in class Object

equals

public boolean equals(Object obj)

Overrides:

equals in class Object