Connecting iWallet payments, check deposits and payouts to your back office

Every iWallet sale leaves more than one server-side record, and they rarely agree at first glance. A card payment routes through Stripe and clears in near real time. A mobile check is photographed in the field, debited from the payer's checking account, and lands in the merchant's bank two to three business days later — about five for an electronic funds transfer, per iWallet's own FAQ. A field-service back office that wants one true revenue figure has to pull all of those, key each to the right technician, and reconcile them against what the bank actually funded. That reconciliation is the integration.

The data is real, structured, and per-account, and it spans two clearing timelines plus a per-technician split. We'd reach it through authorized interface integration against the merchant's own iWallet session, with native report exports kept as a fallback where they exist. The merchant authorizes it; we map it.

Where the money records live in iWallet

These are the surfaces a working iWallet account actually exposes to its operator, named the way the app presents them.

Getting to those records: the routes that apply

1 — Authorized interface integration of the merchant session

Reachable: everything the operator sees — settlement batches and the card and check items inside them, sub-account rollups, tips, risk decisions. Effort: a protocol-analysis pass on the authenticated session, then a stable client. Durability: good, with a watch on front-end change. We arrange the consenting account or sponsor sandbox with you and scope the read.

2 — User-consented scheduled credential access

Reachable: the same surfaces on a timer, for back offices that want a nightly pull rather than a live client. Effort: lower once route 1 is mapped. Durability: tied to the consent the merchant grants and can revoke.

3 — Native export as a fallback

Reachable: the report exports the app already produces, including the ADP- and Paychex-shaped tip files and dashboard transaction lists. Effort: low. Durability: limited to what the export format carries, so it supplements a live pull rather than standing in for it.

Route 1 is what we'd build on for iWallet. It sees every record the merchant sees and holds up across the gap between card and check clearing. Route 3 supplements it; it does not replace it.

A settlement pull, in pseudocode

Confirmed against a consenting iWallet merchant session during the build. The auth observed is an email and password exchange that yields a session cookie, then a short-lived bearer for the data calls.

session = iwallet_login(email, password)        # returns a cookie jar
token   = session.exchange_bearer()             # refreshed when a 401 appears

def settlements(since):
    page = 1
    while True:
        r = api.get("/merchant/settlements",
                     params={"from": since, "page": page},
                     auth=token)
        if r.status == 401:                      # bearer expired mid-pull
            token.refresh(); continue
        for batch in r.json["batches"]:
            yield normalize(batch)
        if not r.json["has_more"]:
            break
        page += 1

def normalize(batch):
    return {
      "batch_id":    batch["id"],
      "funded_on":   batch.get("funded_date"),   # null until 2-3 business days clear
      "state":       batch["status"],            # authorized | debited | funded | declined
      "sub_account": batch["sub_account_id"],    # one per technician login
      "card_items":  [{"amt": i["amount"],
                       "last4": i["card_last4"],
                       "via": "stripe"}           # full card number never requested
                      for i in batch["card"]],
      "check_items": [{"amt": c["amount"],
                       "decision": c["risk_decision"],   # real-time accept/decline
                       "nsf": c.get("nsf", False)}
                      for c in batch["checks"]],
      "tips":        batch.get("tips_by_employee", []),
    }

What lands in your repo

Each deliverable is tied to a surface above, not a generic checklist.

• An OpenAPI/Swagger spec covering the settlement, card-item, check-item, sub-account and tips reads.
• A protocol and auth-flow report: the login, session-cookie and bearer-refresh chain as it behaves on iWallet, with the 401 path documented.
• Runnable source for the key endpoints in Python or Node.js, including the normalize step that assigns the authorized / debited / funded / declined state.
• Automated tests, including a pending-settlement case and a declined-check case.
• Interface documentation and compliance and data-retention guidance written for card-plus-ACH data.

US payment rules the data sits under

iWallet's card path runs through Stripe, so cardholder data falls under PCI DSS — we take a token and the last four digits and never request the full card number. The check path is ACH plus an electronic check image, which brings in the Nacha Operating Rules and Check 21. There is a known open question here: the OCC's 2005 interpretive letter held that remote-deposit-capture deposits are not branch deposits, but the FRB and CFPB have not settled whether a check photographed on a phone is a branch or ATM deposit for Regulation CC funds-availability purposes, so we represent availability from the funded date rather than asserting a regulatory clock. Merchant financial data is also GLBA territory: the FTC Safeguards Rule has been in force since May 2023, and the FTC's stated position is that technology that facilitates financial operations can itself be a covered financial institution. Consent is merchant-granted, read-scoped to that merchant's own history, logged, data-minimized, and revocable, with an NDA where the engagement needs one.

Engineering calls we make on iWallet

Two clearing clocks. Card auths via Stripe settle fast; photographed checks and electronic funds transfers do not — two to three business days, about five for an EFT, per iWallet's FAQ. Every record gets an explicit state, and the funded state flips only when it reconciles against the bank deposit, so cash-flow figures never count money that has not landed.

