The transaction types listed below are required for certification.

Gift/Stored Value

• Balance Checking – Search API call to Clutch for real-time balance information.
• Sell New Physical gift card – Real-time call to Clutch to Allocate and updateBalance of “new” gift card.
• Redeem gift card – updateBalance call to Clutch with full purchase amount.  Clutch will return amount due if balance is not sufficient to cover requested redemption amount.
• Void – use Void API request in the case an immediate reversal of issuance or redemption is required.
• Merchandise Credit issuance – the ability to tender a return to a stored value card.  This will use the same API methods as issuance, but will typically be issued to separate physical card design (card set) and will not require payment for issuance by POS.
• Data input – the ability to ingest card number via mag stripe swipe, barcode scan or manual entry of a card number.
• Gift/Stored value cards are applied as a tender type payment.

Loyalty

• Enrollment – the ability to enroll using either a Physical loyalty card (data input required) or by allocating a virtual loyalty card from a specified card set id.  The ability to enroll during a transaction should be considered as well as “stand-alone” enrollment outside of the transaction flow.  A search should first be performed specifying the Loyalty card set in the return fields.  If the customer is not found, card should be allocated and updated with countAsEnrollment flag set to = true.  If customer IS found, and customer has not been previously enrolled,  updateAccount should be called to set enrollment flag to = true.
• All transactions to Clutch (loyalty member/non-member/anonymous) via Checkout API should be sent to Clutch.  Loyalty card id will be sent with all identified transactions, and no card number will be included for the anonymous transactions.
• Loyalty Earning – this is done via Checkout API  which runs the member card id through our Campaign Manager.  Response will return result of any eligible points earning.  Results may include Balances available (points, cashback, custom values, currency or discount). Two stage checkout should be used if campaign rules employ SKU based discounts.  Integrations should be able to support both checkout types depending on brand preference and campaign configuration.
  • Single-stage checkout – can be used for points accrual and the redemption of Value types (USD, cashback, coffee, t-shirt, reward, etc.)  The balance may equal product type or be cash equivalent. Can also be used to provide anonymous transaction activity to record a purchase.
  • Two-stage checkout – required for any SKU based or discount based campaign configuration.  Clutch manages discount logic and will return balance mutations to be applied in the check. This provides real-time feedback in the case of discounts or rewards being earned as a result of the items being purchased.  (example:  spend 100 on SKU category A and receive a 20% discount on the total purchase)
• Loyalty Redemption – Your integration must support the ability to redeem one or more reward type in a given transaction.  Rewards that are not currency-based should be applied as a ticket or line-item discount and NOT as a tender type. See PaymentMethods for additional information on the best way to redeem during a Checkout API call.
• Balance Checking – call Search to obtain all available balances
• Return Handling – Return API – should be used to handle returns according to the brand return policy.
• Void – use Void API request in the case an immediate reversal of Checkout,  issuance or redemption is required.

Upon code completion of the above functionality, the next step will be to run through the Clutch test scripts and provide your results to our team to be reviewed.