What an integrator gets from AXI RO and the AXI Card portal behind it

Where AXI RO sits in the AXI Card stack

AXI Card is the Romanian face of a regulated split. The cardholder relationship runs through AXI Finance IFN S.A., registered in the BNR special register of non-banking financial institutions and listed on the Access Finance group page as the Romanian lending entity. The plastic itself is a Mastercard issued by Easy Payment Services Ltd. out of Sofia, an EMI authorized by the Bulgarian National Bank. AXI RO sits on top of that pair: it talks to the issuer for card state and 3DS, and to the IFN portal for the rest.

Because of that split, useful integration work is rarely a single endpoint. It is two systems, with the mobile app acting as the shared step-up factor a user actually trusts.

What the app surfaces, screen by screen

Rows below reflect what the public app description and AXI Card support pages put in front of a user, mapped to the back-end domain each comes from.

Mapping the confirm-payment flow

A short sketch of how a build models the two halves of an AXI RO session. The portal step uses the email-OTP that AXI Card's help pages describe; the issuer step is the per-transaction 3DS challenge the mobile app exists for. The values and paths below are illustrative and are confirmed during the build against a consenting AXI Card account.

# Illustrative; endpoints and field names confirmed during the build.
# AXI Card portal session  +  device-bound 3DS challenge.

import httpx

PORTAL = "https://my.axi-card.ro"      # cardholder portal (IFN side)
ISSUER = "https://api.easyps.bg"       # Easy Payment Services issuer side

def open_portal_session(email: str, otp_code: str) -> httpx.Client:
    s = httpx.Client(base_url=PORTAL, headers={"Accept-Language": "ro,en"})
    s.post("/auth/email-otp/request", json={"email": email})
    s.post("/auth/email-otp/verify",  json={"email": email, "code": otp_code})
    return s

def list_transactions(s: httpx.Client, card_id: str, since_iso: str) -> list[dict]:
    # Mapped from the in-app "Recent transactions" surface.
    r = s.get(f"/api/cards/{card_id}/transactions", params={"since": since_iso})
    r.raise_for_status()
    return [
        {
            "occurred_at": t["date"],
            "merchant":    t["merchant_name"],
            "amount_ron":  t["amount"],
            "state":       t["state"],   # AUTHORIZED / CLEARED / REVERSED
        }
        for t in r.json()["items"]
    ]

def confirm_3ds(device, challenge_id: str, factor: str) -> dict:
    # factor in {"biometric", "pin"} — surfaces what the app prompts for.
    return device.post(
        f"{ISSUER}/3ds/challenges/{challenge_id}/confirm",
        json={"factor": factor, "decision": "approve"},
    ).json()

The package an integration ships with

An AXI RO build is delivered as one bundle. Every piece is tied to the surfaces above, not generic.

• OpenAPI 3.1 spec covering the portal-session bootstrap, the card and transaction reads, the 3DS challenge object, and the notification feed, with example request/response bodies in RON and a Romanian/English mixed locale.
• Protocol and auth-flow report — a short PDF describing the email-OTP portal exchange, the device-pairing step the mobile app performs, the biometric/PIN gating, and where tokens live and expire.
• Runnable Python source in a single repo: a client library for the read paths and a small CLI for the 3DS confirm path, with retries, idempotency keys and a typed transaction model.
• Node.js port when the integrator's stack is JavaScript, sharing the same OpenAPI as the source of truth.
• Automated test suite — contract tests against the OpenAPI plus end-to-end tests against a consenting test card, including a recorded-cassette mode for CI.
• Interface documentation in English plus a Romanian glossary for the user-visible terms (sold / cleared / authorized, dobândă, comision, scadență).
• Compliance and retention notes — what may be logged, what must be redacted, and the consent records the cardholder signs.

Authorized routes into the AXI Card backend

Three routes do the actual work here. We pick one as the spine and use the others to fill gaps.

1. Authorized mobile-protocol analysis of AXI RO traffic

