Commerce FAQs

You’ve got questions, we’ve got answers.
Learn more about our industry-leading solutions for in-store and online purchase data extraction and enrichment.


Automate the capture of SKU-level purchase data from paper and digital receipts and eCommerce transactions using artificial intelligence.

Our receipt-scanning solutions (BlinkReceipt and BlinkEReceipt) currently support iOS, Android, and web API. We don’t currently support other platforms (e.g. Flutter/Cordova, React Native), although we do have clients that use them by creating wrappers into our supported platforms.

You can find our iOS SDK documentation here and our Android SDK documentation here.

You can access our API, including relevant documentation, here.

How can customers evaluate our BlinkReceipt product?

  • Customers will need to register first via
  • Once registered and logged in, they will be able to request their 30-day free trial after submitting their contact information, as well as what product they’re interested in.
  • After their request is approved, they should receive a notification via email. This process may take up to 24-48 hours.

What are the differences between the SDK and API?

There are no differences in commercial terms whether you use the BlinkReceipt and BlinkEReceipt SDK, API or both.

The SDK allows the client to leverage the custom camera and its various real-time callbacks to help the end user take the best possible picture of the receipt. Callbacks include receipt detection, blur detection, merchant, date, and total, as well as too far and too close detections. These custom models are built internally. The SDK processes the image locally on the device and is updated monthly.

Our web API ingests an image and processes it on a server. All models used in the SDK are also deployed via the API, which is also updated once per month.

From a user experience perspective, there is no real difference, and results are passed back to the end-user in real-time under both scenarios.

What types of receipts do you support?

Microblink has trained on till slip receipts received post-purchase from retail merchants.

As a retailer agnostic solution, we can support receipts with product numbers (e.g. Target, Walmart, Costco), as well as receipts with no product numbers (e.g., Kroger, Albertsons) using a variety of proprietary techniques we’ve developed over the years.

What countries do you support?

We currently support the United States, Canada, Mexico, Brazil, the United Kingdom, Germany, Spain, Poland, Sweden, South Africa, Australia, Indonesia, Philippines, and Singapore.

We’ve built custom extraction models for English, Spanish, French, German, Polish, Portuguese, and Swedish. We currently only support Latin characters.

It takes roughly 30 days to add support for a new language, so please contact us if your language of interest is not reflected above.

Do you have your own camera UX? Can we build our own?

We do offer our own Custom Camera Controller UI. For greater control, clients can build out their own UI that sits on top of our base camera controller.


Where do you store images?

We store images and resultant data on AWS. For clients in the United States, these servers are located in Virginia.

In compliance with GDPR, all European client data is stored on servers in the European Union.

How do you secure communication between the SDK and your servers?

We do standard HTTPS using TLS, client side certificate pinning, and symmetric encryption of any user credentials.

For email linking solutions for digital receipts, what do you do with user credentials?

Microblink never stores user credentials for any of our solutions. All credentials are maintained locally on the user’s device.

Physical Receipts

How long does it take to process a receipt?

Both our API and SDKs work in real-time (anywhere from less than a second to 4-5 seconds, depending on the network connection).

What do you consider a receipt?

Our system was trained on till slip receipts received post-purchase from retail merchants. Larger documents, like A4-sized invoices (e.g. hotel bills) were not used in training our system and are currently not supported.

What type of payment methods do you currently support?

We currently support Credit, Debit, Cash, Gift Card, Check, EBT/Food Stamps, Loyalty Redemption and WIC. This list continues to grow based on our clients needs.

Which merchants do you support?

Our merchant detection system uses Machine Learning models, phone number and address lookups, string matching, tax identification numbers, and other methods to find the merchant.

In the United States, we also have a database of more than 250,000 unique store locations that we look up using phone numbers and addresses. This database is updated regularly and includes store locations from hundreds of other countries, as well.

How do you find the merchant? Do you build support via merchant by merchant templates?

