Pulling account, BLIK and card data out of PeoPay

Bank Pekao opened production PSD2 endpoints to third parties in 2019, per its own press desk, and the bank's PSD2 implementation follows the PolishAPI standard maintained by the Polish Bank Association. That gives an integrator into PeoPay a real regulated path for the account-side data — balances, history, payment initiation — and leaves the rest of what users actually see in the app (BLIK code events, fund-account history at PekaoTFI, brokerage positions, card management) on the app's own authenticated surface. The interesting engineering for a PeoPay project is the join between those two halves.

PeoPay is the consumer-facing app for a bank that the bank describes as serving both individual and company customers in one shell, with the Apple Pay tokenisation flow embedded inside the app rather than handed off to the wallet. The brokerage and PekaoTFI fund-history screens are also folded in. A useful integration sits on PolishAPI for the parts the regulator already standardised, and on the app's own protocol for everything else, with a single consent trail kept on the client's side.

Data surfaces inside PeoPay

The table maps the surfaces the app exposes to its user against where each one originates, the granularity an integrator gets, and what a third party tends to do with it.

Routes to the data

1. PolishAPI 2.1.1 (regulated AIS, PIS, CAF)

This is the spine. PolishAPI 2.1.1 is the version Bank Pekao implements under PSD2; the standard itself is published by the Polish Bank Association under a Creative Commons licence and is shared across the commercial banks listed on polishapi.org. The scope is current accounts, transaction history, payment initiation, and confirmation of funds — exactly what PSD2 forces, plus the "premium" extensions PolishAPI defined on top. Calls run over mTLS using an eIDAS QWAC and are signed with a QSEAL; consent is per-account and time-boxed. We arrange the TPP credentials with the client during onboarding — either by using a partner TPP, or by walking the client's own KNF registration through.

2. Authorized interface integration

For surfaces the regulator did not standardise — PekaoTFI fund-account history, brokerage positions, BLIK code-generation telemetry, card management, scheduled-payments calendar, Apple Pay enrolment events — we work directly against the app's authenticated interface under the client's authorization. The auth flow uses the same login factors a user sees (PIN, biometric attestation, transaction signing) and runs against an account the client controls or a consenting end user supplies. The deliverable is a documented protocol report plus runnable code; the build runs in our sandbox, then on a Pekao test account, then on the production account.

3. User-consented credential access

For one-shot exports or small populations, the simplest path is a single consented account on the customer side. We capture the session once, derive the long-running token and refresh path, and hand back a CLI plus an OpenAPI spec the customer can run themselves. This is the path many accounting integrations actually want.

4. Native export

The Pekao24 web channel produces MT940 and CSV statement files. Useful as a fallback for batch reconciliation when neither AIS nor a live session is wanted, but it loses the BLIK and card telemetry and is a polling pattern.

For most PeoPay projects we recommend the regulated AIS scope as the trunk, with route 2 layered on for the surfaces above PSD2 scope and a single consent record kept on the client side. Route 3 is for short engagements; route 4 is a fallback.

An AIS call in practice

Below is the shape of the consent grant plus a booked-transactions read against the PolishAPI 2.1.1 surface, redacted and condensed from a sandbox build. The bank-specific paths and headers are illustrative — production headers are confirmed against the live sandbox during the build.

# 1. Acquire access token under PSD2 AIS scope (OAuth2 authorisation code flow,
# mTLS with QWAC, request object signed with QSEAL)
POST /authorize HTTP/1.1
Host: api.pekao.com.pl
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=<code from the redirect after SCA in PeoPay>
&redirect_uri=https://tpp.client.example/callback
&client_id=<TPP client id>
&code_verifier=<PKCE verifier>

# 2. Fetch booked transactions for a consented account
POST /v2_1_1.1/accounts/getTransactionsDone HTTP/1.1
Host: api.pekao.com.pl
Authorization: Bearer <access_token>
X-JWS-SIGNATURE: <detached JWS over the body, QSEAL key>
X-REQUEST-ID: 8d4d…
Content-Type: application/json

{
  "requestHeader": { "requestId": "8d4d…", "sendDate": "2026-05-19T08:11:04+02:00" },
  "accountNumber": "PL61109010140000071219812874",
  "transactionDateFrom": "2026-04-01",
  "transactionDateTo":   "2026-04-30",
  "pageId": "0", "perPage": 100
}

