Reaching the payment records behind Check Mail's emailed checks

Every check sent through Check Mail starts as an authorized debit against a linked bank account, card, or wallet and ends as an emailed payment the recipient can deposit. That round trip is the data worth integrating: who was paid, how much, from which funding source, and where the payment currently sits between sent and cleared. The app names itself on its Google Play and App Store listings as a way to manage and send checks via email; the records behind that flow are structured, per-user, and account-gated, which is exactly what a third party needs to query or sync.

We treat Check Mail as an authorized interface-integration target. You give us the app name and what you need out of it. We work out the request and response shapes its client exchanges with its backend, confirm them against a consenting account, and hand back runnable code plus a specification. The sections below name the surfaces, the route we would run, and what lands in your repository at the end.

What Check Mail keeps server-side

These are the surfaces an integrator would map. Each row is anchored to how the app actually works as a send-checks-by-email product, not a generic payments checklist.

How we reach it

Two routes carry most of this app, with a third covering the bank-side leg. Access and onboarding are arranged with you as part of the build, against a consenting account.

Authorized protocol analysis of the app client

We observe and document the HTTPS calls the Check Mail client makes after login: the token it carries, the device-session handling, and the create-check, list-checks, and status endpoints. This reaches the full issued-check ledger and its lifecycle because it reads exactly what the app reads. Effort is moderate; durability is good as long as we re-validate when the app ships a new client. This is the route we would actually run as the working path, because the check ledger and its statuses are the records most customers come for and they live behind these calls.

User-consented account access

With a consenting account holder, we mirror what they see in the app and confirm field meanings against live data. This is how we verify the protocol work and how we keep the integration honest about what each status value means. Low effort, high confidence, and it is the basis we lean on for the legal footing of the whole engagement.

Bank-side validation via consented account information

The settlement leg moves over ACH, and Nacha's WEB debit rules push originators toward validating the funding account. Where your use case needs the funding side confirmed, we integrate consented account-information access for the bank leg so a debit's status and the account's standing are checked directly rather than inferred. This complements the app-side ledger; it does not replace it.

If the app exposes a receipt or CSV export, we use it as a backstop for historical fills, though it would not carry live status the way the API calls do.

A worked call against the check ledger

Illustrative, in the shape we confirm during the build. The pattern is a short-lived bearer token from the login exchange, carried with a device-session header, then a status read over the issued checks. Field names are normalized to what we deliver, not guessed brand internals.

POST /v1/auth/token
{ "credential": "<user>", "device_id": "<session>" }
-> 200 { "access_token": "ey...", "expires_in": 1800,
         "refresh_token": "..." }

GET /v1/checks?status=in_flight&limit=50
Authorization: Bearer ey...
X-Device-Session: <session>
-> 200 {
     "checks": [
       { "id": "chk_8f3",
         "payee_email": "v***@acme.com",
         "amount": "420.00", "currency": "USD",
         "funding_ref": "src_bank_91", "memo": "INV-204",
         "created_at": "2026-06-03T14:11Z",
         "state": "delivered",            // sent|delivered|deposited|cleared|returned
         "ach_return_window_ends": "2026-06-09" }
     ],
     "next_cursor": "..." }

# normalized payment object we emit downstream:
# { check_id, payee, amount, source_type, state, settled_bool }

The two judgments that matter here: the token is short-lived, so the client refreshes it on a cycle we capture; and state is not the same as settled, because an ACH debit can be returned inside its window. Both are handled in the code we ship, not left for you to discover.

What lands in your repo

Concrete artifacts, each tied to a real Check Mail surface:

• An OpenAPI / Swagger description covering the auth exchange, the check-create and check-list calls, and the status read, with the normalized payment schema.
• A protocol and auth-flow report: the token chain, refresh cadence, and device-session header as they apply to this client.
• Runnable source in Python or Node.js for those endpoints, with paging, token refresh, and the sent-versus-cleared status logic wired in.
• Automated tests against recorded fixtures so a client change is caught early.
• Interface documentation plus data-retention and consent-record guidance for the payment data you will be holding.

Consent, rules, and how we operate

