Saltar al contenido principal
Ahorre un 30 % en su primer año

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.

Read the docsBrowse the SDKs
Datos de la red de tarjetas
{
  "descriptor": "SQ *BISTRO ST-DENIS MTL QC",
  "amount": -119.58,
  "mcc": "5812"
}
Enriquecido por Smartbills
Transacción enriquecida
{
"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
}

Infraestructura

La infraestructura digital para recibos y facturas

Los recibos aún se borran en el papel térmico y las facturas siguen siendo PDF que alguien vuelve a teclear. Smartbills conecta el punto de venta con cada lugar al que debe llegar un recibo, como datos y en segundos.

Para desarrolladores

Donde se emiten los recibos

  • Comercios
  • Punto de venta
  • Comercio electrónico
  • Pagos
  • Software contable
  • Su sistema, por API
Smartbills

Donde se entregan

  • SMS, correo y QR
  • App de Smartbills
  • Apps bancarias
  • Fintechs
  • Software contable
  • API y webhooks

The problem

A transaction feed only gives you a string and an amount.

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 as the point of sale recorded them. There is 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 reported per market and per category. Where there is a gap, the API says so instead of returning an inferred result.

What you can build

Products built on the receipt.

Receipts inside your app, enriched transactions, insurance claims and chargeback evidence, all from the same receipt data.

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.

Más información: 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

    Platform access is granted on request. We confirm coverage in your markets and issue sandbox keys.

  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 receipt component. The API reports coverage per market and tells you when a transaction has no receipt.

The products behind the API

Sample requests and responses for each product.

Documentation and resources

The reference documentation covers every endpoint. These links point to it and to the tools around it.

FAQ

Preguntas frecuentes

Not yet. Access is granted on request, once we have confirmed network coverage in your markets. The documentation is public.

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. Coverage figures per market are provided 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. 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. Build and test your integration there before linking a real card.

Get started

Tell us what you are building.

We'll send coverage figures for your markets and a sample receipt payload.

Talk to usRead the docs