No cardholder data changes hands
Enrichment works from the descriptor, the amount and the timestamp. It doesn't need to know who the cardholder is, and we never receive that information.
Cards and authorization
Clean merchant names on every card transaction
A location-scoped spend control needs the exact store, not a brand name. Smartbills resolves the descriptor to the site at authorization and attaches the receipt once issued.
Smartbills resolves each descriptor to the store itself, with its address and geocode, fast enough to sit in the authorization path.
Enriched transactionSource: receipt
Raw descriptorTIM HORTONS #4412 TORONTO ON • $18.14
MerchantTim Hortons / The TDL Group Corp.
Location220 Yonge St, Toronto ON / store 4412
Line items2 x Double double, large 4.10, 1 x Farmer's wrap 6.29, 1 x Timbits, ten pack 1.56
TaxHST 2.09 / 13%
TipNone on this receipt
Payment methodVisa 4417 / contactless
Confidence1.00 / source: receipt
Source: receiptProvenance per field
The store, not the head office
A chain with four hundred locations resolves to the one your cardholder walked into, with an address and geocode. Controls scoped to a site, region or category stop declining purchases they should allow.
- Multi-location brands resolved to the specific store
- Street address and geocode returned with the match
- Single-transaction REST endpoint for authorization
Late receipts attach by webhook
When a network merchant issues the receipt, a webhook moves the transaction from resolved to known and the basket appears under it, without the cardholder photographing anything.
- Webhooks for receipts that arrive late
- Line items, tax, tip and payment method where a receipt matched
- Batch endpoint for backfilling history
Why teams switch
A head office address says nothing about where the card was used.
A chain with four hundred locations resolves to its head office, so we can't tell where the card was used.
The descriptor resolves to the store the cardholder actually walked into, and comes back with a street address and geocode you can scope a control to.
Controls scoped to a site keep declining purchases they were written to allow.
Location and category are resolved before the authorization decision. The rule runs against a real merchant record and a legitimate purchase goes through on the first try.
Cardholders end up photographing a receipt to explain a charge we already approved.
When the merchant issues the receipt, a webhook attaches it to the transaction with its line items. The explanation is already on the row when anyone looks.
API in your card stack
Two ways to ship it: call the API at authorization and render the result yourself, or place our receipt view next to the transaction in your app.
Call us at authorization
Send descriptor, amount and timestamp in the authorization path. No cardholder identifier is needed or received.
Get the store back
A chain resolves to the location where the card was tapped, with its address and geocode.
The receipt follows
If the merchant issues one, a webhook upgrades the transaction from resolved to known.
Render it your way
On your statement and in your app, with your own threshold for what's confident enough to show.
Embedded receipt, nothing to build
Drop in the component
An itemized receipt view that opens from any transaction row in your card app.
Backfill the history
The batch endpoint fills in the past statements your cardholders couldn't make sense of.
Keep it current
POS push and mailbox capture add receipts as purchases happen. Nobody photographs a slip.
Late receipts catch up
The row updates in place when the document arrives after authorization.
The products that do the work.
Each product works on its own, and when you run two, the same record carries from the receipt to the ledger entry.
Transaction enrichment
Resolve a card descriptor into a business your customer recognizes, with logo, location and category, plus the itemized receipt when the merchant sent us one.
Embedded receipts
Itemized 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.
Corporate cards
Coming soonCorporate cards with receipt capture, coming soon: the itemized receipt arrives with the card transaction, and each card's limit comes from your budget.
FAQ
Frequently asked questions
What people ask us before they sign up.
Yes. The single-transaction REST endpoint is built for exactly that. You send the descriptor, amount and timestamp and get back the merchant, store, address and category in one call, and the receipt follows later by webhook so it never holds up the decision.
Just the descriptor, the amount and the timestamp. We don't need cardholder identity and we don't receive it. If you also use embedded receipts, card linking is tokenized through the network.
They're resolved the usual way, by parsing the descriptor against a merchant corpus plus a model. Every field comes back with its provenance and a confidence score. Your code can tell a merchant read off a receipt from one inferred from a string.
Yes, and most programs start there. A bulk backfill is also the quickest way to measure the coverage you'd see in production, which is why we report matched, resolved and unresolved per market before you commit.
In region. Canadian data stays resident in Canada and European data stays in Europe, which for a regulated issuer is usually the first question asked, not the last.
Get started
Resolve the store before the decision is made
Send us a backfill of past authorizations and we'll report matched, resolved and unresolved per market before you write any code.