finway API Integration Research

Date: 2026-05-13 Product: finway (finway.de) -- "Finance Operating System for SMEs", Munich, Germany Purpose: Evaluate finway's API capabilities for Orcha integration -- specifically for a German customer evaluating finway as a Pleo alternative for employee credit cards while continuing to use Orcha for AP invoices and DATEV for accounting.

Important Context: What finway Actually Is

finway is NOT an ERP or accounting system. Like Pleo, Moss, Payhawk, and Spendesk, it is a spend management platform headquartered in Munich (not Berlin -- correcting the brief), founded in 2020, ~52 employees, ~$10M Series A raised, ~400 customers (per a 2023 Forbes reference). It positions itself as the "Finance Operating System for SMEs" and bundles a wide module set:

• Invoice Processing (AP) -- OCR, e-invoice support, multi-level approval workflows
• Preparatory Accounting -- cost-center coding, G/L mapping, DATEV export
• Corporate Cards -- virtual + physical Mastercard Business Debit (Paynetics AD via Weavr)
• Payments & Bank Connection -- PSD2 to 4,500+ banks
• Travel Expense Management + Employee Reimbursement
• Purchase-to-Pay (P2P) -- POs, 3-way matching (add-on module, launched Q3 2025)
• Budget Control & Reporting

Implication for Orcha: finway is a direct AP competitor in the German SMB segment -- a meaningful overlap because AP automation (OCR, invoice approval workflows, DATEV export) is finway's flagship feature, not a sidecar. Unlike Pleo/Payhawk where the AP module is a clear-cut add-on, finway is marketed primarily as an AP/spend platform with cards layered on top.

Critical for the customer scenario: The customer wants finway for cards only while keeping Orcha for AP. This requires verifying both (a) whether finway sells a cards-only package and (b) whether finway exposes APIs to feed card data into Orcha. The short answer to both is no -- see sections 2 and 6.

1. Summary -- Capability Matrix

Overall assessment: finway has no public developer API, no developer portal, no published webhook surface, and no iPaaS connectors (no Zapier, Make, Workato, Celigo, n8n). Independent reviewer GetApp explicitly lists "API: No" for finway. The only documented programmatic touchpoints are:

1. A native Personio integration that one-way-syncs employee master data into finway
2. A native DATEV Unternehmen Online one-click export
3. CSV/XML exports to ADDISON, BMD, Lexware, Agenda, SESAM, and DATEV
4. A GetMyInvoices inbound connector for invoice collection
5. Google SSO + Microsoft Entra ID for authentication
6. A "finway Integrations (Agent-Schnittstelle)" -- finway's own marketing term for an agent/RPA-style bridge to legacy systems; this is not a public REST API, it's a custom integration service finway delivers per project

For the customer scenario in scope (Orcha = AP, DATEV = accounting, finway = cards), this is a serious blocker on both the read side (cannot pull card transactions into Orcha programmatically) and the write side (cannot push CoA/cost-centers/tax-codes/vendors into finway via API).

2. API Landscape

Public Developer Surface

There is no public finway developer portal, no API documentation, no OpenAPI spec, no Postman collection, and no published authentication scheme.

Probed and confirmed missing:

The finway.de official site mentions DATEV interfaces, Personio integration, CSV/XML exports, and the "Agent-Schnittstelle" -- but the words "API", "REST", "Webhook", "OAuth", "Entwickler", and "Developer" do not appear on the integrations page, pricing page, why-finway page, product pages, or new-functions/release notes page. The German pricing page uses "Schnittstelle" only in reference to DATEV.

The apitracker.io Entry Is Misleading

apitracker.io/a/finway-de shows what looks like API metadata (authentication, sandbox, OpenAPI spec, SDKs, webhooks management API), but inspection reveals the page is an Apideck-operated catalog stub -- every concrete field shows a placeholder dash ("-"), and the footer invites the vendor to "let us know if you have a spec to share". The "specifications" sub-page explicitly states "We don't have API specifications for finway yet". The page surfaces what an API could contain, not what finway actually provides. Apideck does NOT have a finway connector in its unified accounting API.

