Getting Started
Welcome to the Kard API Getting Started guide. This resource will walk you through recommended integration patterns and recommended user experiences to quickly jump start your rewards program through Kard. Whether you are making your first API call, testing parts of your integration or preparing for your pre-production credentials call, this guide will help you get started.
Note, this guide will use the most up to date API definitions. Incoming Transactions API, Rewards APIs and notifications webhooks will reference the 2024-10-01 version and the remaining APIs will reference the legacy definitions.
If you use Marqeta to process your transactions than you can see additional details below to help you set up your integration.
Authenticating with the API
Kard uses OAuth 2.0 credentials for authentication. Read here to learn more about how to connect.
Use our Postman API to test your connection
Postman Collection Coming Soon!
Recommended Integration Patterns
User Management
Kard supports two different patterns for getting users into your system. The card issuer pattern where you add users who you have provisioned a card to, and the aggregator pattern where you collect multiple cards not issued by you. If you use both patterns than you will be given two different environments. One for your self-issued cards, and one for your aggregated cards.
Card Issuer Pattern
Aggregator Pattern
If your application supports cards issued by your program manager transactions will originate from known cardBINs and networks so a user can be created with or without card-level information. If creating without the cardInfo object, the user can later be updated.
Code Recipe:
Creating a User:
- required: userName OR email, referringPartnerUserId, zipCode
Add cardInfo to User:
- cardInfo[“issuer”]: Program Name as known to Kard, rather than the underlying Card Issuer
- required: referringPartnerUserId, cardInfo
Targeted Offers
Each sandbox environment is configured with the following user personas:
sandbox-{issuerName}-new-customer
: this user has no record of prior transactions at the merchant.sandbox-{issuerName}-lapsed-customer
: this user has prior transaction history at the merchant, but none within the last 6 months.
These personas demonstrate targeting functionality in terms of offer discovery (the user is viewing a personalized
offer) and transaction matching (the user transaction matches to the personalized offer). The {issuerName}
variable is provided in the sandbox environment.json.
Transaction CLO Matching
There are three common patterns for transmitting transactions.
- The Dual Message pattern - one authorized transaction followed by a settled transaction.
- The Single Message pattern - one single settled transaction
- The Multiple Message pattern - one authorized transaction, and then multiple settled transactions. Example: one purchase is authorized, but multiple products are shipped from different distributors that settle their portion of the bill separately.
Dual Message Pattern
The most common pattern used to transmit transactionsis the Dual Message system, also known as a Signature transactions. 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. You may handle transactions in other ways. If so, please see the other options that we support below.
In order to accurately match incoming transactions, specific fields must be provided which can be found here.
To properly ingest a matched transaction earned reward notification webhook, check out the section on HMAC Signature Verification.
The following describes the Dual Message system, also known as a Signature transactions. 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.
- Temporary Transaction Event: APPROVED
- Final Transaction Event: SETTLED, REVERSED, DECLINED, RETURNED*
*special case where the originating, temporary transaction ID is not readily identifiable
Code Recipe: Cleared, Signature Transaction
Temporary transaction event:
- status: APPROVED
- authorizationDate timestamp
Final transaction event:
- status: SETTLED
- authorizationDate timestamp
- settledDate timestamp
- identical transactionId as the originating APPROVED event
Code Recipe: Reversed, Signature Transaction
Sending Reversal infomration enables the platform’s Transaction Monitoring, where Kard conducts internal fraud detection to identify suspicious behavior through abnormal transaction amounts and high volume transactions or returns per user on a daily basis. We then notify Issuers of any potential fraud to be investigated if it is found.
Temporary transaction event:
- status: APPROVED
- authorizationDate timestamp
Final transaction event:
- status: REVERSED
- transactionDate timestamp
- identical transactionId as the originating APPROVED event
Single Message Pattern
The Single Message system is also known as a PIN debit transaction. In these transactions, the user is required to enter a PIN. The PIN is validated in real-time by the bank, so a transaction submitted as a single message will be a final transaction event and the authorization and settlement dates are effectively the same.
In order to accurately match incoming transactions, specific fields must be provided which can be found here.
To properly ingest a matched transaction earned reward notification webhook, check out the section on HMAC Signature Verification.
Code Recipe: Clearing, PIN debit Transaction
- status: SETTLED
- authorizationDate timestamp
- settledDate timestamp
Multiple Message Pattern
This pattern is one where a single authorization is followed by multiple settlement events. This pattern is generally seen when a single transaction represents multiple objects.
For example, imagine using an e-commerce site and checking out a cart with multiple items. If these items are shipped individually, there may be multiple, subsequent settlement events.
In order to accurately match incoming transactions, specific fields must be provided which can be found here.
To properly ingest a matched transaction earned reward notification webhook, check out the section on HMAC Signature Verification.
Code Recipe: Single Auth, Multiple Settlements Transaction
- identical referringPartnerUserId for all events
- identical transactionId for all events
- different settledDate timestamps for each SETTLED event
Temporary transaction event: (1 of 1)
- status: APPROVED
- authorizationDate timestamp (“2022-10-29T17:48:06.135Z”)
- $100 transaction amount
Final transaction event: (1 of 2)
- status: SETTLED
- authorization timestamp (“2022-10-30T17:48:06.135Z”)
- settledDate timestamp (“2022-10-30T18:48:06.135Z”)
- $75 transaction amount
Final transaction event: (2 of 2)
- status: SETTLED
- authorizationDate timestamp (“2022-10-30T17:48:06.135Z”)
- settledDate timestamp (“2022-10-31T18:48:06.135Z”)
- $25 transaction amount
Transaction Reconciliation
There are two standard reconciliation reports that Kard issues: Daily files and end of month (EOM) files. Both of these files can be retrieved using the GET Files endpoint.
Daily Reconciliation File
At the end of each day, a daily reconciliation file of transactions is automatically generated and available via the endpoint. This file will be ideal for your team to compare against received earned reward approved and settled notification webhooks and will act as a ledger until the EOM file is generated.
- The file is generated at 4:30 am EST. This is midnight UTC, so it’ll shift by an hour when we enter Daylight Savings Time.
- file naming convention:
cardlinked-reconciliation-YYMMDD
- file format:
.json
Code recipe
GET
Files EndpointorganizationId
path param: the organization id given to you by the Kard Team.fileType
query param:dailyReconciliationFile
Use the attributes.downloadUrl
field in the returned response to access your daily
reconciliation files.
EOM Reconciliation File
On the 15th (or following business day in case the 15th should fall on a weekend or a holiday) each month, a monthly
reconciliation file will be available via the endpoint. The EOM reconciliation report contains only SETTLED
transactions that occurred in the previous month both PAID_IN_FULL
and PENDING
, as well as all PENDING
transactions from all previous months that still have yet to be paid, and PAID_IN_FULL
transactions from previous
months that are being paid out that month.
- file naming convention:
cardlinked-reconciliation-YYMM
- file format:
.csv
Code recipe
GET
Files EndpointorganizationId
path param: the organization id given to you by the Kard Team.fileType
query param:monthlyReconciliationFile
Use the attributes.downloadUrl
field in the returned response to access your monthly
reconciliation files.
Payouts
- Merchants: Merchant terms are generally Net 30 across our merchant partners, but payment can be up to Net 90.
- Issuers: the product supports the 2 following options for payouts to end users.
- Immediate
- Issuers may opt to disburse payments to their end-users immediately, or shortly after a transaction occurs. By selecting this option, the issuer agrees to front the payment amounts to the end-users. Kard will reimburse the issuer for these payments once Kard receives the corresponding commissions from the Merchants.
- Withheld
- Alternatively, issuers may choose to withhold payments to their end-users until such time as they have received the corresponding commission payments from Kard. This option allows issuers to avoid fronting the payment amounts.
- Immediate
Testing The User Experiences
A. Discover a New Customer CLO
GET
Get Offers By User EndpointorganizationId
path param: the organization id given to you by the Kard Team.userId
path param:sandbox-{issuerName}-new-customer
B. Discover a Lapsed Customer CLO
GET
Get Offers By User EndpointorganizationId
path param: the organization id given to you by the Kard Team.userId
path param:sandbox-{issuerName}-lapsed-customer
C. Discover CLOs Near You (Map View)
GET
Get Locations By User EndpointorganizationId
path param: the organization id given to you by the Kard Team.userId
path param:sandbox-{issuerName}-new-customer
- query params:
longitude=-73.9930148
latitude=40.74201480000001
D. Trigger Earned Reward Notification
The following steps provide a demo experience from the perspective of the sandbox-{issuerName}-new-customer
user.
- Discover Eligible New Customer Offers
GET
Get Offers By User Endpoint
- Submit Eligible Approved Transaction
POST
Incoming Transactions Endpoint- Map Rewards offer
attributes.name
to Incoming Transactiondescription
- Ingest Earned Reward Approved Notification Webhook
POST
Notifications Webhook- Authenticate webhook using HMAC Signature Verification
- Delight your user with a notification!
- Use attributes.message to serve the push notification:
- Use attributes.message to serve the push notification:
- Submit Eligible Settled Transaction
POST
Incoming Transactions Endpoint- Map Rewards offer
attributes.name
to Incoming Transactiondescription
- Ingest Earned Reward Settled Notification Webhook
POST
Notifications Webhook- Authenticate webhook using HMAC Signature Verification
- Delight your user with a rewards confirmation notification!
- Use
attributes.message
to serve the push notification:
- Use
E. Track User Attributions
For issuers using event tracking via images on the eligibility endpoints:
- To test that attribution is flowing to Kard, please load the asset urls from the endpoint or webhook you would
like to test. We recommend sending both the
IMPRESSION
event and theVIEW
event and medium, while testing in sandbox. Once you are finished with testing, please provide theeventCode
,medium
and the id of the resource related to the asset url, to your AM/solutions architect so that the team can validate. - If an invalid query
eventCode
ormedium
is supplied the image will return a 400 error with a description of the issue. It is important to note in production image delivery is prioritized so errors will not be returned in production.
For issuers using event tracking via attribution API endpoint:
- To test that attribution is flowing to Kard, please send requests to the endpoint defined above in your sandbox
environment. We recommend sending both the
IMPRESSION
event and theVIEW
event and medium, while testing in sandbox. Once you receive a response code, please notify your AM and solutions architect to verify that events were correctly posted to Kard. Please provide theeventCode
,medium
andtypeID
so that the team can validate.
During the pre-production call, you will be asked to show the end-to-end user flow, and asked to simulate both
an IMPRESSION
event and VIEW
event by navigating your UX experience. For more information see
Attributions.
User Acceptance Test Cases
As a user, I should be able to successfully:
- Enroll in the rewards program.
- Unenroll from the rewards program.
- Add a card to my profile.
- View a list of eligible ONLINE rewards.
- Submit attribution data points for impressions and views
- View a list of eligible INSTORE rewards.
- Submit attribution data points for impressions and views
- View a list of eligible rewards near me.
- Submit attribution data points for impressions and views
- View Offer Details.
- Submit attribution data points for impressions and views
- Submit a Clearing, Dual Message Transaction.
- Submit an APPROVED(aka AUTH) event to the Incoming Transactions Endpoint
- Submit a SETTLED (aka CLEARED) event to the Incoming Transactions Endpoint
- Submit a Declined, Dual Message Transaction.
- Submit an APPROVED(aka AUTH) event to the Incoming Transactions Endpoint
- Submit a DECLINED event to the Incoming Transactions Endpoint
- Submit a Reversed, Dual Message Transaction.
- Submit an APPROVED(aka AUTH) event to the Incoming Transactions Endpoint
- Submit a REVERSED (aka CLEARED) event to the Incoming Transactions Endpoint
- Submit a Single Message, PIN-debit Transaction.
- Submit a SETTLED (aka CLEARED) event to the Incoming Transactions Endpoint
- Submit a Refund Transaction.
- Submit a RETURNED event to the Incoming Transactions Endpoint
- Receive an Earned Reward Approved Webhook push notification
- Submit attribution data points for impressions and views
- Receive an Earned Reward Settled Webhook push notification
- Submit attribution data points for impressions and views
As a rewards program manager, I should be able to successfully:
- Consume recon files.
- Daily
- Monthly
- Create an Audit Request.
- Get an Audit Request Status.
Marqeta Integrations
Marqeta has it’s own user and transaction management systems. If you are using these to power your platform you can integrate those flows directly with Kard rather than writing custom integrations.
Some key differences in terminology are outlined below, and you can find out more here.
Transactions
Transaction Status Mapping
Kard currently receives the following transaction event types from Marqeta:
Note: The data mapping for the transaction events below also apply to Kard’s Earned Rewards Webhook.
FIPS
FIPS State Abbreviation mappings FIPS codes are numbers which uniquely identify geographic areas