Card activity, statements and rewards from one Imprint account

Behind an Imprint login sits one revolving-credit account that may be running any of the brand programs Imprint operates — Shell, Rakuten, Booking.com, the Fetch American Express card among them, per imprint.co. Each program carries its own earn-and-redeem rules on the same account skeleton. The data a partner usually wants out of it is unglamorous and well-bounded: posted and pending card transactions, the monthly statement, the running balance and credit line, the rewards ledger, and the state of scheduled payments. This page describes how we reach that data under the cardholder's authorization and what we hand back.

The short version: this is a clean account-data target. One member can hold exactly one Imprint card program at a time, the records derive from an append-only ledger, and the surfaces a third party cares about are stable. We build a client that signs in to a consenting cardholder's account, walks the activity as an event stream, pulls each statement cycle, and reads the rewards ledger with its program context attached. The work that earns its keep is not the fetch — it is reconciling pending against posted and mapping reward rules that change from one brand program to the next.

What an Imprint account actually holds

Every row below maps to something a cardholder can see in the app, traced back to where it originates in Imprint's own services.

How the session and the ledger fit together

Imprint's engineering write-up is unusually frank about its internals, which makes the integration legible before a single packet is captured. Authentication is brokered by a service the company calls Passport (one-time code, then PIN or biometric, then a JWT). Transactions and their derivatives — balance, statements — come out of a Ledger service backed by an immutable store, so the activity reads naturally as an event log you can replay rather than a mutable table you have to diff. Notifications run through a queue (the company names Amazon SQS), which is why an event-then-pull design fits this app rather than fighting it. The snippet is illustrative; exact paths and field names are pinned down during the build against a consenting account.

# Illustrative. Field and path names are confirmed during the build
# against a consenting cardholder account.
#
# Auth is brokered by Imprint's Passport service: OTP -> PIN/biometric -> JWT.
# Activity and statements derive from an append-only ledger (Imprint Tech
# describes an immutable Amazon QLDB store), so we read activity as a stream.

session = passport.verify_otp(device_id, code)     # -> { access_jwt, refresh, member_id }
headers = {"Authorization": f"Bearer {session.access_jwt}"}

# Walk card activity as a replayable event stream, advancing a cursor by event id.
cursor = store.last_event_id(session.member_id)    # None on the first backfill
while True:
    page = client.get("/account/activity",
                      params={"after": cursor, "limit": 200},
                      headers=headers).json()
    for ev in page["events"]:
        # ev: { id, posted_at, status, merchant, amount_cents,
        #       program_id, reward_accrual_cents, pending }
        ledger.upsert(ev["id"], ev)                # keyed on the ledger event id, so a
        cursor = ev["id"]                          # pending auth and its later posting
    if not page["has_more"]:                       # land on one record, not two
        break

# Statements are cycle rollups read off the same ledger.
stmt = client.get(f"/statements/{cycle_id}", headers=headers).json()
# stmt: { closing_balance_cents, min_payment_cents, due_date, program_id, document_url }
      

A normalized shape worth standardizing on

Whatever the wire format turns out to be, we hand you a normalized record so downstream code never has to care which co-brand program a card belongs to. Two examples:

// transaction
{
  "txn_id": "imp_evt_...",        // = ledger event id, the dedupe key
  "program": "rakuten",            // which co-brand program this account runs
  "posted_at": "2026-05-30T14:02:11Z",
  "status": "posted",              // pending | posted | reversed
  "merchant": "...",
  "amount": { "value": -42.18, "currency": "USD" },
  "rewards": { "accrued": 0.84, "unit": "USD" }
}

// statement
{
  "cycle_id": "2026-05",
  "program": "rakuten",
  "closing_balance": 318.40,
  "minimum_due": 25.00,
  "due_date": "2026-06-25"
}
      

Getting to the data — and which path we take

Consented interface integration

We sign in to a consenting cardholder's account and integrate against the app's own authenticated session: Passport for the token, the activity and statement surfaces for the records. This reaches everything a cardholder can see, at full fidelity, and it is what we anchor on. Access to a test account is arranged with you at the start; the build then runs against that account.

User-consented session access in production

For an ongoing feed, the cardholder authorizes access and we hold no standing credentials of our own. Sessions are short-lived JWTs, so re-authentication is part of the flow rather than an afterthought. This is the durable wrapper around the route above.

Native export as a thin fallback

The app shows statements a user can save, but reviewers note it does not export transactions into money-management tools, so the in-app export is limited. We treat it as a backstop for documents, not a feed.

For a build today, the consented session route carries the most and degrades the least, so we put the client there and let the production consent flow wrap it. The regulated open-banking path, below, is where this may go later — not what we lean on now.

What lands in your repository

The headline deliverable is code that runs, not a folder of documents:

• Runnable client in Python and Node.js — session bootstrap through Passport, cursor-based activity pull, statement fetch, rewards read, all against a consenting account.
• Stream consumer with replay — the activity feed modeled as an append-only event stream, deduplicated on the ledger event id, with a backfill mode that can be re-run safely.
• Notification-triggered sync — a handler that reacts to the app's own push/email/text events (Imprint's Messenger queue) and pulls the delta, so you are not polling blind.
• Automated test suite — fixtures for the states that actually bite: a pending authorization becoming posted, a statement closing, a reward accruing then redeeming.
• An OpenAPI description of the surfaces we exercise, and a protocol & auth-flow note documenting the OTP → PIN → JWT chain.
• Interface documentation and a short data-retention and consent-handling note for your compliance file.

