Skip to main content
Save 30% on your first year

Transaction enrichment

Transaction data enrichment API for banks and fintechs

Smartbills matches a card transaction to the itemized receipt from the point of sale, so your customers see the store, every item, the taxes and the tip, not a string of capitals.

Book a demoTalk to sales
A man at a café looks at a charge on his phone

Customers don't recognize SQ *MAPLE&RYE MTL QC. They recognize two maple lattes, a croissant and the avocado toast.

The receipt behind every charge

Smartbills names the merchant, attaches the itemized receipt and files every line before the transaction reaches your app.

Show the store, not the string

The real name, logo and street address of the store your customer walked into, the same one printed at the top of their receipt.

Categories based on what was bought

Each item on the receipt gets its own category, so the lattes are coffee and the toast is food, not one line of restaurants. The merchant's category stays put month after month.

The full receipt, attached to the charge

Every item and its quantity, the subtotal, each tax, the tip and the payment method, straight from the point of sale and labelled as facts rather than guesses.

Plug in once

One call at authorization, a batch endpoint for backfill and a webhook when a receipt arrives after the charge. Deployed in-region.

Smartbills joins each card transaction to its receipt, with every item, tax and tip, and names the merchant even when there's no receipt.

How transaction enrichment works

  1. Send the transaction

    Descriptor, amount, timestamp and whatever else you have: an ISO 8583 field, an open-banking row or a CSV. No cardholder data needed.

  2. Exact matches first

    If a store that uses Smartbills issued a receipt for that amount, at that terminal, at that time, the merchant is known, not guessed.

  3. The rest is filled in

    Descriptor parsing, our reference data and a model cover what the network can't. Every field says where it came from and how sure it is.

  4. Show it in your app

    Name, logo, map pin, category and, when there is one, the itemized receipt, in your own design.

SDKs

Enrich a transaction in one call

Send the authorization your processor already gives you. Get back the merchant, its location and the itemized receipt.

  • TypeScript@smartbills/sdk
  • React@smartbills/react-sdk
  • .NETSmartbills.SDK
  • Pythonsmartbills
Read the docs
import { SmartbillsClient } from "@smartbills/sdk";const smartbills = new SmartbillsClient({ accessToken: process.env.SMARTBILLS_TOKEN });// The authorization, as your processor sends itconst receipt = await smartbills.receipts.find({  descriptor: "SQ *MAPLE&RYE MTL QC",  amount: -36.72,  currency: "CAD",  mcc: "5814",  authCode: "A7K2Q9",  last4: "4021",  authorizedAt: "2026-10-08T12:41:07-04:00",});

Keep exploring

See all products

FAQ

Frequently asked questions

What people ask us before they sign up.

Transaction enrichment turns the raw text a payment terminal writes into something a person can read: a merchant name, a logo, a location and a category. That raw string was only ever meant to route a payment, which is why customers so often can't make sense of it on their statement.

Receipt enrichment adds the merchant's itemized receipt to a card transaction: what was bought, line by line, with the tax and the payment method. Transaction enrichment tells you where a purchase happened; receipt enrichment tells you what it was. Smartbills returns both in one response, because the receipts come straight from the merchant's point of sale and are matched to the transaction they belong to.

Categorization is a single field, and it only works if the other fields are right. Smartbills resolves the merchant's identity first and attaches the category to the business rather than the string. For merchants on our network we aren't classifying a string at all, because we hold the receipt.

They're resolved the usual way: descriptor parsing against a corpus, with a model for whatever is left. Provenance comes back for each field. You can display an inferred merchant differently or hide low-confidence fields.

No. Enrichment doesn't need cardholder data and doesn't receive it: we need the descriptor, amount and timestamp, and the cardholder's identity stays in your environment. With Embedded Receipts, card linking is tokenized through the network.

We accept the descriptor field from an ISO 8583 message, a row from an open-banking or aggregator feed, or a plain CSV for backfill. Most integrations start with a bulk backfill, since it's also the quickest way to measure your coverage, and then move to the live endpoint.

In-region. Canadian data stays in Canada and European data stays in Europe, which for a regulated institution tends to be the first question asked rather than the last.

Yes. Overrides are stored per user and applied on top of the resolved category. When a customer recategorizes something it stays that way, even after we improve the underlying taxonomy.

Get started

Send us a week of your own transactions.

Measuring coverage against your own book is the quickest way to know what you'd get back.

Book a demoBook a demo