We have a number of ways to identify the merchant, including both Machine Learning (ML)-based and non-ML strategies. Our logic is generic, which allows us to scale in new markets in an accelerated fashion.

How do you find duplicate receipts?

We’ve built our own proprietary algorithms that take into account trip and basket data to determine whether the receipt has been seen before.

How do you identify fraudulent receipts?

We break down fraudulent receipts into two buckets: manipulated and counterfeit. In the United States, we look at the format of the receipt as well as if the receipt has been manipulated to return whether the receipt is fraudulent.

How do you scan long receipts?

For clients using the SDK, we guide the end-user to take multiple pictures of the receipt, starting from the top of the receipt all the way to the bottom. We merge the OCR results on our side to put all of the data back together.

Product Catalog

We’ve built our own product catalog of 15 million UPCs – and growing – to ensure only the cleanest data is returned to clients. We only ingest products once we know they are actually purchased, and as part of the ingestion process, we clean the brand name and category to align with our proprietary taxonomy.

We expand our catalog weekly through a combination of web crawling, manual annotation, and ongoing ML improvements driven by the vast volumes of receipts we process. This powers our data enrichment, which works across any physical or digital receipt format to provide SKU-level purchase insights at scale.

What data is passed back?

We return detailed purchase data from physical and email receipts, including:

  • Products: 
    • Receipt Short Description (RSD): the abbreviated text describing the product (eg “COKE ZERO 6PK”)
    • SKU: also called “RPN” (for Receipt Product Number), numeric sequence uniquely identifying that product within the merchant’s inventory. 
    • Price
    • Quantity
  • Discounts
  • Subtotal
  • Taxes
  • Total
  • Merchant, determined using text on the receipts, as well as logo and other various lookups:
    • Merchant Name
    • Merchant Address
    • Phone Number(s)
  • Additional Properties, including Payment Method(s) or Last 4 digits of credit card

The full documentation of properties can be found here.

How big is your product catalog?

Microblink’s product catalog is currently around 15 million products and constantly growing.

We only ingest products once we know they are actually purchased, and we add products using a mix of online retailer web scraping and in-store human data collection. As part of the ingestion process we clean the brand name and category to align with our proprietary taxonomy.

Our taxonomy is three levels: sector, department, major category. Additionally, we return product attributes. This applies across both physical (paper) and digital (e-Receipts) receipts.

In addition, we have over 400,000 brands in our catalog.

How many sectors do you support?

We currently return 22 sectors, including:

Accessories, Bags & Jewelry
Arts, Crafts & Sewing
Health & Medicine
Home Improvement
Household Essentials
Party, Gifts & Cards
Personal Care
School & Office
Sporting Goods

What is the process for adding new products to your catalog?

Each week, we crawl merchant websites and add products to our catalog that we know are purchased through our paper receipt and e-commerce database. For the remaining 5-10% of products that are not online, we send people into retail stores to find the UPCs we know exist in that store.

How do you classify restaurant receipts?

We’ve built an out-of-home taxonomy to align with the distinct categories found at quick service, fast casual, and sit-down restaurants. Extracted purchase data is mapped to verified menu items at the top 150 merchants in the United States.

What is the process to support a new market? How long does it take?

To open a new market, we need to first build a catalog of products unique to that market and need to create a ground truth regression set for that market to enable adequate testing before go-live.

We thoroughly test our text processing logic, working very closely with the client to ensure the data is where it needs to be.

It currently takes 60-90 days to launch in a new, non-English speaking market. It takes less than 30 days to launch in an unsupported English-speaking country.

We currently support the United States, Canada, the United Kingdom, Germany, South Africa, and Australia, and we are in the process of adding support for other non-English speaking markets.

Digital Receipts/E-Commerce

With Microblink, you can capture first-party purchase data with leading in-store and online purchase data extraction solutions. Automatically read and extract first-party purchase data from even the messiest of paper receipts, or reliably process digital receipts with our email inbox and online shopper account linking solutions.