Run the app against a consenting card and a controlled proxy, model the device pairing and the 3DS challenge object, and rebuild the client. This is what makes the confirm-internet-payment surface reachable at all. Durability is medium: the mobile binary updates roughly monthly per the AppBrain version history, so our maintenance contract budgets time for each release.

2. User-consented portal integration at my.axi-card.ro

Open the email-OTP session that the AXI Card support pages document, then drive the cardholder area to pull statements, transaction history beyond the in-app window, and credit-line metadata. Durability is higher because the portal changes less often than the mobile binary, but the read shape is HTML-derived rather than a native API.

3. Native export, where the portal offers it

Statement PDFs and CSV-style transaction exports the portal generates are the lowest-effort piece and the easiest to schedule. They cover the archival use case and leave the live flows to routes 1 and 2.

A regulated AIS feed via the cardholder's primary Romanian bank can sometimes substitute for route 2 read-only data, where George or BT Pay multibanking already pulls the card account in. We use that as a complement, not a substitute, because 3DS confirmation and IFN-side credit metadata sit outside it.

For most projects we recommend leading with route 1 for the confirm flow and route 2 for everything else, with route 3 layered on for archival. We tell you which is cheaper to maintain for your specific use case before quoting.

Romanian IFN, Bulgarian EMI, and what that means for consent

The consent picture is shaped by the split. AXI Finance IFN S.A. operates as a non-banking financial institution under Romanian law and is on the BNR special register, which puts the cardholder relationship under Romanian GDPR transposition and ANPC consumer-protection oversight; AXI Finance IFN is also a registered personal-data operator per its corporate filings. Easy Payment Services holds the EMI licence on the issuer side and is supervised by the Bulgarian National Bank, with the card scheme rules of Mastercard layered on top.

What that means in practice: a regulated AIS / xS2A consent of the kind a Romanian bank exposes is not, on its own, the right instrument for AXI Card data. The dependable basis is the cardholder's own authorization, captured in writing, scoped to specific data domains and a specific retention window, with revocation honoured by deleting the matching records. We log access, minimize what we pull, and sign an NDA with the integrator when the build is for a third party. Card numbers and PINs never leave the cardholder's device in our pipelines.

Engineering notes specific to this build

Things we plan for at design time, rather than discover in week two.

• The data ownership split is real and we route accordingly. Card-state and 3DS challenges go to the issuer side (Easy Payment Services); credit-line metadata, statements and the cardholder profile go to the IFN portal. The client we ship treats them as two services behind one facade, so adding a future endpoint on either side does not break the integrator's call sites.
• The mobile app is a step-up factor, not a passive reader. The confirm-internet-payment surface is the reason a third party can do useful work here. We design the integration around a long-lived device session plus a per-transaction challenge object, which is how the app actually communicates, instead of pretending it is a flat REST resource.
• Portal authentication is email-OTP, with optional device remembering. AXI Card's support pages confirm a code-to-email step on first login, with an option to mark the device as trusted. We wire the email-OTP exchange into the build so the test suite can run unattended against a consenting account, and we keep the remember-device behaviour switched off in CI so each run is fresh.
• Locale and currency are Romanian-first. Merchant names, statement copy and notification text are Romanian; amounts are in RON; settlement timing follows Romanian banking days. The OpenAPI uses RFC 3339 timestamps with the Europe/Bucharest offset and we normalize amounts as integer minor units to avoid float drift on consumer ledgers.

Running a build

A typical AXI RO build ships in one to two weeks once a consenting AXI Card account is paired and the scope is signed. We deliver the OpenAPI, the runnable Python source, the test suite and the auth-flow report as one tarball. Source-code delivery is invoiced from $300, paid after the bundle is in your hands and the test suite passes against your account. If you would rather not host anything, we run the same code as endpoints and you pay per call, with no upfront fee. Access and compliance paperwork are arranged with you during onboarding; nothing in that step is your problem to solve before we will start. Tell us the app and what you need from it at /contact.html and we will scope from there.

Scenarios this fits