Things this build has to get right

These are the parts we plan for up front, because they are specific to how Imprint is put together.

One account model, many program rule sets

A single login can be running the Shell program or the Rakuten program or the Fetch Amex card, and the earn-and-redeem logic is not the same across them. We read the program identifier on each account and map its reward rules, so two cardholders on different programs are both read correctly from one client rather than silently mismeasured.

Pending versus posted, and slow payments

Because records derive from an immutable ledger, an authorization first appears pending and later posts as a related event. We key on the ledger event id so the two collapse into a single record on replay. Payments are their own case — cardholders report posting taking several business days after the app confirms receipt — so payment state is tracked as a lifecycle, not a one-shot flag.

The single linked bank account

The app permits only one linked payment account at a time; switching accounts is a disconnect-then-relink. We account for relink events in the payment sync so a changed funding source does not read as a gap.

Authorization, and the open-banking question

The dependable basis for this work is the cardholder's own authorization, recorded and logged. Imprint states it is PCI DSS compliant and supports 2FA, biometric sign-in and a PIN; we operate inside that posture — authorized access, data minimized to what the integration needs, consent records kept, and an NDA where the engagement calls for one. The cards are issued by regulated industrial banks (First Electronic Bank is an FDIC-insured Utah industrial bank, per its own site), which sets the backdrop but does not, by itself, grant data access.

The forward-looking piece is the CFPB's Section 1033 personal-financial-data-rights rule, which would put consumer card accounts like these on a consumer-directed access footing. It is not in force: a federal court enjoined enforcement in late 2025 and the Bureau reopened the rule for reconsideration (per the CFPB's reconsideration notice). We design so that a consented integration today can move onto that footing if and when it settles, but we do not build as though the mandate already exists.

How we price it and run it

A first drop is a running client signed in to a consenting Imprint account, typically inside one to two weeks. You can take the source outright from $300: you receive the runnable Python and Node.js client, the tests, and the interface docs, and you pay after delivery once it works to your satisfaction. If you would rather not host it, call our endpoints instead — pay-per-call, no upfront fee, you pay only for the calls you make. Tell us the program and the data you want out of it and we will scope it back to you.

Tell us which Imprint program and what you need

Screens from the app

Public store screenshots, shown for reference. Select to enlarge.

Other apps in the co-branded card space

If you are mapping Imprint, you are likely mapping its neighbors too. Each holds broadly the same shape of account data, which is why a single normalized model tends to pay off:

• Cardless — launches digital-first co-branded cards for consumer brands; in-app activity, statements and rewards behind an account.
• Bilt Rewards — rent-and-spend rewards card; transactions, a points ledger, and payment data.
• Deserve — mobile-first card platform with instant virtual cards and detailed transaction data.
• Petal — cashflow-underwritten consumer cards; transactions, statements and autopay.
• Mission Lane — credit-building card app exposing balances, statements and payments.
• Upgrade Card — card-plus-installment hybrid; transactions, balances and payment plans.
• Tandym — white-label co-branded card platform for brand programs, in the same category as Imprint.
• Bread Financial (Comenity) — services store and co-brand cards across many retail programs; statements and payments per program.

Questions integrators ask

How do you keep the activity feed in sync without re-pulling the whole history every time?

We treat the activity as an append-only stream and carry a cursor on the ledger event id. The first run backfills; after that we ask only for events newer than the last id we stored. Because Imprint derives its records from an immutable ledger, a re-run replays cleanly and a pending authorization collapses into its later posting instead of duplicating.

Can you read the rewards balance and redemption history, or only the card transactions?

Both. The rewards ledger sits alongside transactions in the account, with accrual tied to the program the card belongs to. Redemptions resolve to statement credit, a mailed check, or deposit to a linked bank account, per NerdWallet's review, and we map each of those states so a reward is never counted twice.

Imprint runs many different brand cards. Does the build work the same for a Shell card as a Rakuten card?

The account shape is one model; the reward rules are not. A single Imprint login carries whichever co-brand program the card belongs to, and earn-and-redeem logic differs by program. We read a program identifier on each account and map its rules so two cardholders on different programs are handled correctly from the same client.

We only have the consumer app, no partner credentials. Can you still build the integration?

Yes. We work against a consenting cardholder account, not a sponsor backend, so what we need is the app name and what you want out of the data. Access and the consent records are arranged with you while the build runs.

Sources and review

Checked in June 2026 against the app's store listing, Imprint's own engineering and product material, and the current regulatory record. Primary sources opened for this write-up:

• Imprint Tech — how Imprint built its card-issuing platform (Passport, Ledger / QLDB, Messenger / SQS).
• CFPB — Personal Financial Data Rights Reconsideration (Section 1033 status).
• imprint.co (co-brand programs and product scope).
• Imprint App on Google Play (described features and platform).

Compiled by OpenFinance Lab — engineering notes, reviewed June 2026.