What products do you offer for digital receipts?

Our e-commerce solution consists of three different approaches for scraping and parsing email inboxes, in addition to extracting purchase data from connected merchant accounts.

For email receipts, we offer a forwarding inbox, on-device scraping, and a server-to-server product:

  • Email Forwarding (API documentation)
    • Client sets up inbox (e.g., and instructs users to forward e-receipts to this inbox.
    • E-receipts get auto-forwarded to an inbox set up by Microblink.
    • We run a processing job of Microblink inbox every two minutes
    • Clients access the results via API key.
  • On-device Scraping
    • Users connect their inbox locally via username and password
      • OAuth providers (Gmail, Outlook) store the credentials on the device’s keychain (Note: Microblink does not save the credentials anywhere).
      • For IMAP providers (Gmail, Yahoo, AOL), users enter their regular email and password, and then the Microblink SDK walks users through the process of creating an App Password in a webview.
    • Microblink connects to the user’s inbox (either via the Gmail/Outlook SDKs or via IMAP) and queries for messages from the list of supported senders
    • We currently support Gmail (OAuth/IMAP), Outlook (OAuth), Yahoo (IMAP), and AOL (IMAP).
  • Server-to-server integration allows for passive, asynchronous scraping of inboxes.
    • Microblink scrapes user inboxes via server, then POSTs the results to client webhook (set up on client side)
    • Users connect their inbox locally via username and password
    • Microblink stores the credentials on the device’s keychain (Note: we do not save the credentials anywhere).
    • Client sets up an API to receive structured results.
    • Client calls methods into SDK (locally) to queue up scrape jobs (per email account, using credentials stored on-device) for as many merchants as are supported, which is controlled by a client’s server side config.

What digital receipt fields do you return?

Please reference our documentation for returned fields and responses for email receipts.

While we build out our documentation, please visit our Scan Results page to see what is returned for both on-device email scraping and account linking. (Note that it also includes the fields for physical receipts that can be returned by the BlinkReceipt SDK.)

How do you handle merchant or shopper accounts?

In addition to scraping user’s inboxes, Microblink offers a solution that lets users link their online accounts to extract SKU-level purchase data.

Users authenticate on-device (including the passing through of any two-factor authentication sent from the merchant), and within the SDK, clients dictate how far back they’d like to extract purchase data.

We can go back as far as three (3) years and currently support these merchants.

Note: we never store the user’s login information.

How do you get around two-factor authentication (2FA)?

As part of the authentication process, our SDK creates a unique app password for the client’s mobile app, which is used to authenticate with the server.

Where do you currently offer your e-commerce purchase data solution?

We are currently support the United States, Canada, the United Kingdom, South Africa, and Germany.

For more information around supported merchants within specific markets, please visit this page.

The time to open a new market for e-commerce transactions/digital receipts is generally 30 days.

How do you handle duplicate email receipts or multiple orders?

Our solution currently looks for duplicate email receipts via our forwarding inbox solution, which we identify by unique, trip-level fields such as merchant, order number, total, etc.

We return structured data from all digital receipts, including order confirmations, order updates, substitutions, pickup and delivery confirmations, etc.

In the event that a client wants one clean purchase record (that includes all of these updates and statuses), we can combine the emails into one final “receipt”, along with the component emails that make up that final record.

See more here under “Aggregation.”

How do you handle email receipts with PDF attachments?

We are able to detect PDF attachments to take into account data in both the body of the message and in the PDF to return the most relevant data.

Which emails do you actually look through?

Microblink only looks for specific senders delineated by our clients. We do not passively scan and collect every email in a user’s inbox.

How do you know which email address it’s coming from? How do you ensure it is a receipt?

We use the email sender to determine whether we should parse the receipt.

To ensure it is an actual receipt (as opposed to a marketing and/or promotional email), we run custom-built ML detection models and use post-processing logic to make the determination.