Skip to main content
Save 30% on your first year

Platform

Build on the receipt, not on the descriptor.

A card transaction gives you an amount and a string. Smartbills receives the itemized receipt from the merchant's point of sale at the moment of payment and delivers it to your product as structured data, already matched to the transaction.

Card network data
{
  "descriptor": "SQ *BISTRO ST-DENIS MTL QC",
  "amount": -119.58,
  "mcc": "5812"
}
Enriched by Smartbills
Enriched transaction
{
"merchant": { "name": "Bistro Saint-Denis", "mcc": "5812" },
"items": [
{
"name": "Steak frites",
"quantity": 1, "unit_price": 32.00,
"total": 32.00,
"category": "food"
},
{
"name": "Salade niçoise",
"quantity": 1, "unit_price": 21.00,
"total": 21.00,
"category": "food"
},
{
"name": "Glass of pinot noir",
"quantity": 2, "unit_price": 14.00,
"total": 28.00,
"category": "alcohol"
},
{
"name": "Crème brûlée",
"quantity": 1, "unit_price": 11.00,
"total": 11.00,
"category": "food"
}
],
"tax": 13.78, "tip": 13.80, "total": 119.58
}

Infrastructure

The digital infrastructure for receipts and invoices

Receipts still fade on thermal paper, and invoices are still PDFs someone retypes. Smartbills connects the point of sale to everywhere a receipt needs to go, as data, in seconds.

Where receipts are issued

  • Merchants
  • Point of sale
  • E-commerce
  • Payments
  • Accounting software
  • Your system, by API
Smartbills

Where they're delivered

  • SMS, email and QR
  • Smartbills app
  • Banking apps
  • Fintechs
  • Accounting software
  • API and webhooks

The problem

Everything downstream of a transaction feed is guesswork.

All three come from the same gap: the document that explains a purchase was never connected to the record of it.

Your users don't recognize their own transactions, because a statement descriptor isn't a business name.

Enrichment resolves the descriptor to a real merchant (name, logo, location and category) before it reaches your interface.

Any feature that needs line-level detail ends up built on OCR, and it degrades with every faded receipt.

Where the merchant is on the network, the lines arrive exactly as the point of sale recorded them, so there's no image to read and no confidence score to threshold.

You can't verify a vendor's coverage claims until you're already in production.

Coverage is measurable per market and per category, and where there's a gap we tell you about it instead of filling it with an inferred result.

What you can build

Products built on the receipt.

Each of these has its own product page, because each is something we ship today rather than a use case the API could in theory support.

The itemized receipt shown under the transaction it belongs to, in your product and under your brand. The cardholder links a card once, and every later purchase at a store that sends receipts through Smartbills shows up with no further action.

Learn more: Receipts inside your own app
Maple & Rye4398 Rue Saint-Denis, MontréalDirections

From keys to a rendered receipt.

What an integration looks like from start to finish. The reference for each step is in the documentation.

  1. Get credentials

    Talk to us about access. Platform APIs aren't self-serve yet; the conversation is short, and it's where we confirm coverage in your markets before you build against it.

  2. Link a card

    Your user connects a card once and their consent is recorded. For the end user that's the whole onboarding, with no app to install and no receipts to forward.

  3. Receive receipts

    Purchases at stores that send receipts through Smartbills arrive matched to the transaction, with the lines the point of sale recorded. Pull them from the API or subscribe to them as events.

  4. Render and ship

    Use the data directly, or drop in our component if you'd rather not build the view yourself. Coverage is measurable from day one, so you can decide what to show when there's no receipt.

FAQ

Frequently asked questions

Not yet. Platform access is granted after a conversation, mainly so we can confirm network coverage in your markets before you build against it. The documentation is public, so you can read it before we talk.

Yes, for receipts that only exist as an image or a PDF. Upload the file through the API and it's processed as a background job into an expense with the merchant, date, line items, subtotal and each tax line read out, and a webhook tells you when it's done. Where the merchant is on the network you don't need OCR at all: the receipt arrives as data from the point of sale.

Yes. Invoices and bills uploaded as images or PDFs go through the same extraction, including multi-page documents, and come back with the vendor, dates, line items and taxes. Taxes are read line by line, so GST, HST, QST and PST stay separate.

No receipt is produced, and the API tells you so instead of returning an inferred one. Enrichment still resolves the merchant behind the descriptor. Handling that case explicitly is the most important thing to get right in an integration, which is why we give you coverage figures per market before you start.

The cardholder links their card in your product, and consent is recorded against that action. Receipt data is personal information when it identifies an individual, so it's handled under the same regimes as the rest of your customer data. The security page has the specifics.

Data residency depends on the market and is confirmed during onboarding rather than stated here. The security page describes the current arrangement and how to ask about a specific jurisdiction.

Yes. Onboarding includes a test environment with synthetic merchants and receipts, so you can build and review an integration before a real card is ever linked.

Get started

Tell us what you are building.

The quickest way to find out whether this works for you is to get a coverage figure for your markets and look at a real receipt payload. One conversation covers both.