Getting Started

Create and manage your card-linked rewards program with the provided guides and API documentation.

Quickstart

To simplify the onboarding process, use this quickstart guide as a high-level overview of what to expect in the Kard integration. 

For details on functionality or technical specs, refer to the Product Guides and API documentation respectively.

Call the Kard API

To access the Kard API

  1. Request sandbox access.
  2. Kard will provide you a clientID and clientSecret.
  3. For each session, call the Kard Authentication endpoint
  4. Once granted a session token, you can call the API as needed.

Standard Implementation

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.

Cardholders

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.

Relevant Kard API Endpoint(s) 

  1. Create User
  2. Delete User
  3. Update User
  4. Create User Card

Merchant Offers

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.

Relevant Kard API Endpoint(s) 

  1. Get Rewards Merchant (Card Linked Offers)
  2. Get Rewards Offers (Card Linked Offers)
  3. Get Affiliate Offers (Affiliate Offers)

Transaction CLO Matching

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.

Relevant Kard API Endpoint(s) 

  1. Incoming Transaction
  2. Earned Reward Webhook

Transaction Lifecycle 

The three primary patterns used to send transactions to Kard for matching processing are:

  1. Dual Message
  2. Single Message
  3. One Authorization to Many Settlements

 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.

  1. Temporary Transaction Event: APPROVED
  2. Final Transaction Event: SETTLED, REVERSED, DECLINED, RETURNED (special case where the originating, temporary transaction ID is not readily associated)

Code recipe for temporary transaction event. Note that for temporary transaction events, “status: APPROVED” and there is an authorizationDate timestamp.

{
 "transactionId": "sandbox-web-303",
 "referringPartnerUserId": "438103",
 "cardBIN": "123456",
 "cardLastFour": "4321",
 "amount": 10000,
 "currency": "USD",
 "description": "Hilltop BBQ",
 "status": "APPROVED",
 "authorizationDate": "2022-10-29T17:48:06.135Z"
}