​
Overview

Before starting integration, it’s important to understand Spade’s approach to enrichment and key concepts for successful implementation. Spade takes a unique approach to card transaction enrichment. We have built data partnerships with a variety of providers, including players in the payments value chain, first-party merchants, location data providers, state registry databases, and more. When we receive transaction data from you, we match it to a real merchant entity in our database — returning granular merchant information including clean name, custom category, geo-location, and more in less than 50ms.

​
Example transaction

The best way to understand the value of our enriched data is to walk through an example transaction. Below you’ll a see a sample transaction with the information provided to Spade in the enrichment request, the data returned, and an example of how you might display that in your UI:

​
Spade “Matching”

When we match a transaction to a real merchant identity in our database, we will return a variety of data on all parties involved. Typically, with a proper implementation you will see match rates of at least 95%. Even when we don’t match on a merchant, we will still clean the merchant name, sort the data (e.g., move a phone number from the city to phone number field), and provide a category.

​
Core Data Enrichment

Our foundational layer of factual transaction including factual details like merchant name, logo, category, counterparty ID, and location – delivered in real time and designed for consistency across rails.

​
Counterparties and Third Parties

When we match on a transaction, we will separate the parties involved into counterparties and third parties objects:

Counterparties

The entity you interact with directly when you make a purchase (in most cases a merchant). We’ll return the following information:
  • counterparty ID
  • name
  • logo
  • website
  • location
  • and more
In our example transaction, the counterparty is Walmart.

Third parties

Any entity besides the counterparty involved in a transaction, e.g., a payment processor, delivery service, or BNPL provider. We’ll return the following information:
  • third party ID
  • type
  • name
  • logo
In our example transaction, the third party is Square, a payment processor.
Counterparty IDs Our counterparty ID is a unified identifier for a brand — for example, every Walmart location shares a single Spade counterparty ID (vs. >40,000 merchant IDs coming through the networks). Counterparty IDs should be used as your core identifier of a merchant, as they will stay consistent even through events like a rebrand. These IDs are critical for high value use cases such as card locking, fraud prevention, rewards attribution, and more. They can be accessed via our Merchant search tool ahead of enrichment time as well as via the enrichment APIs on a transaction level. Third Party IDs Similarly, third party IDs are unified identifiers for a third party — for example, every DoorDash transaction shares a single DoorDash counterparty ID.

​
Location

In addition to identifying the parties involved in a transaction, we will attempt to match on the exact geolocation of the counterparty involved. For physical transactions, this is the store where someone has made a purchase — for online transactions, it is typically the merchant’s headquarters. The location object includes a variety of information, including address, city, state, postal code, lat, long, and location phone number. It also has a location ID, a proprietary and unique Spade identifier for the exact location of the merchant. For example, the location ID for Walmart at 1590 Dunlawton Ave is different from the Walmart a few minutes away at 3811 Clyde Morris Blvd. Every transaction where we match on a location will include a location ID. Spade’s merchant matching tool can be used to retrieve location IDs ahead of enrichment time, for example to create authorization rules, and build rewards programs. Location data is also commonly used in UI/UX — learn more about how to use location data in your UI/UX here.

​
Industries

All transactions, regardless of whether or not they match on a merchant, will be categorized by Spade. Counterparty industry Spade has built a custom industry system leveraging our proprietary merchant database to more accurately categorize merchants. Our industry classification system is built as a tree, where tree nodes are sub-industries of their parents – the deeper into the tree you go, the more specific the industry is. Spade’s industry system excels in areas of common MCC weakness, for example classifying risky transactions and categorizing software spend. To obtain a full list of industries, please reach out to sales@spade.com or hit the the categories of the API. Third party type Third parties are also assigned a type in the third parties object. Possible types are buy-now-pay-later (e.g., Affirm), delivery services (e.g., DoorDash), marketplaces (e.g., eBay), payment processors (e.g., Square), and platforms (e.g., Venmo). Learn more about each type in our glossary.

​
Display Information

In addition to providing counterparty and third party information separately, each transaction includes a ‘display’ object that you can use in your UI to easily surface the information most recognizable to a user for you to plug into your UI. The display object consists of a combination of information from the counterparty and third party sections of the response. More information about the display object can be found here.

​
Enhanced Data Features

Premium fields and predictive signals – like recurrence detection, fraud signals, and Google Play app data – that can be activated based on your use case. Enhanced data features are add-ons and can be purchased by contacting sales@spade.com.

​
Recurrence detection

Our recurrence flag leverages transaction history and merchant information to identify recurring spend, from purchases at subscription merchants like Netflix to utility bill payments at Con Edison. When a recurring transaction is identified, we provide information including the recurrence interval (e.g., monthly vs. annual), the date of the next payment expected, and an array of recent recurrences. Learn more about about our recurrence detection here, and contact sales@spade.com for access.

​
Fraud signals (beta)

We offers merchant and transaction level data features designed design to be leveraged on the transaction and customer level to fight fraud and reduce risk. Data fields include content based merchant classification, business age and location age, and more. Contact sales@spade.com to learn more about our fraud signal offering.

​
Google Play app data (beta)

App store purchases represent one of the most highly disputed transaction categories for many of our issuers. We now offer developer, and application level data for 100% of Google Play store apps through our enrichment API. Contact sales@spade.com to learn more about our Google Play offering.