Getting Capital on Tap transaction and rewards data into your stack

Over 200,000 small businesses run their spend through Capital on Tap cards, and across them more than $25 billion has moved over the program, per the company's own ten-year milestone post. Each of those accounts carries the same shape of data: a card transaction feed that settles daily, downloadable statements, employee sub-card limits, a one-point-per-pound rewards ledger, and the card-control state itself. That is the material a finance dashboard, an internal reconciliation job, or a spend-analytics product wants to read — and the app already proves the feed is machine-readable, since it pushes the same transactions into Xero, QuickBooks, Sage and FreeAgent every day through Codat's bank-feed pipe.

So the question is not whether the data moves. It is how to get a clean copy of it into your system, on your schedule, normalized the way you want. The route that reaches the widest surface is an authorized client against the app's own interface, with UK Open Banking consent layered in where you need a durable, regulated transaction read. Below is the data, the routes, and the runnable piece we hand over.

What the account actually holds

Mapped from the app's published feature set and its help material. Each row is a surface a consented client can read, not a hypothetical.

Three ways in, and the one we lead with

These are not equivalent. They differ in what they reach, how long they hold, and what we set up to run them.

Authorized interface integration

We map the app's own mobile and portal traffic under your authorization — the login and token-refresh chain, then the transaction, statement, rewards and card-control calls behind it. This is the only route that reaches the full surface, including the rewards ledger and card lifecycle, which a banking-data feed never carries. Durability is moderate: when the app changes its endpoints we re-map, and we build a check that flags the break early. Access is arranged with you during onboarding, against a consenting account.

UK Open Banking consent

For UK cards, the account balance and transaction read can run as a regulated Account Information read under UK Open Banking — the same framework the app describes in its own customer guidance. This is the most durable path for transactions and balances, with consent and revocation handled the regulated way. It does not see rewards or card controls, so it pairs with the interface route rather than replacing it. We register the access and stand up the consent flow as part of the build.

Native export and bank feed

The app already emits CSV and PDF statements and a daily accounting bank feed. For a one-off historical backfill or a low-touch sync, that export is the cheapest path, and we wrap it into the same normalized output. It is a fallback for bulk and history, not a live read of the richer surfaces.

For most teams the interface client is the spine — it is what brings rewards and card state through — and we layer the Open Banking read under it for UK accounts that need a regulated, long-lived transaction feed. US accounts lean on the interface route plus the cardholder's authorization, since WebBank issues those cards under a different arrangement.

The deliverable

You get code that runs against your own consented account, not a slide deck. In order of what we hand over first:

• A runnable client — a Python or Node.js SDK wrapping the transaction, statement, rewards and card-control surfaces, with the auth and session handling built in.
• Sync logic — cursor-based incremental pull, the ~90-day backfill on first run, and a normalized output schema so UK and US accounts come through the same shape.
• An automated test harness — fixtures over the real response shapes, so an endpoint change shows up as a failing assertion rather than a quiet gap in your data.
• The auth-flow and protocol report — the token/cookie chain and call sequence written down, so your team can maintain it.
• An OpenAPI description of the mapped surfaces, plus interface documentation.
• Data-retention and consent guidance — what gets logged, what gets minimized, and how the consent records are kept.

What the client looks like

An illustrative sketch of the delivered Python client. Field names are confirmed against the live response shapes during the build, not guessed here.

from cot_client import CapitalOnTapClient   # delivered SDK

client = CapitalOnTapClient(session=consented_session)  # auth handled in the auth-flow module

# Incremental pull of the card transaction feed
page = client.transactions.list(
    account_id=acct,
    since="2026-03-01",      # first run backfills the exposed ~90-day window
    cursor=last_cursor,      # resume from where the previous sync stopped
)
for txn in page.items:
    upsert(
        txn.id, txn.amount, txn.currency,
        txn.merchant, txn.posted_at, txn.card_last4,
        txn.status,                 # pending / settled
    )
save_cursor(page.next_cursor)

# Rewards is a separate surface — not part of the banking read
bal = client.rewards.balance(account_id=acct)
record_points(bal.points, bal.cash_equivalent)   # 1 point ≈ 1p, per their rewards guide

Normalized transaction shape

UK and US accounts, two issuers underneath, resolve to one record so downstream code never branches on market.

{
  "txn_id": "cot_8f2a…",
  "account_market": "GB",          // or "US" (WebBank)
  "amount": -42.50,
  "currency": "GBP",
  "merchant": "…",
  "card_last4": "1234",
  "status": "settled",
  "posted_at": "2026-03-14T09:21:00Z",
  "points_earned": 42             // null for US cashback accounts
}

Consent and the regulatory footing

