Ecommerce Stored Value Functionality – Best Practices

Within the Clutch platform, “stored value” is used by clients in a variety of ways including:

• Gift Cards – buying and selling of physical and virtual gift cards.
• Promo Cards or “Promotional Gifting” – these are often used as acquisition tools for brands who may want to issue “Free $5” Promo Cards.
• Merchandise Credit – used to give store credit to customers making returns, etc.

While we often use the term “gift”, it’s important to understand that functionally the different uses of gift and stored value all leverage the same technical integration.

**Please note that the following symbols used throughout our site call out the Required and Best Practice recommendations outlined in the Certification checklist:

Denotes required

Calls out Best Practice and recommended practice

Gift Card Data Interaction

Selling and Redeeming Gift cards is an integral part of ecommerce functionality. One of the key factors making the Clutch gift card experience best in class is that customers are able to both buy and redeem gift cards through any of the purchase channels a brand is employing, including in-store and online. This means that cards bought in store can be redeemed online and those purchased online can also be redeemed in store.

The three main areas we will outline in relation to gift and stored value are:

1. Selling Gift Cards
2. Redeeming Gift and Stored Value
3. Checking Card Balances

Selling Gift Cards (Issuance)

Including the ability to sell (or having end customers buy) gift cards on your site is relatively straightforward. In general terms it works like this:

• You create specific gift card products in the merchant’s inventory.
• These product IDs are stored in the Clutch client portal.
• At checkout time (for virtual cards), you allocate the gift card and issue the appropriate balance.
• When the transaction is passed to Clutch, we will not included it as a qualifying purchase for earning loyalty rewards.

With this in mind, there is a specific consideration to answer before beginning your implementation. This is:

• Are you selling only electronic/virtual gift cards, or physical as well?

Selling Only Virtual/Electronic Cards

Once the option for the purchase of a Virtual gift card has been chosen and the customer is proceeding to checkout, there are several things that take place via API. The timing of these calls can vary slightly depending on the implementation, but the order should remain the same.

Allocation (activation)

 

Steps to allocate a new virtual card:

• The “allocation” call is made with a specific card set id identified. This ensures that the card is sourced from the correct pool of inventory cards. Clutch support will provide a cardSetId with brand credentials when setting up a brand for integration. (example card set id: “BrandVirtualGift”)
• updateAccount follows allocation – this allows information such as Name and Email that are associated with the gift card recipient to be stored in the Clutch platform. At this point, the card is activated and holds demographics, but does not yet hold value. This is where the decision comes as to timing of calls.
• updateBalance is called to add value to the card. This is typically done following the Capture of payment. Keep in mind that Auth and Capture of credit card payment at time of purchase is crucial unless delivery of the card will be delayed until after payment capture occurs. If preferred, all three calls can be made following payment capture in sequence, or you can allocate a card from inventory, updateAccount and follow later with updateBalance call being made post-payment capture.
• Additional updateAccount calls can be performed at a later time if necessary to record an event, update demographics or change status of the card if necessary.

The information required when allocating a new card is as follows:

• Amount
• Giver Name
• Giver email
• Recipient Name
• Recipient email (Possibly using verification by entering twice and confirming match)
• Date of Delivery (if eComm platform can support delayed delivery of virtual cards – may require customization and is not driven by Clutch API’s)*

Selling Both Virtual/Electronic Cards & Physical

If your merchant chooses to sell both virtual and physical cards there are a few additional considerations:

1. You will need to provide a front end page for customers to choose which type of card they wish to buy (see examples in the front end section of this document).
2. You will need to understand who is fulfilling the physical gift card.

It is important to note that with Physical card purchase, there are no API calls made to Clutch for Allocation or updateBalance at the time of the sale by the storefront. This purchase should flow through the system in similar fashion to any other item purchased on the site. At the fulfillment site, it will be necessary to load value and fulfill/ship the physical card via Clutch Virtual terminal or integrated Order Management System (OMS).

The required information for a physical card fulfillment that you will need to collect includes:

• Amount
• Card design (if more than one choice available)
• Custom message to be included (if brand can accommodate on the fulfillment side)
• Recipient information (if different from purchaser)*
• Recipient Address (if split/drop shipping is supported)*

*indicates brand business decision

---

Additional Considerations

Please note that thoughtful consideration should be given to the gift card denominations to be sold. Physical gift cards may be available in a wider range of denominations with a higher maximum value, while Virtual may be limited to a more narrow range due to the element of risk involved with immediate delivery to a recipient. Once a virtual gift card is delivered, it is available for immediate redemption by the recipient. Clutch recommends limiting the maximum card value sold to closely match the average ticket amount if at all possible. In addition, it is highly recommended that the ability to hold gift card orders for manual review is implemented. Fraud control security measures should be employed to allow delay of delivery for Virtual cards if any irregularities are suspected.

---

Redeeming Gift Cards

 Now that you understand how selling gift cards should work on your platform, the next step is redemption.

When it comes to gift card redemption methods may vary depending on the systems in play within the brand infrastructure. A specific consideration Order Management Systems, Accounting systems, etc. may affect the flow of redemption. In most systems, payment by Gift card or stored value instrument is considered and accounted for as a payment type, not a discount. An exception to this rule could include the redemption of a promotional gift card, which a brand may prefer to have applied as an order level discount. It is important to consider these use cases when deferred accounting methods are used, to make sure the redemption of the gift card releases any deferred revenue.

There are two main API flows that will be covered here. They include single step redemption and two step redemption. Clutch recommends that if an ecommerce integration is intended to be rapidly deployable for use with multiple brands, it is advised that both of these methods are available for use. The credit card capture method often dictates their gift card redemption flow.

