Reaching the AXI Card account behind the AXI RO mobile app

The AXI Card is a revolving Mastercard issued by AXI Finance IFN S.A. in Bucharest, and AXI RO is the small mobile companion the issuer ships for cardholders — it confirms 3D Secure online purchases, lists the card's current limit and recent activity, and pushes a notification each time the card moves. For a third party that wants those card-state changes in their own ledger, the interesting thing about the app is not the UI but the event stream behind it: a per-cardholder feed of authorizations, settlements, and SCA challenges that the issuer is already producing in close to real time.

Available data domains

What the app actually shows the cardholder, mapped to where it originates in the AXI backend, with the granularity an integrator gets and one concrete use:

Routes that fit this app

Two routes apply cleanly to AXI RO. They are not mutually exclusive — most projects start with the first and add the second when a single-account use case shows up.

Route 1 — authorized interface integration

With the cardholder's written consent, the studio captures the authenticated HTTPS traffic between AXI RO and the AXI Finance backend, rebuilds the relevant calls in clean Python or Node.js, and produces an OpenAPI document for the slice the integration uses. This is the route that maps one-to-one to every surface the cardholder sees, and it scales to multiple accounts because the client is yours. Access is arranged with you during onboarding: the build runs against your own consenting test card.

Route 2 — user-consented credential service

A small service holds the cardholder's credentials in their own secrets vault, performs the SCA challenge against the AXI backend on demand, and re-emits a normalized event. Lower implementation cost; better when only one or two cardholders are in scope. Harder to scale, and per-device biometric attestation means it cannot be turned into a multi-tenant scraper.

For most projects the first route is the spine of the integration and the second is layered in for a particular account that does not warrant a full client. We tell you which one fits during the initial scoping call — it is rarely an even split.

Regulatory footing: an IFN, not a bank

