Connect Check Mail accounts, eChecks, and ACH payouts to your accounting and ERP stack
Check Mail (com.checkmail.app, published by OnlineCheckWriter.com LLC) lets users mail digital checks via email from linked bank accounts, credit cards, and stored wallets. We deliver authenticated, OpenBanking-style APIs around that flow so finance teams can automate AP, reconcile payouts, and export statements without hand-keying check numbers.
- Transaction data — sent eCheck IDs, payee, amount, memo, status (issued/cleared/voided), funding rail.
- Account data — linked bank accounts (masked), card-funded sources, wallet balances, holder verification state.
- Mail-delivery data — recipient email, send timestamp, open/print events, signature capture for high-value checks.
Feature modules
Authenticated session bridge
Mirrors the Check Mail mobile login: device fingerprint, OTP, and refresh-token rotation. We expose /auth/login and /auth/refresh so you can keep an automated session alive for back-office jobs and reconciliation cron without re-entering credentials.
Send-eCheck endpoint
Wraps the email-delivery flow: payee email, amount, memo, funding source. Returns a check token, signed PDF URL, and delivery_status. Webhooks (echeck.delivered, echeck.viewed, echeck.cleared) feed your AP system the exact moment a vendor opens or deposits the check.
Statement & reconciliation
Pulls a date-ranged statement of issued and received checks across linked bank accounts and card-funded wallets. Supports paging, filtering by funding rail (ACH, card, wire), and exports to CSV for QuickBooks, Xero, or NetSuite import.
Account & wallet sync
Reads the list of linked bank accounts (masked), card sources, and wallet balances. Use this to pre-flight a payment run, prevent insufficient-funds bounces, and surface low-balance alerts in your treasury dashboard.
Multi-payee batch payout
One request, many payees: vendor list with amount, memo, due date. Useful for payroll or contractor disbursements where you would otherwise click "send" hundreds of times in the mobile app.
Compliance hooks
Each call writes a structured audit record (caller IP, consent reference, redacted payload digest). Auditors can pull the log via /audit/export without ever seeing raw check numbers or routing data.
Data available for integration
The table below lists the structured data Check Mail holds and how it maps to typical OpenData / OpenFinance use cases. Field names follow the conventions used by OnlineCheckWriter's public REST API at apiv3.onlinecheckwriter.com, where it has equivalents.
| Data type | Source screen / feature | Granularity | Typical downstream use |
|---|---|---|---|
| Issued eCheck | Send Check screen | Per check: id, payee, amount, memo, status, funding rail | AP automation, vendor payment confirmation, GL posting |
| Linked bank account | Accounts & Funding | Masked account, holder name, verification state, default flag | Pre-flight balance checks, KYC mirroring, treasury dashboards |
| Card & wallet source | Funding sources | Card brand, last4, expiry month/year, wallet balance | Funding rail selection, fallback rules, expense categorization |
| Statement entries | Activity / History | Per transaction line, paged, filterable by date and rail | Reconciliation against bank feed, monthly close, audit trail |
| Delivery events | Email Delivery log | Sent, delivered, viewed, printed, deposited timestamps | Vendor SLA tracking, dispute evidence, dunning workflow |
| Recipient address book | Payees | Email, name, optional postal address, default memo | CRM/ERP master-data sync, vendor onboarding |
| User & business profile | Settings | Business name, EIN/SSN-last4, holder match flag | Compliance checks, ACH enablement gating |
Typical integration scenarios
1. AP automation for SMBs
Context: a 50-person services firm pays 200 vendors monthly. Data/API: POST /echeck/send for each invoice, echeck.cleared webhook for status. OpenFinance angle: the same payment intent that originates in QuickBooks ends up as an ACH-cleared eCheck whose state is reflected back in the GL automatically, eliminating the manual "checks-in-the-mail" backlog.
2. Reconciliation against bank feed
Context: finance close at month-end. Data/API: GET /statement?from=2026-04-01&to=2026-04-30 joined to a Plaid or bank-direct feed by amount and check number. OpenFinance angle: the consumer-permissioned statement export mirrors what CFPB Section 1033 envisions for personal financial data rights, with redaction at the field level.
3. Treasury dashboard with multi-rail funding
Context: a holding company with three linked banks and two card programs. Data/API: GET /accounts + GET /balances, refreshed every 15 minutes. OpenFinance angle: the same account data surfaces in an OpenBanking AISP-style aggregator view, with funding-rail recommendations before a payment run is queued.
4. Contractor payroll batch
Context: weekly payout to 800 contractors. Data/API: POST /echeck/batch with an array of {email, amount, memo} objects, asynchronous job result polled via GET /jobs/{id}. OpenFinance angle: a single signed consent issues hundreds of Same-Day ACH-eligible payouts, mirrored to the GL by job id rather than per-check.
5. Audit and dispute evidence
Context: vendor claims non-payment. Data/API: GET /echeck/{id}/events returns the email delivery, view, print, and deposit chain. OpenFinance angle: the evidence pack is a portable record under regulator-friendly retention rules and feeds directly into a chargeback or arbitration package.
Technical implementation
Authentication (OAuth-style bearer)
POST /api/v1/checkmail/auth/login
Content-Type: application/json
{
"username": "ops@example.com",
"password": "<encrypted>",
"device_id": "dev-7c4...",
"otp": "493021"
}
200 OK
{
"access_token": "eyJhbGciOi...",
"refresh_token": "rt_8a2...",
"expires_in": 3600,
"scope": ["echeck.send","statement.read","accounts.read"]
}
Send eCheck via email
POST /api/v1/checkmail/echeck/send
Authorization: Bearer <ACCESS_TOKEN>
Idempotency-Key: 9f3d-2b1...
{
"funding_account_id": "ba_1029",
"payee": {
"name": "Acme Supplies LLC",
"email": "ap@acme.example"
},
"amount": "1450.00",
"currency": "USD",
"memo": "Invoice #A-2274",
"rail": "ach"
}
201 Created
{
"echeck_id": "ec_55f0...",
"status": "issued",
"pdf_url": "https://files.../ec_55f0.pdf",
"tracking": { "delivery_status": "queued" }
}
Webhook: delivery and clearing
POST https://your-app.example/webhooks/checkmail
X-Checkmail-Signature: t=1714512000,v1=...
{
"event": "echeck.cleared",
"occurred_at": "2026-04-30T14:02:11Z",
"echeck_id": "ec_55f0...",
"rail": "ach",
"settled_amount": "1450.00",
"fee": "0.50"
}
Error handling and idempotency
Every mutating endpoint accepts an Idempotency-Key header so retried payment requests never double-spend. Errors return a stable code field (insufficient_funds, holder_name_mismatch, rail_unavailable) and a retry_after hint for transient failures. The holder_name_mismatch case reflects the 2024 platform change requiring the business name to match the bank account holder for ACH enablement.
Compliance & privacy
Regulatory alignment
Check Mail's payment rails sit on top of the U.S. ACH network, so integrations follow Nacha's ACH Operating Rules, including Same-Day ACH cut-off windows and the WEB / TEL authorization requirements. For consumer-permissioned data export, our patterns are designed to be compatible with the U.S. CFPB Section 1033 personal financial data rights rule and with PSD2-equivalent consent records when European users are involved.
Data minimization
- Only the funding-account id is stored on our side; full account and routing numbers are never persisted.
- Email PII is hashed for analytics and kept clear-text only inside the send job lifecycle.
- Audit logs are append-only and segregated per tenant.
- Consent receipts are exportable as JSON for downstream auditors.
Data flow / architecture
The reference pipeline is intentionally simple:
- Client App (your back-office or mobile UI) issues a payment intent.
- Integration API (our Python or Node.js service) authenticates against Check Mail, signs the request, and applies idempotency.
- Storage persists the intent, the returned check token, and consent receipts in an append-only log.
- Analytics / API output exposes statement, status, and reconciliation reads to your GL, ERP, or BI tool.
Webhooks loop back from Check Mail to the integration API, which fans out events to the storage and analytics layers. No raw bank credentials ever cross the client boundary.
Market positioning & user profile
Check Mail is published by OnlineCheckWriter.com LLC (part of the Zil Money group) and is available on Android and iOS. Its primary users are U.S.-based small and mid-sized businesses, accounting firms, contractors, and landlords who still pay or get paid by check but want the operational profile of an electronic transfer. The product sits inside a wider digital-check market that has grown alongside Same-Day ACH; per Nacha, Same-Day ACH volume reached roughly $3.2 trillion in total value in 2024, and the global open banking market expanded from about $30.9B in 2024 to $38.9B in 2025. Integration demand therefore comes from finance teams who want one programmatic way to handle both check-by-email and ACH rails.
Screenshots
Click any thumbnail to view a larger version.
Similar apps & integration landscape
Teams that integrate Check Mail often work with one or more adjacent products in the digital-check and AP-automation space. The notes below are descriptive only; we treat each as part of the broader ecosystem rather than ranking them.
- OnlineCheckWriter — same parent product family as Check Mail; holds full check, payee, and ACH metadata and exposes a public REST API at
apiv3.onlinecheckwriter.com. Customers who use both often want a unified statement export. - Zil Money — sister platform with broader payroll, credit-card-funded checks, and bank-account management; useful when an integration must reach back to source-of-truth ledgers.
- Checkeeper — long-standing check-printing service whose users frequently migrate or run side-by-side; holds payee, signer, and check-stock metadata.
- Melio — AP-focused platform that pays vendors by ACH or check even when the vendor only accepts checks; relevant when the integration also needs cross-rail vendor data.
- Deluxe Checks — incumbent in printed-check supply with growing digital offerings; relevant for hybrid clients who still rely on pre-printed stock.
- AvidXchange — enterprise AP automation; holds approval-workflow and invoice metadata that complements check-issuance data.
- Dwolla — ACH-first payments API with strong webhooks; commonly paired when a team wants programmatic ACH alongside email-delivered checks.
- eMailACheck — direct competitor for emailed checks; users sometimes consolidate vendors and need a one-time history export.
- CheckMaker — desktop-leaning check writer; integration teams often migrate its archive into a Check Mail-style API workflow.
- Plaid Transfer — not a check app, but commonly co-deployed for instant bank verification before an eCheck is issued.
Users searching for any of the names above frequently end up needing the same primitives: send a payment, watch its lifecycle, reconcile the cleared amount, and export a clean statement to accounting software.
What we deliver
Deliverables checklist
- OpenAPI / Swagger specification for the integration surface
- Protocol and authentication report (token chain, OTP, refresh, device binding)
- Runnable source for login, send-eCheck, statement, and webhook handler (Python and Node.js)
- Automated tests with sandbox fixtures and contract checks
- Compliance guidance covering Nacha ACH rules, CFPB Section 1033 alignment, and PII minimization
About OpenFinance Lab
We are an independent studio focused on fintech and open-data API integration. Engineers on the team have shipped at U.S. banks, payment gateways, and protocol-analysis vendors, so the typical client conversation moves quickly from "what does the app expose?" to "what does your auditor want to see?"
- Payments, digital banking, AP automation, and cross-border clearing
- Custom Python / Node.js / Go SDKs and test harnesses
- Full pipeline: protocol analysis → build → validation → compliance
- Source code delivery from $300 — runnable code and full documentation; pay after delivery upon satisfaction
- Pay-per-call API billing — access our hosted Check Mail endpoint and pay only per call
Contact
To request a quote, share your sandbox credentials, or scope a Check Mail integration with us, open the contact page below.
Engagement workflow
- Scope confirmation: which Check Mail flows are needed (send, statement, webhooks, batch).
- Protocol analysis and API design (2–5 business days).
- Build and internal validation against sandbox accounts (3–8 business days).
- Documentation, sample integrations, and test cases (1–2 business days).
- First delivery: typically 5–15 business days; third-party approvals can extend timelines.
FAQ
What do you need from me to start a Check Mail integration?
How long does delivery take for an eCheck/ACH workflow?
How do you handle compliance and PII?
Can I pay per call instead of buying source code?
📱 Original app overview (appendix)
Check Mail (package id com.checkmail.app) is published by OnlineCheckWriter.com LLC, part of the Zil Money group. The app lets a user effortlessly manage and send checks via email from linked bank accounts, credit cards, and stored wallets, positioning itself as a secure, fast, and reliable payment alternative to traditional paper checks.
- Send digital checks (eChecks) via email to any recipient with an email address.
- Fund payments from bank accounts, credit cards, or stored wallets.
- Track delivery, view, and clearing status from inside the app.
- Manage payee address books, default memos, and recurring vendors.
- Recent platform change: the business name must match the bank account holder's name for bank verification and ACH enablement, tightening Nacha-aligned KYC checks.
- Privacy posture: per the Google Play listing, the app shares no data with third parties and collects no user data outside of payment delivery.
- Available on both Android (Google Play, package
com.checkmail.app) and iOS (App Store), targeting U.S.-based SMBs, accounting firms, contractors, and landlords.