Payment types can be used as a condition for promotions, for example, “Use your American Express card and get 10% off of your next purchase.” The promotion repository item contains the paymentTypes property, which represents the name of a specific payment type.
Payment types represent the same payment methods as payment groups, such as cash, credit card, store credit, but allow you to create specific definitions. For example, some payment methods can have a higher level of granularity or variation, such as different credit card vendors like American Express, or Visa. Payment types that contain a variant refer to both the payment type and the variant, such as creditCard:AMEX. When a merchandising user creates or edits a promotion, they have the ability to select as many payment types as they would like. If they do not select a payment type, all payment types are selected by default.
Payment Types
There are two different categories of payments.
Payments that relate to a whole group, such as cash or any credit card, which are represented by the
GroupPaymentTypeclass. This class uses the booleanhasVariationsproperty to identify if the group payment type has variantsPayments that relate to a specific variant of a payment group, such as American Express credit card, which are represented by the
PaymentTypeclass. ThePaymentTypeclass does the following:Builds a new payment type object
Checks to see if another object is equal to the payment type objects
Returns the string and display name of the payment type object
The PaymentType class uses the following properties:
Property | Description |
|---|---|
| The specific variant of this payment type. For example, credit card American Express. This property may be null. |
| The name that is displayed for the payment type. |
| A resource key that can be used to look up a resource string. |
| The name of the resource bundle that can be used to identify the |
| Denotes the payment group that is associated with this payment type object. |
When creating payment type objects, the CreditCardTools class manages the credit card variations with the supportedPaymentGroup indicating which payment group it supports, for example, creditCard, which is the default setting. Both CreditCardTools and PaymentManager implement the PaymentTypeProvider interface, which returns all payment types managed by a given PaymentTypeProvider for a type of payment group.
The PaymentTypeProvider gets payment type objects for all payment type variations associated with the payment group that has been passed to it. Because some payment type providers support more than one payment group, the PaymentTypeProvider then returns a set of payment types corresponding to that payment group. This allows the system to refer to the correct payment group.
Important: PaymentManager is the default PaymentTypeProvider for payment types that have no variations or additions. If you are going to create a new type of PaymentType, it is advised to create a new PaymentTypeProvider as described in the Creating a Payment Type Provider section.
When a promotion contains a required payment type, the PaymentManager expects to receive a set of strings that identify these payment types using the getPaymentTypes method. This method parses a payment group identifier out of each string and uses that to identify a specific payment type provider. It then passes the string to the payment type provider and requests that it returns a payment type object that represents the string.
Note: If a new payment type is created, it will not be automatically added to pre-existing promotions that do not use the ‘all payment types’ default setting. As such, these types of pre-existing promotions must be updated.
When a new payment group is created, it is possible for a promotion with associated payment types to be applied to an order. This occurs because payment groups are often created early in the process, before any payment method has been selected. For example, if a store creates a Cash default payment group at the beginning of the process, and there happens to be a cash-based promotion, even though a shopper has not selected a payment method, they will receive the promotion. Although this may be useful in certain cases, payment type promotions are by default not applied until the relevant payment group has an associated payment group order relationship.
The creation of the relationship coincides with the selection of the billing type. The PaymentManager contains the includePaymentGroupsWithoutOrderRelationships property that returns a flag indicating whether to include payment types for payment groups that have no explicit relationship with the current order when searching for the payment types for an order. When set to false, which is the default setting, payment types that do not have a relationship with the order will not be included in the promotion. For information on relationships with orders and payment groups, refer to the Using Relationship Objects section.
Payment Types and Promotion Vetoing
If the relevant match is not found between an order’s payment types and a promotion’s payment types, the promotion will be vetoed. Vetoing can be configured to exclude specific payment types or identify if payment types can be used for partial or full payment of the order. For information on vetoing promotions refer to the Tender-Based Promotion Vetoing section.
Importing Promotions with Payment Types
When importing promotions, if there is no payment type contained in the import file, no payment type will be added to the promotion. As described in detail earlier, if the repository does not get paymentType property information to add to the repository, the system identifies that there are no restrictions on the promotion.
Searching for Promotions with Payment Types
When a user searches for a promotion, the search results may be unexpected. When a user enters search criteria in the Find panel for a promotion’s payment type, such as cash, the search will return all promotions that have been restricted to the cash payment type. Promotions that do not have payment type restrictions will not be included in the search results.
For additional information on searching for promotions, refer to the Merchandising Guide for Business Users.
Creating a Payment Type Provider
If you create a new payment method, as described in detail in the Extending the Payment Process to Support a New Payment Method section, you may want to create a new payment type provider.
You can create a new payment type provider by performing the following:
When you create the payment group, implement the
PaymentTypeProviderinterface. The following is an example of an implementation of thePaymentTypeProviderin aneWalletclass.public class eWallet extends GenericService implements PaymentTypeProvider {Identify the payment groups that the payment type provider supports. For example
supportedPaymentGroup=eWalletOnce you have created the payment type, you must register the new payment type provider in the
paymentGroupIdentifierToPaymentTypeProviderproperty of thePaymentManager. The following example adds an eWallet payment type provider:paymentGroupIdentifierToPaymentTypeProvider=\
eWallet=/atg/commerce/payment/eWallet,\
The creditCardTools class implements the PaymentTypeProvider interface and identifies the PaymentType, identifies and then creates a map of SupportedPaymentTypes. To refer to the creditCardTools class as an example, see the ATG Platform API Reference.
