Invoice or GiroCode
→
Provider evaluation
Payment data
RecipientSanitär Krause
AmountEUR 359.44
IBANDE58 5705 0120 0094 7103 28
PurposeInvoice 2026-0417
IBAN validated by Docutain
Published
10 min read
By Sarah Karbach
How to Select a Photo Payment Provider
Reliable photo payment recognises payment data accurately, fits the bank’s architecture and keeps the data flow transparent. A feature checklist alone is not enough for a defensible provider decision.
- Objective
- Less manual entry with a controlled payment draft
- Inputs
- Camera, image, PDF and GiroCode depending on scope
- Evaluation
- Real invoices on representative physical devices
- Core criteria
- Quality, data flow, integration, UX, operations and support
Define the target workflow and scope
Start by defining the role of photo payment in the banking process. A typical target is a controlled payment draft: the app captures an invoice or GiroCode, transfers the recognised fields and presents them to the user for review before authorisation.
The scope should cover input channels, expected documents, required fields, supported platforms, UI ownership and the hand-off to the existing payment form. A solution for Android and iOS also has to fit the native or cross-platform technologies already used by the banking app.
Compare the complete banking workflow
| Criterion | What to review | Useful evidence |
|---|
| Recognition quality | Recipient, IBAN, amount, payment reference and other required fields across real invoices | A shared test corpus and documented field metrics |
| Input coverage | Camera, existing images and PDFs as well as GiroCode/EPC QR according to the use case | End-to-end tests for every planned source |
| Data processing | Processing location, external transfers, optional telemetry and deletion concepts | Architecture diagram, technical review and contract |
| Integration | APIs, UI components, error cases, theming, accessibility and the existing app architecture | A production-oriented proof of concept |
| Operations | OS and device updates, release cadence, monitoring, support and escalation | Support process, update policy and references |
| Total cost | Licence, implementation, QA, maintenance, support and switching risk over time | A three-year TCO based on the same scope |
Review local and server-based processing
Invoices can contain addresses, service details and other personal information in addition to payment data. The data flow is therefore an architecture and procurement criterion, not just a technical detail.
With local processing, images and recognised data remain on the device. Server-based models can offer different operational or update characteristics, but require the corresponding transfer and assessment. Review the actual processing path, optional services and telemetry separately for every provider.
The Docutain Photo Payment SDK processes invoice recognition and GiroCode locally on the device. The host app receives structured payment data for its own review and authorisation workflow.
Measure field-level quality and IBAN validity
A single aggregated accuracy figure can hide important differences. Measure the fields required by the payment process and distinguish between correct, missing and incorrect results. Include different layouts, print quality, folds, lighting, camera angles, digital PDFs and device classes.
Docutain returns an IBAN only when it is valid. This reduces invalid results but does not replace the user’s final review of the complete payment draft. Recipient, amount and payment reference should also be displayed for confirmation before authorisation.
GiroCodes already contain structured data. A robust solution therefore combines GiroCode recognition with invoice OCR for documents without a usable EPC QR code.
Evaluate integration, UX and operations
Do not stop at the first successful API call. A production-oriented evaluation covers permissions, camera and import flows, cancellation, error handling, theming, accessibility, lifecycle behaviour, logging, release builds and the hand-off to the payment form.
The UI should make the source and result understandable, present recognised values for review and allow corrections. The technical team needs stable APIs, documented platform boundaries and a reliable contact for integration and operations.
Test with real documents and devices
- Define an approved, representative invoice corpus and the expected fields.
- Use identical inputs and devices for every candidate.
- Record field quality, correction effort, runtime and cancellations.
- Trace local and server-side data flows technically.
- Include integration, UX, accessibility, support and TCO in the decision.
Use relevant production experience as evidence
At 1822direkt, photo payment runs directly on the device; the success story describes reliable use and a low volume of support requests. Star Finanz uses Docutain for local invoice recognition: on Windows for OCR and data extraction, and on Android, iOS and Mac Catalyst within the photo payment workflow.
References do not replace an evaluation with the bank’s own material. They show which evidence is useful for procurement: a concrete workflow, supported platforms, a transparent data flow and production experience.
FREQUENTLY ASKED QUESTIONS
Evaluating photo payment providers
Evaluate field-level recognition quality, input coverage, data flow, integration, UX, operations, support and total cost together. Weight each criterion according to your banking workflow.
Use the same approved invoice corpus and representative physical devices for every provider. Record correct, missing and incorrect results per field as well as the required manual corrections.
No. Camera behavior, focus, automatic capture and image quality must be tested on representative physical Android and iOS devices. Emulators are suitable only for basic integration checks.
A GiroCode provides structured SEPA data, but it is not present on every invoice. A combined solution uses GiroCode when available and invoice OCR as a flexible fallback.