Getting the Yonder points ledger and card statements into your own system

Every full Yonder membership earns one point for each 20p spent — five points per pound, as Yonder's rewards terms put it — and that running points balance sits beside statements, live card-balance and credit-usage figures, and a redemption history inside an authenticated app. None of it shows up on a public page. The card is a UK rewards product spanning both credit and, since the June 2025 debit launch, premium debit, and the data a partner usually wants is exactly the per-member record locked behind that login.

This page maps what that record contains, the authorized way to reach it, and the working integration OpenBanking Studio hands back. You bring the app name and what you need from its data. We do the interface work.

Data behind the login

Yonder's own app description lists balance, credit usage and rewards on the home screen with real-time spending alerts. Read against the published account and rewards terms, the per-member surfaces break down like this.

Authorized routes to the data

Two routes carry the load here, and they cover different slices of the record.

Authorized protocol analysis of the app session

The points ledger, Send Points transfers, Experiences and the redemption history are proprietary to Yonder and only ever appear inside the authenticated app. We capture the app's own traffic under the cardholder's authorization, document the token and session chain, and rebuild the calls that return points, statements, transactions and redemptions. This is the only route that reaches the full rewards record, and it is the one we recommend leading with for a Yonder build — the loyalty data is the part most partners are actually after, and it has no open-banking equivalent. Effort is moderate; durability depends on the app's release cadence, which we account for in maintenance.

UK Open Banking account information

Credit cards are an in-scope account type for UK account information access, so the standardized card view — balances, available funds and up to roughly twelve months of transactions — can be read under a registered account information permission with the cardholder's explicit consent. This route is durable and regulator-backed for the card-transaction side, but it does not see points or Experiences. We set up the consent flow and, where the studio is not itself acting as the authorised provider, arrange access with you during onboarding. It pairs cleanly with the session route above: open banking for the audited card ledger, protocol analysis for everything Yonder layers on top.

A native statement export is a thin fallback where a member just needs their own PDF or CSV, but it is manual and does not carry the points ledger, so it rarely stands alone.

A worked example

Illustrative shape only — exact paths, field names and the auth chain are confirmed during the build against a consenting account. It shows the pattern: refresh the session token, page the statement transactions, then read the points balance.

# Authorized session against a consenting Yonder member account.
# Token + paths are confirmed during the build; shown here as the shape.

POST /auth/token/refresh
  { "refresh_token": "<held server-side>" }
  -> 200 { "access_token": "ey...", "expires_in": 900 }

GET /v?/accounts/{account_id}/transactions?from=2026-05-01&to=2026-05-31
  Authorization: Bearer ey...
  -> 200 {
       "statement_period": "2026-05",
       "currency": "GBP",
       "transactions": [
         { "id": "txn_8…", "merchant": "…", "amount": -42.10,
           "fx": { "original": "EUR", "fee": 0.00 },   # no-FX product
           "category": "dining", "booked_at": "2026-05-14T19:22:03Z" }
       ],
       "closing_balance": -318.74
     }

GET /v?/rewards/points
  Authorization: Bearer ey...
  -> 200 { "tier": "full", "points_balance": 24180,
           "earn_rate": "5_per_gbp",
           "pending": [ { "txn": "txn_8…", "points": 210 } ] }

# Retry/backoff on 401 -> refresh once, then re-issue; 429 -> honour Retry-After.

What lands in your repo

The deliverable is a working integration, not a report. For Yonder that means:

• An OpenAPI/Swagger spec covering the session auth, transactions, statements, points and redemption calls as mapped.
• A protocol and auth-flow report documenting the token refresh, session chain and error handling for the app interface.
• Runnable source for the key endpoints in Python or Node.js — token handling, statement paging, points read, normalized output.
• Automated tests against the captured surfaces, including the Free-versus-Full earn-rate branch.
• Interface documentation a member of your team can pick up cold.
• Compliance and data-retention guidance scoped to UK Open Banking and UK GDPR.

Where the engagement uses the hosted option instead, the same calls are exposed as endpoints you query and we maintain.

Consent and the FCA basis

For the card view, the dependable basis is the cardholder's own explicit, time-limited and revocable consent under UK Open Banking account information rules, which the FCA oversees and which the Open Banking customer-experience standards spell out. Consent is specific to the data requested, expires on the reauthentication window, and can be withdrawn at any point — the sync is built to re-consent rather than silently lapse. For the proprietary rewards data outside open-banking scope, the basis is the member's authenticated authorization to their own account, captured and logged. Yonder already runs account-information rails inbound through Yapily for affordability and pay-by-bank, per Yapily's published case study, which is useful context but separate from reading Yonder's data outward. We work authorized, logged and data-minimised, under NDA where a client needs it, and keep only the fields an integration requires.

Build notes specific to Yonder

