Payhawk API Integration Research

Date: 2026-05-13 Product: Payhawk (payhawk.com) -- Spend Management Platform, London/Sofia Purpose: Evaluate Payhawk's API capabilities for Orcha integration -- specifically for a German customer evaluating Payhawk as a Pleo alternative for employee credit cards while continuing to use Orcha for AP invoices and DATEV for accounting.

Important Context: What Payhawk Actually Is

Payhawk is NOT an ERP or accounting system. Like Pleo and Moss, it is a spend management platform that handles:

• Corporate credit cards (physical + virtual, debit and credit-line)
• Supplier invoice capture & AP workflows ("Bill Payments" module)
• Employee reimbursements
• Pre-accounting (AI-powered expense categorization)
• Purchase-to-pay (PO management, 2-way/3-way matching)
• Business travel (hotels, flights)

Payhawk sits upstream of the ERP -- it captures, codes, and approves expenses, then exports pre-accounted data to the customer's actual accounting/ERP system (DATEV, NetSuite, Business Central, Sage Intacct, Xero, Exact, etc.).

Implication for Orcha: Payhawk is a peer (spend management) layer, not a target system to push invoices into. For the customer scenario in scope (Orcha = AP, DATEV = accounting, Payhawk = card programme), the integration question is narrower:

1. Can Orcha read card transaction data from Payhawk to provide unified spend analytics alongside its invoice corpus?
2. Can Orcha write reference data (chart of accounts, cost centers, tax codes, suppliers) into Payhawk so the customer's card-coding stays consistent with the AP coding Orcha already drives?

Both directions are technically feasible -- with significant nuances. See section 7.

1. Summary -- Capability Matrix

Overall assessment: Payhawk has a meaningfully better API posture than Pleo on three critical axes -- real-time webhooks, broad plan availability, and rate limits -- while DATEV integration is among the best in the category (native, bidirectional master-data sync via DATEV Cloud Services / Rechnungsdatenservice 1.0). Reference-data write is feasible but takes a different shape than Pleo: Payhawk models chart of accounts, cost centers, tax codes, and projects as Categories + Custom Fields rather than as separate first-class resources, and supplier/vendor write is the weakest area -- there is no documented POST /suppliers endpoint and suppliers are typically pushed in via the DATEV mapping flow or CSV import.

2. API Landscape

API Layers

Authentication

No OAuth 2.0 and no scoped tokens -- this is simpler than Pleo's OAuth client-credentials flow but means API keys are static long-lived credentials that grant broad access. Treat them as production secrets.

Rate Limits

• 15 requests per second per account
• Reported in ratelimit-* response headers
• Standard HTTP 429 on exceeded

For comparison, Pleo's limit is 600 requests/minute = 10 req/s, so Payhawk is slightly more permissive at the per-second budget. The 15 req/s ceiling is comfortable for incremental sync + webhook-driven reconciliation; a full bulk replay on a large account would need pagination + backoff.

API Categories

Confirmed via developer portal section index, help center, and Workato/Make connector inspection:

Recent (Summer 2025) Additions

Per the Summer 2025 release notes:

• Multi-entity API endpoints for categories and custom fields -- write reference data once for a group, not per entity
• Mark expenses / payments as exported via API -- closes the loop so they don't re-trigger downstream
• Contextual fund requests -- documents attachable on fund requests

Deprecation / Versioning

API is on v3. No public deprecation schedule surfaced. The v3 namespace appears stable; older versions are not referenced in current docs.

3. Write Capability Verification

Confidence: MEDIUM-HIGH. Payhawk's write surface is real and useful, but it is structured differently than Pleo's. Where Pleo has separate first-class resources for Vendors, Accounts, Tags, Tax Codes (each with full CRUD), Payhawk consolidates most reference data under Categories (chart of accounts) and Custom Fields (cost centers, projects, tax codes, locations, etc.) with a generic update API. Suppliers are the weakest area.

Confirmed Write Endpoints / Operations

Partial / Workaround Write

Key Limitations