Sub-accounts are the grain. Each technician has a separate login and reporting rolls up per sub-account, so we key every record to its sub-account id and rebuild the master rollup ourselves; a multi-crew merchant then reconciles exactly as iWallet's own daily, weekly and monthly reports do.

The risk decision is data, not noise. iWallet's real-time accept or decline and the $5 NSF flag on a returned check are carried through into the record we deliver, so a returned check is an actionable row rather than a silent gap. Access is arranged with you at the start — the build runs against a consenting merchant account or a sponsor sandbox, and we scope the read and the retention window with you as part of the work.

Cost and how the build runs

Runnable source for the iWallet endpoints you need is delivered in one to two weeks. You pay from $300 only after it is in your hands and you have run it against the records described here — source-code delivery, priced per scope, settled once you are satisfied. The other model is the hosted API: we run the endpoints, you call them and pay per call, with nothing upfront. Either way the merchant authorizes the access and we handle the setup with you. Tell us the app and what you need from its data on the contact page: openbankingstudio.com/contact.

Three things teams wire this into

• Accounting sync: a nightly pull of funded settlement batches, split by sub-account, posted to QuickBooks or Xero as deposits with card and check lines reconciled to the bank feed.
• Technician commission and payroll: per-sub-account daily rollups plus the tips-by-employee feed driving a commission engine and the existing payroll run, since the app already produces ADP- and Paychex-shaped tip files.
• Risk desk: the real-time check accept/decline and NSF flags streamed into an exceptions queue, so a returned check is chased the day it is flagged instead of at month-end.

Keeping the feed honest as iWallet changes

iWallet's front end moves the way any consumer app's does. The integration ships with a small set of canary checks that confirm the login chain, the settlement shape and the sub-account split still parse; a failed check updates the parser before the next scheduled pull rather than after a silent gap. Freshness is bounded by iWallet's own clearing — a funded state cannot be more current than the two-to-three-business-day deposit it reflects.

Screens this maps to

Public store screenshots, used here only to point at the surfaces named above.

Other field-payment apps in the same data space

Same category, each holding a comparable record set a unified integration would normalize against. No ranking, just the landscape.

• Square Point of Sale — in-person and online card sales, deposits and item-level receipts under one merchant login.
• Clover — card transactions, refunds and device-level reporting tied to its own settlement batches.
• PayPal Zettle — card and QR sales plus PayPal-side payout records for small merchants.
• SumUp — reader-based card sales and next-day payout history per merchant account.
• Helcim — a PCI Level 1 processor whose accounts carry card sales and, for banks on RTP or FedNow, next-business-day deposits.
• Stripe — the processor iWallet uses for cards; its own dashboard records charges, payouts and balance transactions.
• GoDaddy Payments — card sales and deposit records bundled with its commerce tools.
• Housecall Pro — a field-service platform with card processing, mobile check deposit, same-day Instapay deposits and QuickBooks reconciliation.
• Jobber — field-service software that records invoiced payments routed through Stripe, Square or PayPal.
• ServiceTitan — payments and job-level financials for larger trade contractors.

What was checked, and when

Checked in May 2026 against iWallet's own support pages and primary US payment-rule sources. The flow and timing facts — Stripe-routed cards, photographed check debit, two-to-three-business-day funding, the ~five-day EFT, the $5 NSF figure, ADP- and Paychex-shaped tip files — come from iWallet's published FAQ; the regime details from the FTC, Nacha and a remote-deposit-capture compliance reference.

Citations: iWallet FAQ · FTC — Gramm-Leach-Bliley Act guidance · Nacha — supplementing data security requirements · America's Credit Unions — RDC and Regulation CC

OpenBanking Studio integration desk — mapping reviewed 2026-05-16.

Questions integrators ask about iWallet

Which iWallet records can a back office actually receive — card sales, check deposits, payouts, or all of them?

All of them. iWallet keeps card sales routed through Stripe, photographed check deposits debited by ACH, the settlement batches that fund the merchant's bank, the per-technician sub-account rollups, tips by employee, and the real-time fraud accept or decline. We map whichever of those you need and key each record to its sub-account.

iWallet funds a business bank account in two to three business days. How do you represent money that's authorized but not yet in the bank?

With an explicit state on every record — authorized, debited, funded, or declined — instead of a single paid flag. Card auths and check debits clear on different clocks, about five business days for an electronic funds transfer per iWallet's FAQ, so the funded state is only set when it reconciles against the actual bank deposit.

Every technician logs into a separate iWallet sub-account. How do you keep those ledgers from blending together?

Each record carries its sub-account id, and we rebuild the master rollup ourselves so a crew of a dozen technicians reconciles the same way iWallet's own daily, weekly, and monthly reports do. Per-tech splits and payroll exports stay separable.

iWallet runs cards through Stripe and handles check images itself. Which US rules govern the data you'd be moving?

Card data sits under PCI DSS, which is why we take token and last-four only and never request the full card number. The check side touches Nacha's ACH rules and Check 21 for the electronic images, with the Regulation CC funds-availability question for phone-deposited checks still unsettled by the FRB and CFPB. Merchant financial data also falls under GLBA and the FTC Safeguards Rule. We work read-scoped, logged, and data-minimized within that.