Two things shape a Yonder build more than anything else, and we handle both up front.

First, the product is not one card. Free and Full tiers earn at different rates — one point per pound versus five — and the June 2025 debit line sits alongside the original credit account with a different account shape. We read the tier and product from the profile and branch the earn, fee and balance logic so a member on any combination reconciles correctly, rather than assuming a single card type.

Second, point value is deliberately variable. The same point is worth up to about 2.5p on an Experience, 0.1p against the card balance, and a flat 31,250 points per fifty pounds on flights. We compute and store a normalized value per event so a downstream ledger or dashboard does not have to guess a rate. When Yonder ships an app update that moves its mobile endpoints, our maintenance pass re-captures the changed calls and patches the client before anything breaks. Access to a consenting account or the relevant sandbox is arranged with you during onboarding; it is part of how the project runs, not something you have to line up first.

Pricing and how delivery works

Source code lands in your repository, reviewed and runnable, before any money changes hands. Source-code delivery starts at $300 and is paid only after delivery, once the integration does what the brief said. If you would rather not host anything, the same Yonder surfaces are available as a pay-per-call hosted API with no upfront fee — you call our endpoints and pay for the calls you make. Either way the build cycle is one to two weeks. Tell us the app and what you need from its data, and we will scope it: start a brief with OpenBanking Studio.

Where teams put this

• A personal-finance app folding Yonder card transactions and balances into a single net-worth and spend view alongside the user's other accounts.
• A loyalty or travel tool valuing a member's Yonder points and surfacing the best redemption — Experience, flight or card credit — from the live ledger.
• An accounting integration pulling monthly Yonder statements as structured data for expense reconciliation, no PDF parsing.
• A rewards dashboard tracking earn velocity by Free versus Full tier and flagging points that expire unused.

What the app screens show

Store screenshots we reviewed while mapping the surfaces — tap to enlarge.

Sources and what was checked

Mapped on 11 June 2026 from Yonder's own published terms and product pages, Yapily's open-banking case study, and the FCA and Open Banking customer-experience guidelines for account information access. Where a figure is Yonder's own — earn rates, redemption values, the FCA firm reference — it is attributed to that source rather than asserted independently. Primary references:

• Yonder rewards terms and conditions
• Yonder account terms (statements and balances)
• Yapily case study: Yonder open banking
• FCA: account information and payment initiation services
• Open Banking account information service guidelines

OpenBanking Studio · integration desk mapping, June 2026.

Nearby UK cards an aggregator would read alongside Yonder

Same wallet, neighbouring data — each holds a comparable per-member record a unified integration would normalise next to Yonder. Listed for ecosystem context, not ranked.

• American Express (Preferred Rewards Gold) — points balances and Membership Rewards earn and transfer records behind an account.
• Barclaycard Avios — card transactions plus an Avios accrual ledger tied to spend.
• Virgin Atlantic Reward credit card — statements and Virgin Points earned per purchase.
• NatWest Travel Reward card — card transactions and no-FX spend abroad with a rewards element.
• Curve — an aggregating wallet that re-routes other cards, holding consolidated transaction history.
• Revolut — multi-currency balances, transactions and the RevPoints loyalty scheme.
• Monzo — current-account transactions, pots and Monzo Flex instalment records.
• Tymit — instalment-plan credit records and the underlying transaction schedule.
• Zilch — buy-now-pay-later spend and repayment schedules per user.
• Klarna — purchase and repayment plans across linked merchants.

Questions integrators ask about Yonder

Can you reach the Yonder points balance and Experience redemptions, or only card transactions?

Both. The points balance, earn events, Send Points transfers and Experience or flight redemptions live inside the authenticated app interface, so they come through authorized protocol analysis of the Yonder session. Card transactions and balances arrive through that same session, and the standardized card-account view can also be read under UK Open Banking account information access where the card account is reachable.

How do the Free and Full membership tiers change what we read?

Earn rates differ by tier — Yonder's terms describe one point per full pound on Free and one point per full 20p on Full, which is five points per pound. The monthly fee also differs. We read the tier from the member profile and apply the matching earn and fee rules, so points reconciliation stays correct whichever tier a member holds.

Yonder itself uses Yapily open banking — does that affect the integration?

It tells us the card already speaks account-information rails on the inbound side, which Yapily's published Yonder case study describes for affordability checks and pay-by-bank. For pulling Yonder's own data outward we work from the authorized app session and, for the card-account view, UK Open Banking account information under the cardholder's consent.

Points are worth different amounts depending on redemption — can you normalize that for a dashboard?

Yes. Yonder publishes variable redemption values — up to roughly 2.5p per point on Experiences, 0.1p per point against the card balance, and flights at 31,250 points per fifty pounds. We emit a normalized value field per earn and redemption event so a downstream rewards dashboard does not assume a single fixed rate.