Multiple web-search hits that summarise this page as "finway has Developer docs, API Reference, Webhooks, Webhooks management API, Sandbox environment, Authentication including SSO/Social login, OAuth playground, GraphQL playground, API Explorer, Postman/Insomnia collections, OpenAPI/Swagger specs" appear to be LLM hallucinations triggered by the template field labels on the apitracker page. None of these resources actually exist for finway as of May 2026.

Independent Confirmation

• GetApp (finway product page, 2026): "API: No" -- this is the definitive third-party confirmation
• Capterra (feature list): no API field; only "Integrate with a third-party accounting system" (4.1/5 user rating)
• G2 alternatives page: lists finway features but no API category
• OMR Reviews: mentions "Apis / integration" as a generic capability tag but provides no API specifics; integrations listed are limited to DATEV, Personio, Google SSO, Microsoft Entra
• finway-published release notes (2022 -> 2025): no API/webhook/developer feature ever announced

What Does Exist Programmatically

3. Write Capability Verification

Confidence: HIGH that no public write API exists.

There is no documented public REST endpoint to write any record type into finway. Every reference-data object the customer would want Orcha to push (chart of accounts, cost centers, tax codes, vendors/suppliers) is set up via one of:

1. The onboarding template CSV (a one-time bulk upload during implementation -- explicitly described on finway.de/en/implementation: "use our onboarding template to upload your employee, cost centre, supplier, subscription and G/L accounts")
2. Manual UI configuration in finway's web app
3. The Personio inbound sync (employees only)
4. The DATEV inbound flow (one-way export only; DATEV does not push master data back into finway -- this differs sharply from Payhawk's DUO-bidirectional integration)

Confirmed-Missing Write Operations

The "Agent-Schnittstelle" Caveat

finway markets an "intelligent Agent-Schnittstelle" as a bridge to legacy/existing systems. This is not a public, self-service API -- the language and context strongly suggest a custom integration service (likely RPA/headless-browser or middleware delivered by finway's Customer Success team during onboarding). There is no public documentation, no rate card for this offering, no SDK, and no developer portal. A customer wanting Orcha <-> finway integration via this channel would have to negotiate a custom statement of work with finway -- and given that Orcha and finway are AP competitors, finway has no business incentive to facilitate this integration cleanly.

4. iPaaS & Middleware Findings

This is a notable gap relative to Pleo (Zapier: 4 triggers + 8 actions), Payhawk (Workato official + Make community), and Spendesk (Zapier + Make community). finway has zero iPaaS coverage, which means there is no third-party-built API specification we can use to infer undocumented capability. The iPaaS evidence is consistent with the direct evidence: no API to expose.

5. Alternative Channels

DATEV Integration

Implication for the customer scenario: Because finway -> DATEV is one-way, the customer's CoA, cost centers, and tax codes in finway must be manually kept in sync with DATEV (or with Orcha's view of those). There is no automatic master-data feed in either direction at the finway side. The customer would have to keep three sources of master data aligned manually: DATEV (the accounting truth), Orcha (the AP truth), and finway (the cards truth).

Native ERP/Accounting Integrations

Confirmed list (limited compared to Pleo/Payhawk):

Notable absences vs Pleo/Payhawk: No NetSuite, no Business Central, no Sage Intacct, no Exact Online, no Xero, no QuickBooks, no Odoo, no Pennylane. finway is a DACH-only accounting integration story -- their entire export catalog is German/Austrian DATEV-family products.

HRIS Integrations

• Personio (one-way: Personio -> finway; employee, team, absence data) -- this is built on Personio's API, not finway's
• No other HRIS connectors documented

Webhooks

• NO webhook surface published.
• No subscribe/manage endpoint exists in any documentation
• No event catalog
• This is a hard blocker for real-time card-tx ingestion into Orcha

Banking

• PSD2 via third-party AISP/PISP (unspecified provider; supports 4,500+ banks for retrieval, 2,700+ for online transfer)
• Not exposed to finway customers as a developer API
• Used internally by finway for invoice-to-bank-tx matching

Cards Infrastructure

• Mastercard Business Debit, issued by Paynetics AD (Sofia, Bulgaria; EMI licensed by Bulgarian National Bank), distributed via Weavr (announced Nov 2021)
• Last-4 digits, virtual/physical flag, FX information, Apple Pay support: none documented in any customer-facing material (only Google Pay is mentioned)
• The Weavr partnership in principle gives finway access to real-time card transaction events, but finway does not expose any of that to its customers

Document Capture

• Email forwarding (company-specific inbox)
• UI upload (bulk supported)
• Mobile photo capture
• GetMyInvoices integration (3rd party invoice fetcher; rated 3.0/5)
• No API ingestion -- cannot push an invoice via REST

6. Licensing & Access Requirements

API Access

There is no API access tier because there is no API. This is the headline finding.

A customer purchasing the maximum-tier finway plan still has no programmatic write access for reference data and no programmatic read access for transactions. The only programmatic touchpoints (Personio inbound, DATEV outbound, GetMyInvoices inbound) are pre-built by finway against named third-party services -- they cannot be reused for Orcha.

Plan Pricing (Invoice-Volume-Based)

Pricing model: Per-invoice-volume + unlimited user seats (unlike Pleo's per-user model). Monthly billing carries a 20% surcharge over annual.

Cards cost: EUR 0 for virtual; EUR 3/card/month for physical.

Critical Pricing Finding: There Is No Cards-Only Plan

The customer's preferred shape -- "finway just for cards" -- is not a supported package. Cards are bundled into both Essential (EUR 209+/mo) and Professional (EUR 299+/mo) plans, and the EUR 209 plan also includes "Digital invoice processing (incl. e-invoice)", "Pre-allocation and invoice split", and "Multi-level approval processes & workflows" -- which is exactly the AP functionality that Orcha already provides for this customer.

In other words, if the customer buys finway for cards, they're paying full price for the AP automation module they don't intend to use. There is no SKU-level separation between the cards capability and the AP capability in finway's published pricing.

Compare to:

• Pleo: Same problem in principle, but Pleo at least offers an Essential tier where cards are the primary value
• Payhawk: Solved cleanly via module pricing -- Cards & Expenses ($449/mo) is a separate SKU from Bill Payments ($349/mo)
• Spendesk: Modular; cards purchasable without AP
• Moss: Similar bundling issue to finway

Customer Setup Checklist (What Would Be Required)

For the customer to use finway-for-cards alongside Orcha-for-AP:

1. Purchase finway Essential plan (EUR 209+/mo) -- accepting that bundled AP functionality is unused
2. Complete the standard finway onboarding (2-6 weeks per finway's own messaging) including:
   • Upload employees, cost centers, suppliers, G/L accounts via onboarding CSV template
   • Configure DATEV DUO export connection
   • Set up KYB / bank account
   • Issue cards to employees, configure limits
3. For the customer's analytics use case: export card transactions from finway UI to CSV on a recurring (manual) cadence and either:
   • Forward CSV exports to Orcha via shared drive / email / SFTP
   • OR fund a custom-integration project with finway's Customer Success team to use the "Agent-Schnittstelle" -- pricing not published
4. For reference data consistency: keep CoA/cost-centers/tax-codes/suppliers manually in sync between Orcha, DATEV, and finway. There is no automated path.

Ongoing Cost Implications

• The bundled AP module the customer doesn't need is part of the EUR 209+/mo base
• If Personio is in the stack, the inbound employee sync is free of charge
• DATEV DUO connection is free
• Custom integration work via Agent-Schnittstelle is custom-quoted
• No API call metering (because no API)

7. Orcha-Specific Deep Dive

Critical Question Comparison: finway vs Pleo on the Customer's Pain Points

Critical Question: What Role Does finway Play Relative to Orcha?

finway and Orcha are direct AP competitors in the DACH SMB segment. The overlap is severe -- not the "Bill Payments module that can be turned off" pattern of Payhawk, but a core bundling where buying finway means buying competing AP functionality regardless of whether the customer uses it.

For the customer scenario, the natural reading is: if the customer buys finway for cards, finway will try to grow within the account by deprecating Orcha's AP role. The mere act of purchasing finway puts a competing AP automation suite into the customer's stack, fully provisioned and pre-paid.

Integration Scenarios for the Customer

Scenario A: Orcha reads card transaction + expense data FROM finway (PRIMARY USE CASE)

• Feasibility: LOW
• No webhook surface, no public API, no documented data feed
• Only path is manual CSV export from finway UI on a cadence (daily/weekly) and dropping it somewhere Orcha can ingest
• Not real-time; not automated; not durable across UI changes
• Would require an Orcha-side CSV parser per finway's export schema, which may change without notice
• Alternative: pay finway's Customer Success team for an Agent-Schnittstelle custom build -- but this is fundamentally requesting our AP competitor to build integration to us, with all the obvious commercial and reliability concerns

Scenario B: Orcha writes reference data INTO finway for consistent coding (SECONDARY USE CASE)

• Feasibility: LOW
• No public POST endpoints
• Workaround is the one-time onboarding CSV template, which is not a sync mechanism -- it's an implementation step
• For ongoing changes (new supplier in Orcha, new cost center, new G/L account), the customer's finance team would have to log into finway's UI and manually replicate
• This is operationally painful and error-prone for a customer who already has Orcha as the AP master

Scenario C: Customer keeps Orcha as AP master, lets finway maintain its own coding independently, converges at DATEV

• Feasibility: HIGH but architecturally messy
• Each of Orcha (AP) and finway (cards) pushes independently to DATEV DUO
• DATEV is the single source of truth for accounting
• Risk: divergent coding between finway and Orcha (different G/L assignments for the same vendor, different cost-center hierarchies, etc.) -- which surfaces as inconsistency when the customer's tax advisor reconciles
• This is the only realistic path with finway, but it's strictly worse than what Payhawk/Pleo enable

Scenario D: Orcha pushes invoices into finway

• NOT POSSIBLE via API (no endpoint exists)
• Email-to-inbox would work mechanically but is irrelevant since the customer doesn't want this

Key API Differences vs Pleo and Payhawk

Orcha Integration Capability Summary

8. Recommended Path Forward

Assessment: finway Is NOT a Good Coexistence Partner for Orcha in This Customer Scenario

Three factors compound to make this integration impractical at the current state of finway's platform:

1. No public API surface at all -- not a "gated to Enterprise plan" situation; the API simply does not exist for any customer at any price point
2. Cards are bundled with competing AP functionality -- buying finway-for-cards means paying for finway's AP module, which directly overlaps with Orcha. There is no SKU-level separation
3. One-way DATEV integration -- the master-data-consistency burden falls on the customer's manual operations, with no automated keep-in-sync path between Orcha, DATEV, and finway

Honest Recommendation to the Customer

For a customer who wants to replace Pleo with a card programme that plays well with Orcha + DATEV, finway is the weakest option of the four spend-management platforms researched so far. The ranking on this customer's specific criteria:

If the customer's primary requirement is "feed card transactions into Orcha for unified spend analytics", finway makes that nearly impossible without a custom integration engagement -- which we cannot recommend with an AP competitor.

When finway Might Still Make Sense for the Customer

Despite the integration gaps, finway could in principle fit if:

1. The customer is comfortable accepting manual CSV-based synchronization between finway -> Orcha for spend analytics (weekly cadence, parsed by Orcha's CSV ingestion pipeline if one exists)
2. The customer accepts manual triple-source-of-truth maintenance for CoA / cost centers / suppliers across Orcha, finway, and DATEV
3. The customer is willing to pay for the bundled AP module they don't intend to use (EUR 209+/mo)
4. The customer prefers a single-vendor DACH-native UX in German that bundles cards + travel expenses + reimbursements + (unused) AP

None of these are technical wins; they are commercial trade-offs the customer would have to consciously accept.

What NOT to Build

• Direct API integration to finway: Not possible -- no API exists
• Webhook subscription for card transactions: Not possible -- no webhook surface
• Reference data sync to finway: Not possible programmatically -- CSV template only
• Custom Agent-Schnittstelle work with finway's CSM team: Strongly discouraged -- inviting a direct AP competitor into custom integration work creates obvious commercial and reliability risks

Pre-Implementation Verification Needed (If Customer Insists)

Before committing engineering effort to any finway integration:

1. Empirical verification of the export schema -- pull a CSV export from a finway demo account and validate column stability across export templates
2. Confirm the Agent-Schnittstelle pricing and SLA -- if the customer wants to fund a custom integration, get it quoted in writing
3. Verify card-data field coverage in the CSV export (FX, merchant ID, card last-4, virtual/physical flag) -- none of these are publicly documented
4. Probe whether finway will release public APIs in 2026 -- their roadmap is not published, but worth a sales conversation if the customer has buying power

Architecture Decision

Recommendation Summary

For the customer scenario (DATEV + Orcha + Pleo replacement for cards): finway is not a fit. The combination of no public API, no webhooks, AP-bundled pricing, one-way DATEV, and the direct competitive overlap with Orcha on AP makes this the worst of the four spend-management options researched. We recommend the customer evaluate Payhawk first, Spendesk second, and treat finway as last-resort if the customer has a strong non-technical preference (German UX, bundled travel, single-vendor consolidation) that overrides the integration cost.

Compared to Pleo on the three critical gaps:

1. Realtime: Pleo has partial webhooks; finway has none -- finway is worse
2. Receipt URLs: Pleo expires after 24h; finway has no documented receipt URL surface at all -- finway is worse
3. API pricing tier: Pleo gates API to Advanced ($109/mo+); finway has no API at any tier -- finway is worse

On the cards-only question: No. finway does not sell cards as a standalone SKU. The cards capability is bundled into the Essential plan (EUR 209/mo) alongside full AP automation that directly competes with Orcha. The customer would be paying for AP functionality they don't intend to use, with the structural risk that finway's growth motion within the account is to displace that unused-but-paid-for AP capability against Orcha.

9. Sources

Official finway Documentation

• finway homepage (EN)
• finway product overview (EN)
• Integrationen (DE) -- canonical integrations page; no API mention
• DATEV integration -- confirms one-way export
• Pricing (EN) -- EUR 209 / EUR 299 / P2P on request
• Pricing (DE) -- same content, in German
• Company cards product page -- Mastercard via Paynetics/Weavr
• Bank connection product page -- PSD2 via third-party AISP
• Invoice receipt and capture -- email / UI / mobile / bulk; no API
• Preparatory accounting
• Why finway
• About us -- Munich, founded 2020, ~400 customers, ~$10M Series A
• Implementation -- onboarding template approach
• New functions / release notes -- 2022-2025 history, no API releases

Help Center

• help.finway.de -- no developer/API category
• Update September 2025 -- POs and Invoice Matching -- latest product update, no API content

Confirmed Missing Developer Surface

• developer.finway.de -- DNS does not resolve (probed)
• api.finway.de -- DNS does not resolve (probed)
• docs.finway.de -- DNS does not resolve (probed)

Third-Party Validation

• GetApp: finway profile -- explicit "API: No" listing
• Capterra: finway profile
• Capterra: finway reviews -- user feedback on DATEV/banking limitations, no API requests
• G2: finway alternatives
• OMR Reviews: finway -- only DATEV, Personio, Google SSO, MS Entra mentioned
• Tekpon: finway reviews
• apitracker.io: finway profile -- catalog stub (Apideck-operated), all fields placeholder
• apitracker.io: finway specifications -- explicitly states "We don't have API specifications for finway yet"
• Crunchbase: finway

Integration Partners (Confirmed)

• Personio Marketplace: finway integration -- inbound employee sync
• Wolters Kluwer ADDISON OneClick partner: finway -- XML export

Cards Infrastructure

• Weavr partners with finway (Nov 2021) -- Paynetics AD as issuer, Weavr as distributor
• Paynetics: Weavr partnership

iPaaS Coverage (Confirmed Missing)

• Zapier site:zapier.com finway -- 0 results
• Make.com site:make.com finway integration -- 0 results
• Workato marketplace -- no finway connector
• Celigo marketplace -- no finway connector
• n8n -- no finway node
• Apideck connectors -- no finway integration

Background Reading

• finway: Crunchbase profile
• Forbes / Authority Magazine: Jennifer Dussileck interview
• Business Money: Weavr partners with finway

Reference Docs (Orcha Internal)

• /docs/research/integrations/2026-04-29-pleo-integration-research.md
• /docs/research/integrations/2026-05-13-payhawk-integration-research.md
• /docs/research/integrations/2026-05-14-qonto-vs-pleo-defense-customer-assessment.md

Addendum 2026-05-14 — Defense, Cannibalization, Funding Model

Supplementary research for a German defense-sector customer (currently Pleo for cards, DATEV for accounting, Orcha for AP) who wants to replace Pleo. Updated customer priorities: cards must work very well, good mobile receipt-capture app, a very good API for Orcha to READ and WRITE, and a non-prepaid card funding model (charge card / credit line preferred). This addendum confirms/updates the four areas below; all claims cited.

A. Defense-Sector Posture — Verdict: AMBER (leaning RED on funding model)

Data hosting (confirmed German). finway's security page states data storage is on an AWS server in Frankfurt am Main, with backups in Paris, France. finway states it relocated hosting to Germany for sub-processors from "unsafe third countries" where technically possible, and concluded SCCs with the rest. Good residency story for a German buyer. finway Security, finway Privacy Policy

Certifications. Underlying AWS infrastructure is ISO/IEC 27001 compliant; finway itself advertises GoBD certification per IDW PS 880, AES-256-GCM encryption, and regular penetration tests. The card stack (weavr / Paynetics) meets PCI DSS v4 Level 1. No evidence of finway holding its own platform-scoped ISO 27001, SOC 2, ISAE 3402, or BSI C5. BSI C5 — the German cloud-security standard most relevant to a defense buyer's own security function — is not held. Same gap as Qonto and Pleo. finway Security

Card BIN issuer + its defense policy — the decisive finding. finway cards are Mastercard Business Debit issued by Paynetics AD (Sofia, Bulgaria; EMI licensed and supervised by the Bulgarian National Bank), distributed via weavr. Two layers of Paynetics terms apply:

• The binding finway programme terms (the "Nutzungsbedingungen der Paynetics AD" PDF hosted on finway.de, dated 25 Oct 2023) define "Prohibited Transaction" as an 8-item list — pyramid/Ponzi schemes, illegal items, counterfeits, third-party payment aggregation, money laundering, terrorism financing, pornography/escort services, and unlawful card use. Weapons/arms/military goods are NOT explicitly named in this binding list. However, the same terms give Paynetics broad discretion: "Paynetics may refuse to approve any application and/or enter into an agreement for its services for any reason," plus KYB/UBO verification and refusal/termination rights tied to "Prohibited Transaction" belief. Paynetics AD terms hosted on finway.de
• Paynetics' general Customer Acceptance Policy (paynetics.online) — the issuer-wide AUP — explicitly lists "Weapons, firearms, munitions of any sort" among ~60+ prohibited business categories, and reserves discretionary termination where the relationship "would cause serious operational and/or reputational risk." Paynetics Customer Acceptance Policy

So the issuer carries an explicit weapons exclusion even though the finway-specific programme terms do not name it. This is the same Paynetics AD issuer that Payhawk uses — meaning finway and Payhawk share the identical issuer-level defense exposure. For an actual arms/munitions manufacturer this is a real onboarding/offboarding risk; for a defense-adjacent business (software, IT, logistics, dual-use components) it is discretionary and would need written pre-clearance. finway itself publishes no own AGB with an industry-exclusion list — the binding restrictions are entirely the Paynetics layer.

Verdict: AMBER. German hosting is a plus; the lack of BSI C5 and the issuer-level "weapons, firearms, munitions" exclusion are the concerns. Not as clearly RED as Qonto (whose own policy explicitly bans "military activities… sale of weapons, military vehicles"), but the Paynetics issuer exclusion means finway is no safer than Payhawk on defense and materially less safe than a vendor that issues under its own licence with no weapons clause. Combined with the funding-model finding (Section D), the practical verdict trends toward RED for this customer.

B. Cannibalization Risk vs Orcha — Rating: HIGH

Confirmed HIGH. This is the standout risk and nothing in this refresh softens it. finway's flagship product is AP automation — invoice OCR, e-invoice processing, pre-allocation/invoice split, multi-level approval workflows, GoBD-grade preparatory accounting (cost-center/G-L coding), and DATEV export. That is a near-complete functional overlap with Orcha's core. Unlike Pleo (spend tool that stays in its lane) or Payhawk (modular, cards/AP are separable SKUs), finway has no cards-only SKU: the entry Essential plan (from €209/mo) bundles "Digital invoice processing (incl. e-invoice), Pre-allocation and invoice split, Multi-level approval processes & workflows, DATEV export & interface" together with cards. finway Pricing

Buying finway-for-cards therefore means paying full price to install a direct, fully-provisioned AP competitor inside the customer's stack — one with an obvious commercial incentive to grow within the account by displacing Orcha's AP role. finway is the most directly cannibalizing vendor in the entire researched set: more so than Qonto (whose AP ambition via Regate is real but not yet in the German core product) and more so than Payhawk (modular, AP can be left unbought). Rating: HIGH — and structurally so, because the overlap is the product, not a toggleable module.

C. API Read/Write Refresh — Still NO public API

Re-verified: finway has still not launched any public developer API. No developer portal, no API docs, no OpenAPI spec, no webhooks, no OAuth, no published auth scheme. The apitracker.io/a/finway-de page remains an Apideck-operated catalog stub — every concrete field is a placeholder dash; web-search summaries claiming finway has "Developer docs, API Reference, Webhooks, Sandbox, OAuth playground" are LLM hallucinations off that template and should be disregarded. The finway pricing and integrations pages contain no API reference of any kind; named integrations remain DATEV (one-way export), Personio (inbound employee sync), GetMyInvoices (inbound invoice fetch), and CSV/XML exports. GetApp's finway profile lists no API. apitracker.io stub, finway Pricing, GetApp: finway

What Orcha can READ: nothing programmatically — only manual CSV/XML export from the finway UI. What Orcha can WRITE: nothing programmatically — reference data (CoA, cost centers, tax codes, suppliers) is loaded via a one-time onboarding CSV template or maintained by hand in the UI. This directly disqualifies finway against the customer's stated "very good API for read AND write" priority — there is no API to read or write at all, at any plan tier, at any price. Cards still cannot be bought standalone — only bundled with the competing AP module (Section B).

D. Card Funding Model + Cards/App UX — Prepaid wallet (against customer preference); app is weak

Funding model — confirmed PREPAID, which is exactly what the customer does NOT want. The binding Paynetics terms are unambiguous: "Your Card is a debit card linked to your Account, it is not a credit or charge card." The account is e-money that must be loaded/topped-up via SEPA before use ("LOADING FUNDS TO YOUR ACCOUNT… minimum load amount… top up fee every time your Account is loaded"), and cardholders "must make sure that your Account has sufficient funds available to cover the amount of a given payment." finway's own cards page confirms a wallet is auto-assigned and topped up by bank transfer or standing order, and each transaction is debited from the finway Wallet. There is no charge-card option and no credit line anywhere in finway's offering. finway Company Cards, Paynetics AD terms, finway virtual cards blog

Cards UX. Decent but not a standout. Virtual + physical Mastercard Business Debit; virtual cards free and instant, physical €3/card/mo and ~6 working days to arrive. Reviewers praise easy card issuance and transparent spend control, but at least one Capterra reviewer flags "some debit cards not accepted by retailers" — a known limitation of prepaid debit acceptance vs a charge/credit card. Apple Pay is not documented (only Google Pay). finway Company Cards, Capterra finway reviews

Mobile app / receipt capture. This is a weak point per reviews. Capterra reviewers repeatedly describe the mobile app as "still work in progress," "buggy," "iOS App noch am Anfang," with "long loading times" and "could be more clearly organized." Receipt capture exists (mobile photo upload, auto-reminders to attach receipts, OCR) and works "once you learn the tips and tricks," but the OCR is flagged as inconsistent and automatic receipt matching was called "eine Katastrophe" by one CEO reviewer. For a customer whose core need is a polished mobile receipt-capture experience, finway's app does not currently lead. Capterra finway reviews, OMR Reviews: finway

Addendum Bottom Line

finway fails three of the customer's four updated priorities outright: no API (read or write — disqualifying), a prepaid wallet funding model (the customer explicitly wants a charge card / credit line), and a mediocre, work-in-progress mobile app. The cards product itself is adequate but unremarkable and carries prepaid-debit acceptance gaps. On defense it is AMBER (German hosting good; no BSI C5; Paynetics issuer carries an explicit weapons exclusion — same exposure as Payhawk). And cannibalization is HIGH — buying finway means paying to seat a direct AP competitor next to Orcha. finway should not be recommended to this customer.