iWallet API integration services (check deposit / OpenFinance)

1. Accounting / QuickBooks sync

Context: a home-service company closes books daily and wants card sales, tips, check deposits and fees in its ledger without re-keying. Data/API: the statement endpoint plus the settlement-batch webhook. OpenFinance mapping: a nightly job pulls /transactions and /settlements, maps each line to a GL account, and posts journal entries — the same "account information" pattern OpenBanking uses for read access.

2. Cash-flow forecasting for field crews

Context: dispatch needs to know when deposited check funds will actually land. Data/API: check-deposit status events and the payout-to-bank webhook. Mapping: ingest each deposit event, model the documented 2–3 business-day clearance window, and surface an "expected available" date per job and per crew — a confirmation-of-funds style read.

3. Payroll & tip distribution

Context: weekly payroll needs accurate tip totals per technician. Data/API: tip line items joined to sub-account ledgers. Mapping: aggregate by sub_account_id and pay period, then push the totals to the payroll provider over its API — iWallet sub-accounts act as the account-holder dimension.

4. Fraud / risk-control dashboard

Context: operations wants to watch the check-bounce rate and stop repeat offenders. Data/API: account-verification results plus check-rejected webhooks. Mapping: stream the events to a risk store, score by payer and routing number, and alert when a threshold is crossed — analogous to OpenBanking "confirmation of payee" checks.

5. Review automation after paid jobs

Context: marketing wants a review request to fire only after a job is paid. Data/API: the payment-completed event and the reputation-management module. Mapping: on payment_succeeded, trigger a review request, then log the response back against the transaction and technician for reporting.

1. Authenticate & create a Tap to Pay card sale with a tip

POST /api/v1/iwallet/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=...&client_secret=...
-> 200 { "access_token": "tok_...", "expires_in": 3600 }

POST /api/v1/iwallet/payments
Authorization: Bearer tok_...
Content-Type: application/json
{
  "sub_account_id": "tech_204",
  "amount": 18500,            // cents
  "currency": "USD",
  "tip_amount": 2500,
  "method": "tap_to_pay",
  "idempotency_key": "job-9921-cap"
}
-> 201 {
  "payment_id": "pay_7Hk2",
  "status": "captured",
  "card": { "brand": "visa", "last4": "4242", "auth_code": "0A1B2C" },
  "receipt_url": "https://.../r/pay_7Hk2",
  "created_at": "2026-05-12T14:03:11Z"
}

2. Submit a remote check deposit and poll status

POST /api/v1/iwallet/check-deposits
Authorization: Bearer tok_...
Content-Type: application/json
{
  "sub_account_id": "tech_204",
  "amount": 47200,
  "front_image_id": "img_a91",
  "back_image_id": "img_a92",
  "check_guarantee": true
}
-> 202 {
  "deposit_id": "chk_5512",
  "status": "pending_verification",
  "estimated_available_on": "2026-05-15"
}

GET /api/v1/iwallet/check-deposits/chk_5512
-> 200 {
  "deposit_id": "chk_5512",
  "status": "cleared",          // or "rejected" (+ reason_code)
  "verified_account": true,
  "settlement_batch_id": "set_3380"
}

3. Receive and verify a signed webhook

# iWallet sends JSON over HTTPS with these headers:
#   x-iwallet-topic: check_deposit.rejected
#   x-request-signature-Sha-256: <hex HMAC>

import hmac, hashlib, json

def handle(request, webhook_secret):
    raw = request.body  # bytes, do not re-serialize
    sig = request.headers["x-request-signature-Sha-256"]
    expected = hmac.new(webhook_secret, raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(sig, expected):
        return 400, "bad signature"
    event = json.loads(raw)
    topic = request.headers["x-iwallet-topic"]
    if topic == "check_deposit.rejected":
        flag_payer(event["payer_routing"], event["reason_code"])
    elif topic == "settlement.paid_out":
        post_settlement(event["settlement_batch_id"], event["net_amount"])
    return 200, "ok"

4. Export a statement for reconciliation

GET /api/v1/iwallet/statements?from=2026-04-01&to=2026-04-30
    &sub_account_id=tech_204&format=json
Authorization: Bearer tok_...
-> 200 {
  "period": "2026-04",
  "rows": [
    { "type": "card_sale",  "id": "pay_61", "gross": 18500, "fee": 480, "net": 18020, "tip": 2500 },
    { "type": "check",      "id": "chk_22", "gross": 47200, "fee": 0,   "net": 47200, "status": "cleared" },
    { "type": "refund",     "id": "ref_9",  "gross": -3200, "fee": -90,  "net": -3110 }
  ],
  "totals": { "gross": 62500, "fee": 870, "net": 61630 },
  "export_urls": { "csv": "https://.../st.csv", "pdf": "https://.../st.pdf" }
}

Deliverables checklist

• API specification (OpenAPI / Swagger) for the iWallet flows in scope
• Protocol and auth-flow report (OAuth / token / webhook signature chain)
• Runnable source for check-deposit, card-payment and webhook-receiver services (Python / Node.js)
• Automated tests, a Postman/HTTP collection, and API documentation
• Compliance guidance (PCI DSS scope, Check 21 / Reg CC, NACHA, retention and consent logging)

Engagement models

• Source code delivery from $300 — you receive runnable API source code and full documentation; pay after delivery once you are satisfied.
• Pay-per-call API billing — call our hosted iWallet integration endpoints and pay only per request, with no upfront cost; suited to teams that prefer usage-based pricing.
• Both models include a short hand-off session and 30 days of fixes for issues in the delivered code.

About us

We are an independent studio focused on fintech and open-data API integration. The team includes engineers who have worked on payment gateways, bank back ends, protocol analysis and cloud infrastructure, so we are comfortable with PCI DSS scoping, Check 21 image exchange, NACHA ACH rules and US money-transmitter expectations. We deliver end-to-end: protocol analysis, build, validation, documentation and compliance scaffolding — for App interface integration and authorized API integration projects across financial, e-commerce, travel and other categories.

• Payments, digital banking, lending and field-service back-office integrations
• Enterprise API gateways, webhook pipelines and security reviews
• Custom Python / Node.js / Go SDKs and test harnesses
• Documented, authorized data access only — no scraping of protected surfaces

Contact

For a quote, or to submit your target app and requirements, open our contact page. Tell us which iWallet data you need — check deposit status, Tap to Pay transactions, tip totals, sub-account ledgers or settlement batches — and we will scope it.

Contact page

Engagement workflow

1. Scope confirmation: which iWallet flows and data (check deposit, card payments, statements, webhooks, sub-accounts).
2. Protocol analysis and API design (2–5 business days, complexity-dependent).
3. Build and internal validation (3–8 business days).
4. Documentation, samples and test cases (1–2 business days).
5. First delivery typically 5–15 business days; third-party approvals may extend timelines.

FAQ

What do you need from me to start an iWallet integration?

How long does an iWallet API integration take?

How do you handle compliance and cardholder data?

Do you support pay-per-call billing instead of source code delivery?