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.
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.
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.
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.
Cómo funciona transaction enrichment
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.
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.
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.
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 - .NET
Smartbills.SDK - Python
smartbills
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",});Siga explorando
Ver todos los productos- ProductoEmbedded receiptsItemized receipts from the merchant's point of sale, shown inside your own app under the transaction they belong to. For banks, fintechs, retailers and any app built on the API.
- ProductoDispute defenceChargeback prevention that explains a charge right on the transaction screen, with the merchant's evidence ready for the disputes that open anyway.
- ProductoDigital receiptsDigital receipt software that turns every sale at your POS into an itemized electronic receipt, hosted online and delivered by app, SMS, email or API.
FAQ
Preguntas frecuentes
Lo que nos preguntan antes de registrarse.
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.