Personalized Dining Deals

Click “Copy Page” to copy this use case as markdown.

Problem

Cashback deal catalogs often include restaurant offers, but without knowing which restaurants a user actually visits, every deal is a guess. Generic promotions compete for attention and frequently go ignored because they don’t feel relevant. Users who regularly order through delivery platforms have strong restaurant preferences, but that signal is not available to the issuer’s app.

Solution

Use SKU-level transaction data retrieved from linked delivery platform accounts via the Sync Transactions endpoint accounts to identify which restaurants a user already frequents. When a cashback deal becomes available at one of those restaurants, surface it proactively to a segment of users, personalized with the user’s actual order history.

In-app deal card showing a personalized cashback offer at a restaurant the user has ordered from recently, with recent menu items listed

This turns a generic deal catalog into a targeted, high-relevance experience, increasing deal activation rates by matching offers to established habits rather than broadcasting to everyone.

Flow

Implementation

Sync transactions and build restaurant preferences

When a user switches their card at a delivery platform or they simply link their merchant account w/o switching their card, Knot begins collecting transaction data for that account. Listen for the NEW_TRANSACTIONS_AVAILABLE webhook event, then call Sync Transactions to sync SKU-level transactions on a daily basis. For each delivery platform transaction, read products[].seller.name to identify the restaurant.Key fields

Field	Purpose
`products[].seller.name`	Restaurant name (e.g., “Domino’s”) extracted from a delivery platform order.
`products[].seller.url`	Restaurant URL for matching against deal catalog entries.
`products[].name`	Menu item names for personalizing the deal notification.
`products[].image_url`	Product image to display on the deal card.
`merchant.id`	Identifies the delivery platform.
`merchant.name`	Delivery platform display name (e.g., “DoorDash”).
`datetime`	Purchase timestamp for recency filtering.
`external_user_id`	Identifies the user in your system.
`order_status`	Filter to completed orders only.

Only include transactions with order_status of COMPLETED, DELIVERED, PICKED_UP, SHIPPED, BILLED, or ORDERED. Filter out CANCELLED, REFUNDED, and FAILED.Store restaurant-level preference data per user. For each transaction, increment order count and last-order timestamp for the restaurant.

FOR each transaction in sync response:
    IF merchant is a delivery platform:
        FOR each product in transaction.products:
            restaurant = product.seller.name
            user_preferences[external_user_id][restaurant].order_count += 1
            user_preferences[external_user_id][restaurant].last_order = transaction.datetime
            user_preferences[external_user_id][restaurant].recent_items.append(product.name)

Match deals to user preferences

When a new deal is added to your deals catalog for a restaurant, query your preference store for users who have ordered from that restaurant recently.

FOR each user with deal.restaurant in their preference data:
    pref = user_preferences[user_id][deal.restaurant]
    IF pref.order_count >= MIN_ORDER_COUNT
       AND pref.last_order >= today - RECENCY_WINDOW_DAYS:
        queue personalized notification for this user

Configuration decisions for your team:

Parameter	Suggested Default	Considerations
`MIN_ORDER_COUNT`	2 orders	Lower thresholds may include one-time visitors. 2+ orders signals a genuine preference.
`RECENCY_WINDOW_DAYS`	90 days	Orders from over 90 days ago may no longer reflect active habits. Adjust based on your user base’s ordering frequency.
Max items shown in notification	3	Enough to feel personalized without overwhelming the message.

Notify the user and surface the deal

Send a push notification and surface a deal card in the issuer’s app deals or offers section.

Push notification and in-app deal card showing a personalized cashback offer at a restaurant the user has ordered from recently

Populate the deal card with the user’s most recent products[].name values for that restaurant, limited to 3 items. If products[].image_url is available, use it as the image for each product in the list.

Expansion Path

Historical preference scan: On initial account link, scan historical transactions to immediately identify restaurants the user already frequents. Users get a relevant deal the first time they open the offers section rather than waiting for new orders to accumulate.
Grocery and convenience expansion: Apply the same logic to grocery delivery merchants. products[].seller.name identifies the specific store brand or product type, enabling matched deals on grocery staples, household items, and beverages.
Frequency tiers: Segment users by order frequency (2-4 orders vs. 5+ orders) and surface different deal messaging. Frequent visitors may respond better to a loyalty-framed offer (“Your go-to Domino’s”). Less frequent visitors may respond better to a discovery-framed offer (“You’ve ordered here before, here’s a deal to come back”).

General

SDK

CardSwitcher

SubscriptionManager

TransactionLink

Detect

Vaulting

Shopping

Merchant Account Linking

Personalized Dining Deals

Problem

Solution

Flow

Implementation

Sync transactions and build restaurant preferences

Match deals to user preferences

Notify the user and surface the deal

Expansion Path

​Problem

​Solution

​Flow

​Implementation

Sync transactions and build restaurant preferences

Match deals to user preferences

Notify the user and surface the deal

​Expansion Path

Problem

Solution

Flow

Implementation

Expansion Path