AXI Finance is a non-bank financial institution — an instituție financiară nebancară, IFN — registered in the BNR Special Register of IFNs (per Access Finance's published corporate materials). That matters more than it sounds. Romania's PSD2 AISP scheme, which most integrators reach for first, covers bank payment accounts behind the Berlin Group NextGenPSD2 APIs published by BCR, BRD, Banca Transilvania, ING and the rest. The AXI Card account sits at an IFN, outside that scheme, so a Romanian AISP cannot read it on your behalf. The dependable basis is the cardholder's own consent, captured at the start of the build and logged with the integration.

Around that, the usual GDPR posture applies: data minimization to fields the use case needs, retention windows agreed up front, processor agreements where the data crosses our infrastructure, and an NDA on the cardholder's data by default. The in-app 3DS confirmation is a regulatory step in the Mastercard ACS pathway — an integration that automates payment confirmation has to respect that and surface a missed challenge as a decline, not silently approve it.

What the build ships

For an AXI RO engagement, the studio routinely delivers, in this order:

• Runnable client source in Python and Node.js for the AXI Card surface: card list, transactions, notification stream subscriber, 3DS challenge subscriber and decision call. A Go variant where the project asks for it.
• A webhook handler that normalizes the AXI push stream into your event bus — Kafka, SQS, or a Redis stream — with idempotency keyed on AXI's notification id so retried events do not double-post.
• An automated test suite with HTTP cassettes recorded against a consenting account, so the build keeps running in CI without depending on a live AXI session.
• Ingestion design notes covering batch vs realtime trade-off, the SCA challenge window, and how to back off cleanly on 401s without re-prompting the cardholder.
• An OpenAPI specification for the slice the integration mirrors.
• A protocol and auth-flow report covering token issuance, refresh, and the biometric attestation binding.
• Interface documentation in Markdown and a short compliance memo on consent capture, retention, and IFN-specific notes (KYC implications, scope limits).

Sample request flow

An illustrative shape of the calls the client wraps. Exact field names are confirmed during the build against a consenting AXI account; the point of this snippet is the round-trip, not the wire format.

# Session — short-lived access token, refresh token, device-bound attestation.
POST https://api.axi-card.ro/v2/auth/session
{
  "device_id":        "<attested-device-id>",
  "username":         "<cardholder>",
  "password":         "<cardholder-pin>",
  "biometric_token":  "<platform-attestation>"
}
-> { "access_token": "...", "refresh_token": "...", "expires_in": 600 }

# Card surface.
GET /v2/cards          -> [ { id, masked_pan, expiry, currency, limit, available } ]
GET /v2/transactions   -> [ { id, ts, merchant, amount, status: "AUTH"|"SETTLED"|"DECLINED" } ]
GET /v2/notifications  -> [ { id, kind: "3DS_CHALLENGE"|"AUTH"|"PAYMENT"|..., ... } ]

# 3DS confirmation — the app's main interactive surface.
# This call is the SCA step in the Mastercard ACS pathway and must
# complete inside the challenge window or the upstream authorization
# is declined at the merchant.
POST /v2/3ds/challenges/<challenge_id>/decision
{ "decision": "approve", "biometric_token": "<fresh-attestation>" }
-> { "status": "approved", "tx_id": "...", "approved_at": "..." }

Normalized event shape

The webhook handler folds AXI's push stream into one event shape keyed by issuer and card. This is what lands on your bus — multi-issuer integrations can drop AXI in next to a Pago-style aggregator without changing consumers.

{
  "issuer":    "AXI",
  "card_id":   "axi:<internal-card-id>",
  "event_id":  "axi:notif:<notification-id>",
  "kind":      "TX_AUTH" | "TX_SETTLED" | "3DS_CHALLENGE" | "3DS_APPROVED" | "CARD_LIFECYCLE",
  "ts":        "2026-05-27T09:14:02Z",
  "amount":    { "value": 14999, "currency": "RON", "scale": 2 },
  "merchant":  "...",
  "raw":       { ... original AXI payload ... }
}

Runtime notes worth knowing

• 3DS challenges are time-bounded — the challenge window is on the order of a few minutes, so ingestion has to acknowledge inside it or the underlying authorization is declined at the merchant.
• Session tokens are short. The client library refreshes in the background and uses exponential backoff on 401s rather than re-prompting the cardholder.
• The notification feed is the authoritative event log. The transactions endpoint is a denormalized projection of the same state and lags by a few seconds after a 3DS approval. Trigger on notifications; reconcile against transactions.
• Per the AppBrain listing the Android build was last refreshed in January 2026 (version family 2.9.x). Any payload assertion in the final client is verified against the version live at build time, not against this snapshot.

Quirks the build accounts for

Per-device biometric binding

The SCA pathway in AXI RO binds the biometric proof to the device identifier the cardholder enrolled in the app. The client library is therefore designed to either run on that device or to replay a fresh attestation the cardholder produces on demand — multi-account variants of the integration still respect per-device SCA rather than try to pool credentials.

IFN status of the issuer

Because AXI Finance is an IFN rather than a bank, the BNR's PSD2 AISP channel used for Romanian bank accounts is not the right shape for an AXI integration. The build scopes the data path around direct cardholder consent and documents the IFN status in the deliverables, because downstream consumers (KYC, AML, lending decisioning) treat an IFN attestation differently from a bank statement.

Mastercard rail timing

Settlement timing on the AXI Card follows the Mastercard cycle, so the transactions feed will surface authorizations first and clearings later. The integration surfaces both states so the downstream consumer can choose which to act on — pre-auth holds for fraud workflows, settled lines for accounting.

Romanian-language payloads

Merchant strings and notification bodies come back in Romanian. The normalized event shape preserves the original string and adds an optional English translation only where the use case asks for it; we do not silently rewrite the issuer's source data.

Screens the brief was checked against

The Google Play listing for AXI RO carries the screenshots below. Click to enlarge.

Sources and review

The brief was checked against the Play Store listing for the Android build, the issuer's own product and corporate pages, the parent group's locations page, and a third-party tracker for Romanian open banking. Specific sources:

• AXI RO on Google Play — app description, screenshots, last-updated date.
• AXI Card — About us — issuer identity and product framing.
• Access Finance — Bucharest — corporate parent and Romanian operating context.
• Open finance tracker — Romania — PSD2 and Berlin Group NextGenPSD2 context.

Mapping reviewed by the OpenFinance Lab integration desk · 2026-05-27.

Comparable apps in the Romanian card stack

Apps that share data shapes or integration concerns with AXI RO. Naming them here in case a project considering AXI is also looking at, or already integrating, one of these:

• TBI Pay — TBI Bank's Romanian shopping-and-installment app; closest non-bank-card peer, with a similar transaction and installment-plan surface.
• Pago — Romanian aggregator that ingests cards and bills for a single household view; the canonical Romanian aggregator AXI is most often slotted next to.
• BT Pay — Banca Transilvania's payment app, on the bank side; the reference for Romanian PSD2 AISP wiring against a domestic bank.
• Salt Bank — Romanian PSD2-native neobank; a modern baseline for how a Romanian card backend exposes itself.
• ING Home'Bank — ING Romania's banking app, with RoPay integration; commonly cited Berlin Group AIS example in production.
• BRD Mobile — BRD–Société Générale Romania; comparable transaction stream and SCA flow on the bank side.
• Cetelem MyAccount — BNP Paribas Personal Finance Romania's consumer-credit app; the closest IFN-category peer outside the Access Finance group.
• Provident Online — Provident Financial Romania; non-bank consumer-credit servicing for a different category of cardholder.
• Revolut — operates in Romania with a local IBAN; often mirrored for card and transaction state alongside a Romanian-issuer card like AXI.
• Edenred Romania — meal-voucher card app; comparable card-state-and-notification surface, narrower product.

Questions integrators ask first

How fresh is the data we'd be ingesting from AXI RO?

The notification stream is the authoritative event log and lands within a couple of seconds of the issuer-side state change. The /transactions projection lags that stream by a few seconds after a 3DS approval, which is why the integration treats notifications as the trigger and transactions as the reconciliation source.

We already run a Pago-style aggregator. Can AXI sit next to it without double-ingesting?

Yes. AXI's notification ids are stable and the normalized event shape we deliver carries an issuer key (AXI) and a per-card id, so the aggregator can dedupe by (issuer, card, notification_id). Most projects route AXI's stream to the same Kafka topic the aggregator already drains and let the consumer pick a side.

If a 3DS challenge times out before our ingestion acknowledges it, what happens to the underlying card purchase?

The Mastercard ACS pathway declines the authorization upstream — the cardholder sees the purchase fail at the merchant. Because that is a regulatory outcome, the integration is built to acknowledge inside the challenge window or to surface the decline cleanly, never to silently approve a missed challenge.

Why can't we just call the Romanian AISP API for the AXI Card account?

PSD2 AISP coverage in Romania is for bank payment accounts (the BCR / BRD / Banca Transilvania / ING and similar APIs under Berlin Group NextGenPSD2). AXI Finance is a non-bank IFN, so the AXI Card account is outside that scheme. The dependable basis is the cardholder's direct consent, captured and logged inside the build.

How the work runs

A first AXI RO build runs one to two weeks end to end — enough to capture a clean SCA round-trip and exercise both the notification and transaction surfaces, short enough to keep against a single working test card. Source-code delivery starts at $300, paid after delivery once the integration runs against your account; the same surface is available as a hosted endpoint billed per call with no upfront fee. Pick the model that fits the project and send a short brief here with the account scope and which one you want.