UK card data, when read as an Account Information service, runs under UK Open Banking and the Financial Conduct Authority, with each request vetted against the Open Banking Directory — the model the app itself describes to its customers. Consent is explicit, scoped to the data domains you need, time-boxed, and revocable; we keep the consent records and design the read so a lapse re-prompts rather than failing silently. Capital on Tap appears on the FCA register under firm reference 625592 for consumer credit and 900922 as an e-money issuer, per its own legal pages; we verify the live registration at build time rather than relying on a cached number.

US cards are issued by WebBank, so the dependable basis there is the cardholder's own authorization to access their account. The CFPB's Personal Financial Data Rights rule could formalize that footing in time, but it is not in force today — enforcement is enjoined and the rule is back with the agency — so we treat it as a direction the work can follow later, not the law it rides now. Either way the access is authorized, logged, data-minimized, and covered by an NDA where the engagement calls for one.

Build notes specific to this app

Two things shape how we scope a Capital on Tap job, and both are handled on our side rather than asked of you.

Two issuers, one app. UK cards sit with Capital on Tap and US cards with WebBank, which means different auth behaviour and different endpoints behind the same screens. We map both paths and route each account to the right one, so a business with cards on both sides of the Atlantic gets a single normalized feed instead of two half-integrations.

Rewards is outside the banking scope. The points ledger — accrual at a point per pound, plus conversions into Avios, Virgin Points or cashback — never appears in an Open Banking read, because it is a loyalty surface, not an account one. We cover it through the interface client, so the redemption history lands alongside the transactions. We also design the sync around the daily settle and the roughly ninety-day history the app exposes: the first run backfills that window, then the client tracks the cursor forward.

How this was put together

Checked in June 2026 against Capital on Tap's own customer material and help pages, its US and UK newsroom posts, and the FCA's open-banking guidance, plus the public Codat and Plaid case studies that describe how the card feed is moved today. Where a number or a registration is stated above, it is attributed to the source it came from; anything not publicly confirmed is mapped at build time against your consented account.

• Capital on Tap — What is Open Banking
• Codat — Capital on Tap bank-feed case study
• FCA — Open banking and the FCA
• Google Play — Capital on Tap (com.cot.app)

Mapped and reviewed 2026-06-07 by OpenFinance Lab integration engineering.

Where it sits among similar tools

Same category, same kind of server-side spend data — useful when an integration has to span more than one card or expense platform. Listed for context, not ranked.

• Ramp — corporate cards plus expense and vendor-payment data in one platform.
• Brex — startup-focused corporate cards with transaction and spend records.
• Pleo — company cards with per-employee limits and receipt/expense data.
• Soldo — prepaid company cards with budget and transaction controls.
• Payhawk — cards, expenses and bill pay with a unified spend ledger.
• Expensify — cards plus expense, reimbursement and invoicing records.
• Moss — corporate cards and spend management for European businesses.
• Navan — travel and expense, formerly TripActions, holding trip and card spend data.

Questions an integrator tends to ask

Can you read the rewards points ledger, or only card transactions?

Both. Open Banking consent covers the card balance and transaction read, but the rewards ledger — points earned at one point per pound, plus redemption and conversion history into Avios, Virgin Points or cashback — only shows inside the app itself. We reach it through the authorized interface integration, so the points balance and the redemption events land in the same feed as the transactions.

How does the data stay current — does Capital on Tap push to us, or do we pull?

We design the ingestion as a pull on a cursor. The first run backfills roughly ninety days of history — the same window the app exposes to accounting tools — and after that the client requests only what changed since the last cursor, on a daily cadence that matches how the card feed itself settles. If you need closer-to-real-time card-control events, we can add a poll on a tighter interval for that surface.

Our UK and US cards are on one program — is it one integration?

It is one delivery, but two issuer paths underneath. UK cards are issued by Capital on Tap and the US cards by WebBank, which means different auth and different endpoints behind the same app. We map both and route each account to the right path, so a mixed UK and US estate comes through as one normalized feed.

Which regulator covers the UK transaction read?

For UK accounts the read runs under UK Open Banking, supervised by the Financial Conduct Authority, with every data request checked against the Open Banking Directory. For US accounts the dependable basis is the cardholder's own authorization; the CFPB's Personal Financial Data Rights rule may extend that footing later but is not in force today, so we do not build against it as settled law.

A first working client against the Capital on Tap surfaces typically lands within one to two weeks. We deliver the runnable source and documentation for a fixed fee from $300, which you pay only once the build is in your hands and working; or you skip the source entirely and call our hosted endpoints, paying per call with nothing upfront. Tell us the app and what you need out of it, and we sort the access and compliance with you — start at /contact.html.

Interface evidence

App screenshots, as published on the store listing. Click to enlarge.