• No invoice push to Payhawk via API. Invoices enter via:
  • Receipts Mailbox (unpaid@payhawk.me / paid@payhawk.me) -- up to 10 attachments per email
  • UI / mobile upload
  • Agent Fetch (Payhawk's own retrieval-bot product)
• No approval trigger / approve / reject via API. Workflow API is read-only.
• No supplier CRUD via API. Significant gap vs Pleo's POST /vendors, PUT /vendors, archive, etc.
• No card issuance via API. Card lifecycle handled in UI / banking layer.

4. iPaaS & Middleware Findings

Workato is the best iPaaS path if Orcha or a customer wants no-code orchestration. The two real-time triggers (New expense, Updated expense) mirror Payhawk's webhook events and are the same primitives we'd build against directly. For anything beyond expenses (categories write, custom fields write, webhook subscription management), even Workato users will need the HTTP connector. The Zapier gap is real -- customers used to Pleo-on-Zapier will not have parity.

5. Alternative Channels

DATEV Integration (Native)

This is Payhawk's strongest non-API channel and a major advantage vs Pleo for German customers.

Implication for Orcha-in-customer-stack: If the customer connects Payhawk directly to DATEV DUO, the chart of accounts, tax codes, and cost centers will flow DATEV -> Payhawk natively -- meaning Orcha does NOT need to push CoA/tax/cost-center reference data into Payhawk in that configuration. Orcha would still need to push supplier mappings (External ID alignment) if Orcha is the authority for vendor master data, since DUO can't auto-sync those. See section 7 for the recommended split.

Native ERP/Accounting Integrations

Confirmed list (non-exhaustive):

HRIS Integrations (30+)

Workday, ADP, Gusto, BambooHR, Deel, Paycor, Personio, Hibob, etc.

Webhooks

CSV Exports

• Multiple ERP-specific CSV templates (Sage, SAP, others)
• Bulk supplier import/export
• Custom CSV builder

6. Licensing & Access Requirements

API Access

Payhawk API is free on all plans. This is the headline differentiator vs Pleo.

"Free to use across all Payhawk accounts" -- payhawk.com/integration/api

There is no API-gated tier and no per-call fee. The 15 req/s rate limit applies uniformly. Any paying Payhawk customer can issue API keys via Settings > Integrations.

For comparison: Pleo gates Open API access to the Advanced plan ($109/mo+).

Plan Pricing (Module-Based)

Payhawk priced per module + per admin/accountant seat + per card + by transaction volume, NOT per-user. Employee seats are unlimited on every plan.

Every module includes: unlimited employee seats, OCR data extraction, advanced workflow approvals, multi-entity environment, live accounting integrations, custom exports, HRIS integrations, security/SSO, and developer API access.

Pricing model differences vs Pleo:

• Payhawk: module-based, flat-rate per module, unlimited employee seats
• Pleo: per-user (Essential $45, Advanced $109, Beyond $219) with API gated to Advanced+
• For a German company with 30 cardholders: Payhawk Cards & Expenses is ~$449/mo flat; Pleo Advanced is ~$45 base + 27 users × ~$11-18 = ~$340-540/mo
• Crucially: API and webhooks are included on Payhawk's entry-level Cards & Expenses plan, while Pleo requires the Advanced upgrade

Customer Setup Checklist

1. Customer needs any paying Payhawk plan (Cards & Expenses is the relevant one for this customer)
2. Admin / IT Admin / privileged custom role navigates to Settings > Integrations
3. Use Primary/Secondary auto-generated key, or create a custom key
4. (Optional but recommended) Set up DATEV DUO connection if customer wants Payhawk -> DATEV direct -- see section 5
5. Subscribe to webhook events (expense.created, expense.approved, etc.) pointing at Orcha endpoint
6. Implement RSA/SHA-256 signature verification using Payhawk's public key

7. Orcha-Specific Deep Dive

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

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

Payhawk and Orcha have overlapping functionality in the AP module of Payhawk -- but the customer scenario in scope explicitly excludes Payhawk's Bill Payments module. The split is clean:

So with the Bill Payments module off, Payhawk's responsibility is cards + reimbursements + their export to DATEV, and Orcha's responsibility is AP invoices + their export to DATEV. The two streams converge in DATEV, not in either spend tool.

Integration Scenarios for the Customer

Scenario A: Orcha reads card transaction + expense data FROM Payhawk for unified spend analytics (PRIMARY USE CASE)

• Feasibility: HIGH
• Subscribe to expense.created / expense.approved webhooks -> Orcha endpoint
• On event, GET /api/v3/accounts/{accountId}/expenses/{expenseId} for full detail
• Optionally GET /api/v3/accounts/{accountId}/expenses/{expenseId}/workflow for approver chain
• Optionally pull raw card-tx feed via Fund Accounts endpoint (settled card transactions, ATM/FX fees, bank statements) -- this catches transactions BEFORE the user reviews them in Payhawk, useful for early-stage analytics
• Pull document URLs (document.files[].url) for receipt access -- BUT verify URL TTL before designing whether to mirror documents into Orcha S3 or fetch on-demand
• No invoice push back to Payhawk needed

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

• Feasibility: MEDIUM-HIGH, with one caveat
• If customer connects Payhawk directly to DATEV DUO: chart of accounts and tax codes flow DATEV -> Payhawk automatically, so Orcha does NOT need to write them. Cost centers (KOST1/2) need to be set up in DATEV first; once they are, they also sync down.
• Where Orcha can add value: writing supplier mappings, since DUO can't auto-sync suppliers. Orcha (as the AP authority) likely has the canonical supplier list with DATEV External IDs. Push these to Payhawk so any future Payhawk invoice-via-card-charge can be matched. Workaround: bulk supplier CSV import + External ID column; no native POST /suppliers API.
• Cost centers / projects: if customer wants Orcha-coded cost-center taxonomy mirrored to Payhawk for card coding, use the Custom Fields API to create/update predefined-list values.

Scenario C: Customer migrates AP from Orcha to Payhawk's Bill Payments module

• NOT relevant for this customer scenario. Customer keeps Orcha for AP.

Scenario D: Orcha pushes invoices into Payhawk

• NOT POSSIBLE via API -- no POST /invoices endpoint. Email-to-Mailbox (unpaid@payhawk.me) would work as a hack but is irrelevant since customer doesn't want this anyway.

Key API Differences vs Pleo

Receipt URL Longevity -- Action Required

The single most important unverified question for the customer scenario is: do receipt URLs returned by GET /expenses persist, or do they expire like Pleo's 24h ones? Public docs do not state a policy. Our recommendation:

1. Before committing engineering effort, the Orcha team should run an authenticated probe against a Payhawk test/sandbox account: fetch an expense, capture the receipt URL, then attempt re-fetch at T+1h, T+6h, T+24h, T+72h, T+7d.
2. If TTL is short (Pleo-style 24h): Orcha should mirror documents into its own object storage at webhook time -- same pattern we'd use for Pleo.
3. If TTL is long (multi-day or non-expiring): Orcha can rely on Payhawk-hosted URLs and skip mirroring.

The URL field is explicit and documented (document.files[].url), and the receipt is a first-class object (multiple files per expense supported, with id, url, contentType), so retrieval mechanics are clean -- only the TTL is ambiguous.

Orcha Integration Capability Summary

8. Recommended Path Forward

Assessment: Payhawk is a Strong Coexistence Partner for Orcha in This Customer Scenario

Unlike Pleo, where API gating + monthly export cadence + 24h receipt expiry make a clean real-time integration painful, Payhawk's posture is fundamentally compatible with how Orcha wants to operate:

• Webhooks are real-time and free.
• API access is on all plans, including the entry-level $449/mo Cards & Expenses module.
• DATEV is the deepest native target in the category -- which means Orcha and Payhawk can both write to DATEV independently and let DATEV be the source of truth for accounting, without needing to coordinate at the spend-tool layer.

Recommended Architecture

[Card transactions]            [Vendor invoices]
       |                              |
       v                              v
   Payhawk  -- real-time webhook -->  Orcha (read-side: unified spend analytics)
       |                              |
       v                              v
     DATEV  <----- shared books ----- DATEV

Read side (Payhawk -> Orcha):

1. Subscribe webhook to expense.created and expense.approved
2. On event, GET /expenses/{id} -- pull amount, FX, merchant, category, custom fields, employee, card metadata, document URLs
3. GET /expenses/{id}/workflow for approver chain
4. (Optional) periodic GET /expenses?reviewedAt>... reconciliation sweep against missed webhooks
5. (Optional) Fund Accounts endpoint for raw card-tx pre-review
6. Mirror documents to Orcha storage at webhook time (default-safe pending TTL probe)

Write side (Orcha -> Payhawk):

1. If customer connects Payhawk directly to DATEV DUO: write nothing initially -- DATEV is the master, syncs both ways naturally. Verify CoA + tax + KOST mapping is clean.
2. If customer has supplier master in Orcha that needs to land in Payhawk for matching: push via supplier CSV import (manual or scripted) with External ID column. Revisit if Payhawk releases a public POST /suppliers.
3. (Optional, advanced) If customer wants specific custom fields populated in Payhawk that aren't in DATEV (e.g., Orcha-specific cost-center taxonomy), use Custom Fields API to create the field definition and populate values.

When Payhawk Integration Makes Sense

1. Customer migrates off Pleo for cards/reimbursements onto Payhawk: ALL the Pleo gaps that drove the move (realtime, API tier, DATEV depth) are resolved by Payhawk.
2. Unified spend reporting requirement: Webhooks + structured expense API make this a clean read-side integration.
3. Multi-entity German group with DATEV across entities: Payhawk's multi-entity API endpoints (Summer 2025) + DATEV native bidirectional integration give the customer a one-stop card-to-DATEV flow.

What NOT to Build

• Invoice push to Payhawk: Not possible via API; not needed for this customer anyway
• Approval workflow automation in Payhawk: Not API-accessible
• Replacing Payhawk's DATEV integration: It's already best-in-class via DATEV Cloud Services

Architecture Decision

Pre-Implementation Verification Needed

Before any engineering commitment:

1. Probe receipt URL TTL in a Payhawk sandbox -- see section 7
2. Enumerate the full webhook event catalog (cards, transactions, expenses, payments, reviews) by reading the authenticated developer portal -- this is JS-rendered SPA and not scrapable from public web
3. Confirm Fund Accounts endpoint schema for raw card-tx feed vs expense-level data -- which is better for pre-review analytics
4. Confirm whether POST /suppliers exists in a non-public partner-only namespace -- Payhawk has a Partner Program (payhawk.com/partner-program) that may expose richer endpoints than the public dev portal

Recommendation Summary

For the customer scenario (DATEV + Orcha + Pleo replacement with Payhawk for cards): YES, integrate. The read-side path is genuinely clean -- real-time webhooks, included API, deep field coverage. The write-side path is narrower than Pleo's CRUD but sufficient because DATEV does the heavy lifting for accounting reference data. Suppliers are the one gap to call out to the customer (and to mitigate via CSV import + External ID).

Payhawk is materially better than Pleo on the three critical gaps that prompted this evaluation:

1. Realtime: solved with webhooks
2. API pricing tier: solved (free on all plans)
3. Receipt URLs: TBD -- needs empirical verification, but no public claim of a 24h expiry exists, so default expectation is better-than-Pleo

9. Sources

Official Documentation

• Payhawk Developer Portal -- interactive API reference (JS SPA; partially accessible from public web)
• Payhawk Developer API Overview (Help Center)
• FAQ on Payhawk Developer API
• Payhawk for Developers (Help Center hub)
• Payhawk API on apitracker.io
• Payhawk GitHub organization -- mostly forks; one per-diem cloud function example

API & Webhook Details

• API for advanced spend management integrations -- confirms base URL https://api.payhawk.io/api/v3, 15 req/s, free on all plans, RESTful, real-time webhooks
• Mastering Webhooks for Efficient Financial Data Integration -- expense.created example, retry behaviour on 408/409/429/500+, SHA-256/RSA signature verification

DATEV Integration

• Native DATEV integration (Payhawk)
• Connecting Payhawk to DATEV Unternehmen Online (DUO) -- wizard, account mapping, KOST1/2, RDS 1.0
• How and why to integrate Datev Duo with spend management
• Exporting Expenses and Payments to DUO -- auto-export on review/settle, External ID mapping
• Sharing Suppliers between Payhawk and DUO -- confirms DUO cannot auto-retrieve suppliers; External ID workflow
• DATEV (Payhawk DATEV collection)

Reference Data & Custom Fields

• Creating, editing, and deleting custom fields
• Enrich your data with custom expense fields
• Custom Expense Fields blog
• Updating Custom Fields from Exact Online -- ERP-to-Payhawk reference data pattern
• Supplier Management -- bulk import/export, ERP sync

Integration & Release Notes

• Payhawk Integrations -- ERP / accounting / HR / no Zapier-Make-Celigo
• Expense Management Integrations
• Summer 2025 release edition -- multi-entity API endpoints, mark-as-exported API, card workflow improvements
• Release Notes (recent) -- Pennylane (Dec 2025), Sage Intacct (Jan 2026), Business Central (Jan 2026), Xero (Feb 2026)

iPaaS Connectors

• Payhawk on Workato -- 2 triggers + 3 actions (New/Updated expense, Get/Update expense, Custom action)
• Payhawk on Make (community) -- community integration by MAXMEL Tech

Pricing & Plans

• Payhawk Pricing & Plans -- Travel $299, Cards & Expenses $449, Bill Payments $349, Procure to Pay $499
• Payhawk Pricing 2026 (G2) -- Cards & Expenses higher-tier cited at $699
• Payhawk Pricing 2026 (Capterra)

Reviews & Comparisons

• Payhawk vs Pleo (Capterra)
• Pleo Alternative (Payhawk marketing)
• Payhawk on G2
• Payhawk on Capterra

Partner & Card Details

• Payhawk Partner Program
• Issuing virtual cards
• Issuing Physical Cards for Administrators
• Why are the last 4 digits of my card different on the invoice?

Document / Receipt Handling

• Overview of the Receipts Mailbox
• Managing receipts and invoices in the portal
• Automating Receipt And Invoice Retrieval With Agent Fetch

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

Supplementary research for the German defense-sector customer assessment (companion to 2026-05-14-qonto-vs-pleo-defense-customer-assessment.md). Updated customer priorities: must handle employee credit cards extremely well, needs a strong mobile receipt-capture app, needs a read+write API, and prefers NOT prepaid (wants a charge card / credit line, not a top-up wallet).

1. Defense-Sector Posture — Verdict: AMBER

2. Cannibalization Risk vs Orcha — Verdict: MEDIUM (trending MEDIUM-HIGH)

Payhawk does overlap with Orcha — more than Pleo, less aggressively than Qonto, but the trajectory is the concern.

• Overlap is real and named. Payhawk markets a full Accounts Payable product: AI-driven invoice OCR in 60+ languages, "zero-touch invoice processing," multi-step approval workflows, 2-way and 3-way matching, vendor management synced to ERP, and payment execution across 115 currencies / 150+ countries. That is squarely Orcha's lane. (payhawk.com/en-us/accounts-payable)
• The customer scenario contains it — for now. The customer keeps Orcha for AP and would buy only Payhawk's Cards & Expenses module (Bill Payments is a separate paid module). With Bill Payments off, the split stays clean. But the AP product is one upsell click away, and Payhawk's sales motion is consolidation.
• Trajectory points the wrong way. Payhawk is a unicorn raising toward a ~$2bn valuation, publicly committed to an M&A "shopping spree" (CEO told CNBC/PYMNTS, 2024) targeting Series-A startups, and shipping "AI Office of the CFO" agents — including a Financial Controller Agent that auto-retrieves invoices/receipts (Spring 2026 edition, 93% capture accuracy). The product investment is flowing toward invoice automation, not away from it.
• Why not HIGH: unlike Qonto (which already owns Regate, a full AP/AR platform), Payhawk has no completed AP acquisition and its AP module is sold separately rather than bundled-by-default. The overlap is a module the customer simply doesn't have to buy.
• Why not LOW: the capability exists in the product today, it is actively being deepened with AI agents, and Payhawk's whole pitch is "one platform for all spend." A buyer who sees Payhawk's AP module and DATEV export may question why they run Orcha separately. Net: MEDIUM, with a realistic path to MEDIUM-HIGH over 12–24 months.

3. API Read/Write Refresh (re-verified 2026-05-14)

No material regressions since the 2026-05-13 doc; one positive signal. Base API still https://api.payhawk.io/api/v3, 15 req/s, API free on all plans.

Orcha can READ: expenses/transactions (GET /accounts/{accountId}/expenses, paginated 1000/page, filterable) incl. amount/FX/merchant/category/custom-field values; individual expense detail; receipts/documents (inline files[] array with id/url/contentType, multiple per expense — URL TTL still not publicly documented, still needs an empirical probe); approval workflow (/expenses/{id}/workflow, approver names + status, read-only); raw card-tx feed via Fund Accounts bank-statement endpoint (tx type, currency, FX, fees). Employees and card-metadata endpoints remain thinly documented publicly — confirm in the authenticated portal.

Orcha can WRITE: custom fields — full CRUD on definitions and values (the primary mechanism for cost centers, tax codes, projects); categories / chart of accounts — create/update incl. multi-entity endpoints (Summer 2025); create bills / reimbursable / cash expenses (not card expenses); mark expenses/payments as exported (Summer 2025); webhook subscription CRUD. Suppliers/vendors remain the weak spot — still no clearly documented public POST /suppliers; however the webhook catalogue now lists a supplier.updated event, implying suppliers are at least a first-class object internally, so a write endpoint may exist or be near — worth a direct check with Payhawk. Workaround unchanged: bulk CSV import + External ID, or DATEV DUO sync.

Webhooks: real-time confirmed, ~20 event types incl. expense.created, expense.approved, payment.settled, supplier.updated; HTTPS POST, RSA/SHA-256 signed, retries on 408/409/429/5xx. Real-time capability holds.

4. Card Funding Model + Cards/App UX

Funding model — this is the strong fit for the customer's "NOT prepaid" requirement. Payhawk offers a genuine revolving credit card / credit line in the EEA (incl. Germany), not just a prepaid wallet:

• Credit card / credit line: Payhawk itself underwrites the credit (risk analysts, ~24 business-hour decision). Eligibility: limited company in UK/EEA, min. €250k annual turnover, Year-1 accounts filed; credit up to €500k. Monthly billing cycle — utilised credit is repaid by the 8th of the following month via bank transfer from the company's bank account (not auto-debit); non-payment by the 8th suspends the accounts. Marketed as interest-free for up to 38 days. This behaves like a charge card / monthly-settled credit line — exactly what the customer wants (spend now, settle monthly from the bank account, no wallet to top up).
• Debit option also exists (linked to a pre-funded Payhawk funds account = the prepaid model the customer wants to avoid) — and admins can switch a card between debit and credit funding even after issuance. So the customer can run pure credit and never touch the prepaid mode.
• Caveat: the credit line is underwritten by Payhawk and gated on the €250k turnover / filed-accounts test — fine for an established defense company, but it is an application/approval step, and credit availability/limit should be confirmed for the specific entity.

Cards & app UX — solid, not flawless. Aggregate user-satisfaction ~92% across G2/Capterra (~930 reviews); Payhawk is a G2 Leader and Momentum Leader in expense management. Physical cards (plastic + metal) ship in ~5 business days; issuing cards is praised as fast. Mobile receipt capture is a core strength — "snap a photo, system extracts the data instantly," AI auto-suggests the account code. Documented gripes: receipt scanner accuracy/responsiveness is "could be better," the email-receipt matcher doesn't always match, occasional post-update technical glitches, limited reporting, and physical cards don't print the in-app card name (confusing with multi-entity setups). Net: a credible, mobile-first cards + capture product that clears the customer's bar, with minor rough edges typical of the category.

Addendum Sources

• Payhawk Terms & Conditions ; Terms of Use (legacy)
• Payhawk Trust Portal ; Payhawk Security
• Paynetics General Terms and Conditions
• Payhawk Financial Services UAB — Bank of Lithuania ; Payhawk Financial Services UAB profile — TheBanks.eu
• Payhawk obtains EMI licence
• Applying for Payhawk credit lines and credit cards (UK/EEA/US)
• Customisable credit and debit cards ; Prepaid vs Credit vs Debit corporate cards
• Payhawk Accounts Payable ; Spring 2026 edition
• Payhawk plans M&A spree after 86% growth — CNBC ; Payhawk Looks to M&A — PYMNTS
• Payhawk eyes $2bn valuation — Crowdfund Insider
• Overview of the Payhawk Developer API
• Payhawk Reviews — G2 ; Payhawk Reviews — Capterra
• Issuing Physical Cards for Administrators ; Unsupported card transactions