Build or buy a receipt verification API? A practical architecture guide
Compare building and buying receipt extraction, quality checks, duplicate controls, review operations, webhooks, and loyalty delivery.
The first version of receipt scanning looks small: accept an image, read a date and total, return JSON. A production promotion adds the work hidden behind that diagram. Customers upload bad photos. Retailers abbreviate products differently. The same purchase arrives from another account. Ambiguous evidence needs a reviewer. Webhooks fail and retry. Someone must explain why a genuine customer was rejected.
The build-or-buy decision is not “can our team call an OCR model?” It is “which parts of the verification operation create an advantage for us, and which parts do we want to own for years?”
Map the full system before estimating it
A production path normally needs:
- upload sessions and file validation
- image normalization and a capture-quality gate
- field and line-item extraction
- product-catalogue matching
- configured eligibility and consistency rules
- visual and purchase duplicate checks
- an exception queue with evidence and reasons
- signed events, idempotent delivery and retries
- retention, audit history and access controls
- a downstream loyalty or promotion decision
The last item deserves emphasis. Verification should produce trusted evidence and a decision against its configured evidence rules. The loyalty engine owns earning, limits, challenges, tiers and rewards. In the native Steve–Open Loyalty integration, approved receipts become transactions; Open Loyalty then applies campaign and earning rules.
When building is reasonable
Building can make sense when the workflow is narrow, stable and strategically distinctive. You may have one retailer feed with clean identifiers, an existing internal review tool, and engineers who already operate image pipelines and event delivery. You may also need controls so specific that a general service would require more adaptation than it saves.
Estimate the ongoing system, not the prototype. New receipt layouts and product descriptions appear. Fraud patterns change. Review policies need versioning. Customer support needs reasons. Operations need replay and audit tools. Security teams need key rotation and retention controls.
When buying is reasonable
A managed verification layer is attractive when the campaign spans retailers, evidence quality varies, launch dates matter, or several clients need different rules. It can also remove the need to join separate OCR, duplicate, queue and delivery products.
Buying does not remove design work. You still own the campaign brief, product reference data, participant experience, downstream integration and acceptance test. Steve exposes configured fields with per-field confidence, rule reasons and event history; matching arbitrary catalogue records to receipt lines remains a workflow to design and validate rather than an automatic consequence of providing a catalogue.
Compare the real options
| Area | Build | Buy | Hybrid question |
|---|---|---|---|
| Capture UX | Full control | Reuse hosted/API capture | Keep app UX, call verification API? |
| Extraction | Tune and operate models | Configure required schema | Keep proprietary catalogue matching? |
| Duplicates | Build history and matching | Configure workflow scope | Share only identity keys? |
| Review | Build queue and permissions | Use provider queue/API | Review in existing case tool? |
| Delivery | Own signing, replay, ledger | Use signed webhooks/connector | Which system is source of truth? |
| Loyalty | Build campaign engine | Integrate one | Let Open Loyalty own earning? |
Test failure paths through the API
A technical evaluation should include more than a successful request. Retry the same client submission identifier. Deliver the same webhook twice. Reject a bad signature. Simulate a downstream outage and confirm delivery can be retried without creating two loyalty transactions. Submit an unreadable image and verify the response distinguishes “cannot assess” from “ineligible.”
Steve’s delivery API uses short-lived upload sessions, client submission identifiers, HMAC-signed webhooks and a delivery ledger. The typed client covers the API and signature verification. Approved evidence can be delivered as Open Loyalty transactions or custom events. These controls are part of the product boundary; points calculation remains in Open Loyalty.
A build-or-buy checklist
- Can every decision be traced to evidence and a rule?
- What is the duplicate scope: participant, campaign, client or full history?
- What happens when a field or product match is uncertain?
- Can reviewers override a decision, and is the action logged?
- Are gated uploads billed?
- Are events signed, deduplicated and replayable?
- Can rules and schemas change without rewriting historical results?
- Who owns reward qualification and member balance changes?
- What format and page limits apply?
- Can you evaluate the system on your own labelled sample?
If you are deciding whether to assemble this stack or use a managed layer, book a technical demo. Bring a sample payload, several difficult receipts and the system that should receive the result. We will map the responsibilities before discussing implementation.