# 3. Response (trimmed) — normalised on our side into the schema we hand over
{
  "transactions": [
    {
      "itemId": "TX-0001",
      "tradeDate": "2026-04-03",
      "bookingDate": "2026-04-04",
      "amount": { "value": -129.90, "currency": "PLN" },
      "counterparty": { "name": "Allegro.pl",
                        "accountNumber": "PL49105000…",
                        "address": "Poznań, PL" },
      "description": "BLIK payment 312045",
      "type": "BLIK_PAYMENT"
    }
  ],
  "nextPage": null
}

# Errors we wire in:
#   401 — token expired → silent refresh via refresh_token
#   429 — TPP rate ceiling → exponential backoff with jitter
#   403 PSU_CONSENT_REVOKED → trigger re-consent in the client UI

What goes in the handover

For a PeoPay engagement the handover is a single repo a working engineer can run on a Monday morning:

• OpenAPI 3.1 spec covering the AIS scope we wired (accounts, balances, transactions done and pending, optional PIS), plus the above-PSD2 endpoints we built for the client's case.
• Auth report — the OAuth2 + mTLS + QSEAL flow as it actually runs, sequence diagrams for SCA renewal, consent expiry, and revocation handling.
• Runnable Python and Node.js clients — token bootstrap, paginated transaction reader, payment initiation, retry and idempotency, with a CLI that prints what each call returns.
• Automated tests against the sandbox and a recorded-fixture replay so CI does not need live credentials.
• A normalised schema for what the client cares about — typically accounts, transactions, cards, BLIK events, FX rates — so the bank-side response shape is not the application's problem.
• An operations note: rate limits we observed, freshness windows, where the bank's behaviour differs from a strict reading of PolishAPI, what to log for the KNF audit trail.

Consent, PolishAPI scope, and KNF

PSD2 in Poland is supervised by the Komisja Nadzoru Finansowego (KNF). A third party calling Pekao's production endpoints must hold either a Polish authorization as an AISP/PISP, or an EU-passportable equivalent, evidenced by an eIDAS certificate issued for that role. The standard itself, PolishAPI, is maintained by Związek Banków Polskich; it covers AIS, PIS and CAF and goes beyond the PSD2 minimum with a "premium" scope. Consent in the PolishAPI flow is per-account, time-boxed (up to 180 days under the regulatory technical standards as they currently apply in the EU), and revocable by the PSU at any time. The integration we build keeps a per-customer consent record, surfaces the expiry to the calling application, and retries SCA only on user action — never silently.

For surfaces outside PSD2 scope (BLIK code telemetry, fund history, card management) the lawful basis is the customer's own authorization to act on their account, captured under a written authorization on file and limited to the data the client actually needs. GDPR applies in the usual way: data minimisation, purpose limitation, retention timer, the right to erasure. We sign an NDA where the client wants one and keep an integration log the client can inspect.

Things we account for in a Pekao build

• Two holder types in one shell. The app deliberately puts an individual customer and the same person's company accounts behind one login. The consent grant in PolishAPI is per-account, so we model the join on the client's side and never assume a token covers the whole logged-in profile — otherwise the company-account history quietly drops out the moment the personal consent is renewed alone.
• BLIK lives across two surfaces. The 6-digit code is generated client-side in the app; the settled payment lands in the account history through AIS. The two have different timestamps and we have seen them drift by tens of seconds. We reconcile on the bank-side itemId, not on the code, and we keep the code-generation telemetry stored only when the integration genuinely needs it.
• Foreign-currency accounts pay in their own currency. The app supports paying online directly from a currency account, which means a single "transaction" in the user's mind can carry no FX leg at all. The normalised schema we hand over flags FX presence explicitly so downstream code does not multiply by the wrong rate.
• PekaoTFI is not in PSD2 scope. Fund-account history at the bank's asset-management arm and the brokerage feed are layered on through the app's authenticated interface, not through PolishAPI. We build it as a separate adapter so an AIS-only deployment is still a clean install.
• Front-end churn. The above-PSD2 surfaces ride the app's own interface, which the bank refreshes on its own schedule. We pin parser versions in each released build and run scheduled checks against a live consenting account, so a UI refresh does not silently drop a field on the customer's side.