The payments here move over ACH, so the Nacha Operating Rules are the operative scheme, including the WEB debit account-validation requirements that push originators to confirm a funding account is real and open before debiting it. The dependable basis for the integration is the account holder's own authorization to reach their data; we build on that consent and keep records of it. The CFPB's Section 1033 personal financial data rights rule is the unsettled, forward-looking piece for US financial data access, not current law: a federal court enjoined its enforcement in late 2025 and the Bureau put it back into reconsideration, so we describe it as where access rights may head, not a framework you can rely on today. Access is authorized, the work is logged, the data is minimized to what your use case needs, and we sign an NDA where the engagement calls for it. Card and account numbers stay as tokens; we do not store raw funding credentials.

Engineering notes we account for

Two things about this specific app shape the build, and we handle both:

• Token rotation and device sessions. The client carries a short-lived token tied to a device session. We map the refresh exchange so a long-running sync re-authenticates cleanly instead of dropping when the token expires mid-run.
• The check lifecycle versus settlement. A sent check is not a settled one. We design status sync around the full lifecycle — sent, delivered, deposited, cleared, returned — and around the ACH return window, so your records never mark a payment final before it actually is.
• Plan-gated endpoints. The listing's update history mentions subscription renewal handling, so some endpoints likely require an active plan. We exercise those against a valid account during the build and document which calls depend on entitlement.
• Client-change resilience. When the app ships a new build that alters a call shape, we wire a re-check into maintenance so the integration is corrected before it silently returns stale data. Access for that is arranged with you during onboarding against a consenting account.

App screens we referenced

From the store listing, used to anchor the surfaces above. Tap to enlarge.

How this was checked

Worked through on 2026-06-07: the app's own store listings for what it does and how it funds checks, the Nacha rules for the ACH leg, and the current status of US data-access rulemaking. Primary sources, opened directly:

• Check Mail on Google Play
• Check Mail on the App Store
• Nacha Operating Rules — new rules (WEB debit account validation)
• CFPB — Personal Financial Data Rights reconsideration

Mapped by the OpenBanking Studio integration desk, June 2026.

Apps in the same payment space

Named for context and keyword reach, not ranked. Each holds comparable records and could sit behind one unified payment integration.

• Deluxe eChecks — emailed eChecks tied to a bank account, with issuance and tracking records.
• Checkbook.io — push payments where you enter a name, email, and amount, holding digital-check status.
• Online Check Writer — check printing plus eCheck and ACH, with a sizeable transaction history.
• Zil Money — ACH, wire, eChecks and printable checks under one account ledger.
• Checkeeper — check creation and mailing with stored payee and check data.
• Check Supply — an iOS app that mails physical checks after linking a bank account, with delivery status.
• Checkissuing — digital and printed checks plus ACH direct deposit, with statement automation.
• FiChecks — eChecks delivered by email alongside instant ACH transfers and bill management.

Questions integrators ask

Which Check Mail records can a status sync actually surface?

The issued-check ledger and its lifecycle: payee email, amount, memo, funding-source reference, send date, and the state each check sits in (sent, delivered, deposited, cleared, returned). The linked funding sources appear as tokenized references rather than raw card or account numbers. We map those surfaces to a normalized schema so a downstream system reads one consistent payment object regardless of whether the check was funded from a bank, card, or wallet.

How does the ACH settlement timeline shape a Check Mail status integration?

An emailed check that the recipient deposits settles over the ACH network, so a check is not final on the day it is sent. We design the status sync around that window, including the multi-day return period during which a debit can be reversed, so your records distinguish delivered from genuinely cleared instead of treating send-time as settlement.

What governs pulling Check Mail's payment data in the United States?

The money movement rides the ACH network under the Nacha Operating Rules, including the WEB debit account-validation requirements. The dependable legal basis for the integration itself is the consenting account holder's own authorization to access their data. The CFPB's Section 1033 personal financial data rights rule is the forward-looking piece here, not settled law: a federal court enjoined its enforcement in late 2025 and the Bureau reopened it for reconsideration, so we build on consumer consent and treat 1033 as where access rights may go.

Can you hand over the eCheck-issuance endpoints as runnable source?

Yes. The create-check, list-checks, and check-status calls come back as runnable Python or Node.js against the confirmed request and response shapes, with the token and device-session handling wired in, plus an OpenAPI description and tests. Turnaround is one to two weeks. Source-code delivery is paid only after you have it and are satisfied.

Pricing is plain. Source-code delivery starts at $300 and is paid after we hand it over, once the runnable endpoints, spec, tests, and docs are in your hands and you are satisfied; the build runs one to two weeks. Prefer not to host it yourself — call our endpoints and pay only for the calls you make, with no upfront fee. Send us the app name and what you want out of Check Mail's payment data and we will scope it: start a conversation.