1. A Romanian back-office tool consolidating cards across BCR, BT, Revolut and AXI Card into one ledger, where AXI Card sits outside the bank-multibanking flow and needs its own connector.
2. A consumer-finance dashboard whose users hold an AXI Card alongside a main current account, where the dashboard needs to surface 3DS confirmation events the main bank does not see.
3. A merchant or PSP QA suite that needs to reproduce a Mastercard 3DS step-up against a real Romanian credit card, with the confirm action driven by the test runner rather than a human tester.

Interface evidence

Screens from the public Play listing. Click to expand.

Sources we checked

For this page we read the public Play Store listing, the AXI Card help articles, and the corporate group page, alongside the Romanian open-banking landscape so the AIS comparison is accurate. The sources below are the ones we cite directly.

• AXI RO on Google Play — feature list and developer attribution.
• AXI Card support — two-factor authentication on my.axi-card.ro — describes the email-OTP and trusted-device behaviour.
• Access Finance AD — corporate profile — confirms the AXI Finance IFN S.A. (Romania) and Easy Payment Services Ltd. (Bulgaria) split.
• Open Banking Tracker — Romania — current AIS / xS2A landscape for cross-checking the multibanking complement.

Reviewed May 2026 by the OpenBanking Studio integration desk.

Same-neighbourhood apps

Apps a Romanian integrator usually has to think about in the same project. Each is named for ecosystem orientation, not ranked, and is a separate piece of work to integrate.

• George (BCR) — main current-account mobile app, exposes other cards via its multibanking screen on the bank side.
• BT Pay (Banca Transilvania) — payments super-app whose multibanking can read card data from other Romanian providers.
• Smart Mobile (Raiffeisen Bank) — current-account and card management, often the user's primary credential.
• Home'Bank (ING Bank Romania) — current accounts, cards, and ING Pay for mobile payments.
• Revolut — multi-currency wallet with cards, frequently held alongside an AXI Card.
• mobilPay Wallet — Romanian wallet from NETOPIA Payments, scans and in-app payments.
• AXI PL — the sibling AXI app for the Polish market, same engineering shape under different regulator.
• Axi Card ES — the Spanish-market sibling app, useful when the integrator covers more than one Access Finance market.

Questions integrators actually ask about AXI RO

Does AXI RO fall under PSD2 AIS, or is it a different consent regime?

AXI Card is a credit-card product, not a PSD2 payment account at a Romanian ASPSP, so the regulated AIS / xS2A path that George or BT Pay expose does not cover it directly. The lending entity is AXI Finance IFN S.A., on the BNR special register of non-banking financial institutions; the card itself is issued by Easy Payment Services Ltd., a Bulgarian EMI authorized by BNB. An integration runs through user-consented access to the cardholder portal at my.axi-card.ro and the mobile app's own traffic, with NDA and a written authorization in place when the work is for a third party rather than the cardholder.

What does the 3DS confirmation step inside AXI RO actually carry?

Per the public app description and the AXI Card support pages, the confirm-internet-payment flow is a step-up: the cardholder sees a notification or in-app challenge tied to a specific merchant authorization, approves it with biometrics or a security code, and the result flows back to the issuer for the Mastercard transaction. The integration we build models that as a device-bound session plus a per-transaction challenge object, not a flat REST call, because that is how the app communicates.

If a customer's main Romanian bank already exposes AXI Card data through its multibanking screen, do we still need AXI RO at all?

Sometimes not. George and BT Pay both pull data from other accounts through Open Banking-style multibanking, and if your use case is read-only and the card account is reachable that way for your cardholders, that is the cleanest path. Where it is not enough is the 3DS confirmation flow, statements as the portal renders them, and the credit-line metadata held by AXI Finance IFN rather than the cardholder's primary bank. We scope the integration around exactly that gap, rather than duplicating what multibanking already gives you.

How do we get a working AXI RO test account for the build?

Access is arranged with you during onboarding. A consenting AXI Card cardholder is enough for the read paths; for confirmation-flow work we run against the same account end to end so the device pairing and the email-OTP portal session are real. We handle the consent paperwork on our side and our CI never stores card numbers or PINs.