Other Polish retail-banking apps in the same picture

Polish retail banking has settled around a handful of major mobile apps, all of which expose at least the PSD2 AIS/PIS scope through PolishAPI, with the surfaces above that varying per bank. Listed here as plain text — names referenced for ecosystem context, not endorsement.

• IKO (PKO BP) — the country's most-used banking app; PolishAPI on the regulated side, with a similar above-scope problem for IKO's investments, BLIK and card surfaces.
• Moje ING (ING Bank Śląski) — strong on the savings, mortgage and investment surfaces beyond AIS; PolishAPI implementation on the PSD2 side.
• mBank PL (mBank) — includes mKantor FX inside the app on top of standard PolishAPI accounts and history.
• Santander mobile (Santander Bank Polska) — multi-product retail with the EU-wide Santander group's PSD2 endpoints alongside Poland-specific surfaces.
• Bank Millennium — Autopay road-toll integrations and parking on top of the AIS/PIS regulated baseline.
• Alior Mobile (Alior Bank) — broad mobile-payment surface plus tickets and parking; standard PolishAPI on the regulated side.
• VeloBank — VeloKantor 24/7 FX in the app, otherwise the same PolishAPI baseline.
• GOmobile (BNP Paribas Bank Polska) — group-level PSD2 endpoints with Poland-specific scheduled-payments and FX surfaces.
• CA24 Mobile (Credit Agricole Bank Polska) — retail PSD2 coverage and consumer-loan surfaces in the app.
• Citi Mobile (Citi Handlowy) — retail and small-business banking with PolishAPI on the regulated side.

For a Polish-market integration that crosses banks, the regulated scope behaves consistently — the work is in the above-scope surfaces and in normalising the per-bank shape of an AIS response.

Questions integrators usually ask

Does PolishAPI cover PekaoTFI fund history and brokerage positions?

No. PolishAPI 2.1.1 carries AIS, PIS and CAF — current account balances, transaction history, payment initiation, funds confirmation. Investment fund unit balances at PekaoTFI and brokerage positions sit on a separate authenticated portal surface in the app. We integrate those through authorized interface integration under the customer's consent, not through PSD2.

Are BLIK code-generation events visible through AIS?

AIS sees the resulting transaction in the account history once the BLIK payment settles. The 6-digit code generation event itself — when the user produced a code, on which device — lives in the app's own session state and is not in PSD2 scope. If you need that telemetry we capture it through the app's authorized interface, not the PolishAPI endpoints.

Can we sit on Pekao's live PSD2 endpoints without holding a TPP licence?

Production calls require an eIDAS QWAC (transport) plus QSEAL (signing) certificate tied to a registered TPP. If you do not hold a Polish or EU-passportable TPP authorization, we use a partner that does, or run the integration as user-consented authorized access. Sandbox calls are open for development without that paperwork. Sorting this out is part of onboarding.

How fresh is account data through PolishAPI versus the app?

Balances and booked transactions through the PolishAPI AIS scope match the app within the bank's standard reconciliation window. Pending Express Elixir movements show up in the pending list before they hit booked. For card-level events and BLIK timestamps you want sub-minute, the app surface is closer to real time and we wire that route in alongside AIS.

A typical PeoPay build takes one to two weeks once TPP credentials are in hand — the regulated AIS scope on day one, the above-PSD2 surfaces over the following days, and a final pass on tests and the audit log. Source-code delivery starts at $300 and is paid only after the repo is handed over and you have run the OpenAPI spec and the test suite yourself. If you would rather not host anything, the pay-per-call hosted endpoint option charges only for the calls you actually make, with no upfront fee. To brief us, the input we need is the app name and the data you want from it; access, TPP credentials and the compliance paperwork are arranged with you. Send the brief through the contact page.

Sources for this mapping

Checked against the bank's own open-banking material and the standard body's specification before writing. Three primary references kept open in another tab:

• Bank Pekao S.A. — Otwarta bankowość (open banking) page
• Bank Pekao — PSD2 production environment press release
• PolishAPI specification (PDF, Polish Bank Association)
• PolishAPI — commercial banks implementing the standard