Why use single vs two-step redemption:

• Single step redemption is redemption on a card that happens immediately, usually initiated directly from the storefront during checkout. It is done using an updateBalance call to Clutch and will remove funds equal to the greatest amount available to satisfy the order balance in full if at all possible. If necessary, additional tender may be collected if the available balance does not satisfy the order total. If using this method, it is likely that credit card payment ALSO uses the Auth/Capture method via storefront at time of purchase. If a credit card is only authorized by the storefront and capture is done via a separate system, it is recommended that gift card redemption follow that same logic if possible (see two-step redemption).
• Two Step Redemption also known as using “Holds” is the most common redemption method employed. Many brands prefer two step redemption as it aligns well with their credit card capture methods. Using this method, it is common for redemption to be initiated by the storefront by placing a “hold” on the balance being redeemed. The order will then flow through normal channels (ERP, OMS) and the hold is redeemed by that second system once payment is captured and the item is shipped. **It is important to note that holds are unlike credit card authorization, which may automatically “fall off” after a period of time if order is not completed. A balance in Hold status must be removed either by completing the redemption with a hold redemption or releasing the hold to restore the balance amount.

Redemption use cases include the following examples – brands may define additional edge cases to be considered:

• Redemption in full via gift card – no split tender required, Card balance is exhausted.
• Partial redemption of gift card, Full amount of sale is covered, but balance retained on card. Customer retains card for future use.
• Split tender required. Total purchase exceeds balance of gift card and additional payment form required. Check cannot be closed until additional payment accepted. Clutch will return NSF (insufficient funds) message in updateBalance response
• Multiple gift cards used for a single purchase

1 Step Redemption: Auth & Capture

No Clutch holds will be utilized for this transaction as the funds are captured at time of purchase by the front end system (store front).

2 Step Redemption: Using Holds

• Purchase on website initiates placement of hold (auth) by front end system (store front).
• Order transmitted through order management/alternate systems
• Order fulfillment process completed, system initiates hold redemption to capture funds.

**If fulfillment process is not completed for some reason, then a hold release must be initiated to restore the funds to a customer card. Holds will not expire

---

Clutch best practice dictates that PIN Validation always be employed during checkout and redemption of a Stored value card. Front-end logic may need to be used to do initial card number logic check if legacy cards that do not have PINS are to be entered for redemption on site. For example, if legacy cards are 12 digits/alphanumeric, it is possible to discern that PIN will NOT be available for validation and therefore a PIN field not exposed. If card has Clutch generated data format, PIN would be required for redemption.   Gift/Stored value cards produced by Clutch will have PIN number printed on card. Scratch off panel over top of PIN is also recommended for greater security.

---

Checking Card Balances

Check Card balance – call to Clutch for real-time balance information. Balance checker should always include PIN validation and Captcha for security purposes.

Example of Balance checker UI with PIN/Captcha:

Providing a balance check page is a key feature. The URL for this page is typically printed on the back of physical cards and provides a way for customers to see how many funds they currently have on a given card.

It is extremely important to have both PIN and captcha on this page to combat those who wish to programmatically try to defraud your gift card offering. These people may write bots to systematically run through huge ranges of card numbers looking for valid cards.

Other Gift Card Management Needs

Voids/Adjustments (Post void and during sale)

If using one-step redemption and payment via CC fails as second form of payment, the redemption of the gift card will need to voided if the transaction is not completed. Further use cases can be discussed if necessary with your Clutch integration support team as brand needs are revealed.

Attaching Demographics to Gift cards

It may be important for a brand to attach and store demographics to a gift card in the Clutch platform. These can later be used for gift card escheatment purposes or researching lost/stolen cards.   Clutch welcomes this data and encourages the ability to send the following information when activating a gift card. For Physical gift card sales, this would typically be the “purchaser” information, but some brands do request the intended recipient name and record that as well. Clutch does have a concept of Primary and Alternate demographic sets and more information on that is contained in our API documentation.

• First Name
• Last Name
• Email Address

Account Adjustments and Status changes

In the event a card is lost or stolen, it may become necessary for a customer service team to perform administrative adjustments on both the card balance and the card status.

This would normally be performed using either OMS tools or site back-end admin tools. API calls from the source to Clutch would include updateBalance with the Is adjustment flag set to true in addition to updateAccount call to change the card status to Suspended. Once completed, a new card can be issued to the consumer as brand policy dictates.

Merchandise Credit Data Interaction

Merchandise Credit – How is it different from gift cards?

With the exception of the restaurant world, most brands will regularly receive returns on their product. Clutch recommends issuing credit in the form of stored value whenever possible to help the brand keep the customer coming back to spend that credit.

This issuance will differ slightly from the issuance of a Gift card in the ecommerce flow. Depending on how returns are initiated and processed by the brand, there may be the need to issue a virtual merchandise credit via either OMS integration, site back-end admin or the Clutch Virtual terminal. In addition, it may be necessary to email the consumer with the card number and PIN of the Merchandise credit “card”.

A separate virtual card set may also be used for allocation by the system in place to administer Merchandise credits.

Billing & Checkout

Changes to the billing and checkout pages include providing a spot where customers can enter the stored value card number and PIN and have that applied as payment method.  You will want to consider storing the RequestRef (transaction id) that is provide in the Clutch API response as it will be needed for any future voids or hold redemption if using  the two step redemption method outlined above.  Clutch also recommends sending the Order id via API in the standard header of the API call to allow us to record and store the order id for future reference as it creates a tie between the Clutch transaction and the Ecommerce transaction.