Create and manage your card-linked rewards program with the provided guides and API documentation.
To simplify the onboarding process, use this quickstart guide as a high-level overview of what to expect in the Kard integration.
To access the Kard API
The Kard integration consists of three main areas of functionality, Cardholders, Merchant Offers, and, Transaction CLO Matching. Below, we will cover the basics of these three sections and the implementation steps.
The Cardholders domain tracks all end users that are opted into your rewards program. Kard does not require any PII, but does need a User ID, User Name, Card BIN and Last 4 to accurately match and attribute valid reward opportunities to your cardholders.
Kard provides the endpoints required to view and filter on valid merchant offers for your cardholders. We work with a number of merchants to provide a large ecosystem and variety of offers to provide cardholders with the optimal reward experience via National and Local Card Linked Offers, as well as Affiliate deals.
Kard’s Transaction CLO Matching functionality allows the platform to ingest all issuer transactions and automatically identify redeemable card-linked offers (CLOs) for reward program cardholders in near real-time. The multi-tiered matching algorithm is built to constantly increase its dataset of known transactional data. The ideal end user experience that Kard provides is a cardholder being notified of a reward within a minute of completing a purchase.
Our recommendation is to provide all consumer transactions via the Kard API. Batch is possible, if needed, and please contact a Kard account manager to discuss further.
The three primary patterns used to send transactions to Kard for matching processing are:
The following are descriptions and code recipes for each pattern.
I. Dual Message
The most common pattern used to transmit transactions is the Dual Message system, also known as a Signature Debit transaction. Using this system, a transaction is submitted in 2 events. The first, originating event is a temporary transaction state followed by a second event that is a final, clearing transaction state.
"description": "Hilltop BBQ",