Maple & Rye4398 Rue Saint-Denis, MontréalDirections
In your app, with data kept in region
Drop in the receipt view or build your own on the API. Deployed in Canada or in Europe, with no cardholder identity required.
Disputes and support
Fewer "what is this charge?" calls
Most disputes and support calls start with a cryptic terminal string. Show the business name, logo and store, plus the receipt where we have it, and the cardholder has the answer before calling.
Smartbills resolves the descriptor to the business, its logo and the store, and attaches the receipt when a network merchant issued one.
Enriched transactionSource: receipt
Raw descriptorSQ *LE PETIT DEP 8004169726 QC • $32.17
MerchantLe Petit Dep / 9418-2207 Quebec Inc.
Location179 Rue Saint-Paul O, Montreal QC / store 01
Line items2 x Espresso 3.25, 1 x Ham sandwich 11.50, 1 x Sugar pie 6.75
TaxGST 1.24, QST 2.47
Tip3.71 / 15%
Payment methodVisa 4417 / contactless
Confidence1.00 / source: receipt
Source: receiptProvenance per field
A transaction row the cardholder recognizes
The real trading name, logo, street address and category on the transaction, resolved to the store where the card was used.
- Trading name, legal name, logo, website, address and geocode
- Store-level resolution for multi-location brands
- Category taken from the business itself
Answer with the merchant's own record of the sale
Where the receipt exists, the argument is no longer about a descriptor. You can show what was bought, when, at which terminal and on which card.
- Line items, tax, tip and payment method from the merchant
- Original document kept and linked
- Provenance stated on every field in the pack
Why teams switch
A descriptor nobody can read turns into a dispute.
Our support queue is full of "what is this charge?" and too many of those turn into disputes.
The cardholder sees the merchant's real name, logo and location on the transaction row, which settles most of those questions before anyone picks up the phone.
Our agents defend a charge using the same descriptor the customer couldn't read.
Where the receipt exists, the agent can show the line items, tax, tip and payment method from the merchant's own record, and that usually ends the conversation in one reply.
Our evidence packs mix facts and estimates, and nobody can tell which is which.
Every field carries its provenance and a confidence score, so what was read off a document and what was inferred are labelled differently in the pack you submit.
The API, rendered your way
Two ways to ship it: build the transaction row yourself from the enriched record, or drop our receipt view under the row you already have.
Send the transaction
Descriptor, amount and timestamp. No cardholder identity is needed or received.
Get the business back
Trading name, logo, street address and category, down to the specific store.
Receipt attached when we have it
Line items, tax, tip and payment method, linked to the original document.
Show it
On the statement row and in your support console, with your own threshold for what's confident enough to show.
Our receipt view, nothing to build
Drop in the component
An itemized receipt view that opens from any transaction row, in the cardholder app and the agent console.
Most questions stop there
Most "what is this charge?" contacts end once the cardholder sees a name and logo they recognize.
Disputes arrive with evidence
What was bought, when, at which terminal and on which card, from the merchant's own record.
Late receipts are added
A webhook attaches the document if it arrives after authorization, before anyone opens a case.
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.
Dispute defence
Chargeback prevention that explains a charge right on the transaction screen, with the merchant's evidence ready for the disputes that open anyway.
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.
FAQ
Frequently asked questions
What people ask us before they sign up.
By answering the question before it's asked. Most "what is this charge?" contacts come from not recognizing the merchant, not from fraud. When the row already shows the business name, logo, street address and (where we hold it) the receipt, the cardholder works it out alone and never contacts you.
The merchant, store, address and category, resolved from the descriptor and labelled as resolved rather than known. Each field comes with a confidence score, and you decide what's reliable enough to show a customer.
Yes, that is what it's for. The original document is kept and linked to the transaction, and the line items, tax, tip and payment method come from the merchant's own record of the sale. Provenance is stated on every field. The pack never passes off an estimate as fact.
Only if you want to. An embedded receipt view opens from any transaction row in your app, and plain REST is there if you'd rather render it with your own typography and thresholds.
No. Enrichment needs the descriptor, the amount and the timestamp. Cardholder identity isn't required and isn't received, and the data stays resident in region: Canadian data in Canada, European data in Europe.
Get started
Answer the question on the row, not in the queue
Send us a backfill of past transactions and we'll report how many resolve to a store and how many match a real receipt.