Fulfillment Scenarios

Item Qualification

Since there are many pieces within the offer_criteria object of the Banyan Offer data model, it is important to understand what result to expect in different purchase scenarios. Each item is assessed on the receipt as to whether it qualifies for the offer. Once that has been determined, the item's amount is included in the qualified_item_total_amount tabulation which uses the discount_item_amount*quantity.

Whether the item is qualified depends on the fields:

• SKU Excluded
• SKU Included
• Tags Included
• Tags Excluded

Rules of overlapping settings:

• If an item is excluded by SKU or by Tag it will automatically be excluded (regardless if it is also included through a tag or a sku)
• If there are no inclusions and no exclusions set, every item will qualify by default
• If there are only inclusions set, the item must be part of at least one of the inclusion sets to qualify
• If there are only exclusions set, the item musn't be part of any of the exclusion sets to qualify
• If there are both inclusions and exclusions set, the item must be part of the inclusion set AND not be part of the exclusion set
• Inclusion sets have an "OR" relationship. An item only needs to be part of one inclusion set to qualify

Note, the paid amount for each item goes towards the amount threshold of the offer after it goes through this decision tree and is deemed as qualified. Having an unqualified item in your order does not disqualify the transaction as a whole.

Other Qualification Assessments

• Dates: The date of the purchase must fall within the start and expiration dates of the offer (inclusive)
• Repeat Amount: If there is a repeat amount set, an offer redemption will return as unqualified if all of the instances of the offer have already been redeemed.
• Order Type: The purchase must be made using a declared order type such as web or in_store or both.
• Amount Threshold: The total purchase of qualified items must clear the amount threshold
• Activation Required: The activation of the card or account must happen before the purchase timestamp in UTC

Handling Split Payments/Tenders

There are times, whether the purchase is made in store or online, where multiple payment types are used. Whether this is among many cards, gift cards, or with cash, there may be a desire to only have the user qualify and redeem an offer if the payment that has the offer activation has passed all of the criteria. In other scenarios, the reward is fulfilled based on the amount authorized across all payment types.

If using the Banyan API to set up your offer, this configuration is called prorate_qualified_spend. If prorate_qualified_spend is set to TRUE, then only the activated account or card will be what is considered when assessing the minimum spend or other offer criteria. If prorate_qualified_spend is set to FALSE, all payments will be considered in the assessment.

If using the UI to set up your offer, this configuration is pictured below:

The toggle of "prorate qualify spend" has options of Yes or No which correspond to the definitions described above as TRUE and FALSE respectively.

Wallet/Virtual Cards

When a customer uses an apple/google wallet or paypal to pay for a purchase, their card last four is no longer exposed to the merchant. It is a tokenized value that will not match the true card PAN. While this may not impact matching for Banyan, as all other elements are still passed through without issue, it does change how Banyan can do offer adjudication.

Activated Offers

If an offer requires activation, we would have to have the virtual card last four as part of the activation in order to recognize the user's purchase as viable for a specific offer. This isn't typically something the CLO provider can get, so Banyan's recommendation is to make all activated offers ineligible for wallet/virtual card transactions.

Always On Offers

If an offer is always on, Banyan will count fulfillment limits separately for virtual card last four vs the physical card last four. This potentially means that a user can get offers redeemed more than the merchant expected.