Reaching Ozon Bank for Business account and payment flows

Two channels carry most of what an integrator wants out of Ozon Bank for Business (package ru.ozon.fintech.sme, per its Google Play listing): the account-and-statement surface inside the mobile app, and a documented 1C:DirectBank exchange that Ozon Bank publishes for business clients. The first holds balances, operation history, counterparty transfers and the Daily Income savings ledger. The second was built for machine exchange of payment documents and statement requests. Either one gets a back office a clean, structured view of a Russian business account without a person retyping figures from a phone screen.

Our read: where the business account is enabled for 1C:DirectBank, that channel is the spine of the work because it already speaks signed documents and statements. Where it is not, we build against the app's own authenticated traffic under the account holder's authorization. Both end at the same normalized schema, so a switch later does not break the consumer.

What data sits behind the login

The rows below reflect surfaces the app and Ozon Bank's business help describe, named the way a user sees them.

A statement pull, sketched

This is the shape we target for the app-traffic route: authenticate, refresh the session token, then page the operations feed for a date window. Field names are illustrative and get confirmed during the build against the live response.

# Illustrative — exact paths/fields are confirmed during the build
POST /auth/session/refresh
  Cookie: ozb_sid=<session>
  -> 200 { "access_token": "...", "expires_in": 900 }

GET /business/v1/accounts
  Authorization: Bearer <access_token>
  -> [ { "account_id":"40802...", "kind":"current", "balance":"148230.55", "ccy":"RUB" },
       { "account_id":"40802...", "kind":"daily_income", "balance":"500000.00", "ccy":"RUB" } ]

GET /business/v1/accounts/{account_id}/operations?from=2026-05-01&to=2026-05-31&cursor=...
  Authorization: Bearer <access_token>
  -> { "items":[
        { "op_id":"...", "amount":"-12500.00", "dir":"debit",
          "type":"sbp_transfer", "sbp_ref":"A1B2...", "counterparty":"OOO Romashka",
          "ts":"2026-05-14T08:21:03+03:00", "purpose":"Оплата по счёту 114" } ],
      "next_cursor":"..." }

# Handle token expiry (expires_in ~900s) with a single refresh-and-retry,
# and treat HTTP 429 as a backoff signal, not a failure.

What lands on your side

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI 3 spec covering accounts, operations, SBP/QR events and the 1C document exchange as a single contract.
• A protocol and auth-flow report: the session/cookie chain and bearer-token refresh for the app route, or the document-signing and polling flow for 1C:DirectBank.
• Runnable source for the core calls in Python and Node.js — session bootstrap, paged statement pull, SBP event extraction, account list.
• A normalized transaction schema so SBP, internal transfers and 1C payments arrive in one shape.
• Automated tests against recorded fixtures, plus a small replay harness so a front-end change is caught before it reaches production.
• Interface documentation and data-retention guidance written for a Russian business-account context.

Routes in, and the one we lean on

1C:DirectBank exchange

Ozon Bank documents a 1C:DirectBank integration for business clients. It exchanges signed payment orders and statement requests over a channel meant for software, so it is the most durable source where the account is enabled for it. We arrange enablement with you during onboarding and build the connector and its document mapping.

Consented app-traffic integration

With the account holder's authorization, we analyze the app's own HTTPS traffic and reimplement the account, statement and SBP calls as a clean client. This reaches everything a user sees, including the Daily Income accruals, and is the fallback when 1C:DirectBank is not in play.

Native artifacts as a top-up

Ordered certificates and exported statement files cover documents that neither channel needs to synthesize. We fold them in where they save effort.

The practical pick is straightforward: lead with 1C:DirectBank when the account supports it, because a signed-document channel ages well; otherwise the consented app route carries the same schema. We say which applies after one look at the account's enabled features.

Consent and the Russian rulebook

Ozon Bank operates under Bank of Russia oversight, and personal data here falls under Federal Law No. 152-FZ. Access rests on the account holder's explicit authorization — a consenting business account or the client's own 1C:DirectBank enablement — scoped to the data domains the project needs and nothing wider. We keep consent records, log every pull, minimize stored fields to what the use case requires, and work under NDA where the engagement calls for it. The Bank of Russia has published Open API standards that are advisory today, with a stated intent to make them mandatory for major banks from 2026; we design the schema so it can ride a standardized open API surface later without a rewrite, but the dependable basis right now is the account holder's consent, not a future obligation.

Build notes specific to this app

• The Daily Income account credits interest daily, so the operations feed carries a steady stream of small accrual entries. We tag and roll those up separately so they do not drown out real business movements in a reconciliation view.
• SBP settlements post 24/7 — Ozon Bank runs in-bank transfers around the clock. We design the sync to poll on a schedule that catches same-day SBP events rather than assuming a nightly batch window.
• Session tokens on the app route are short-lived (about 15 minutes in observed behaviour); we wrap calls in a refresh-and-retry so a long statement page does not die mid-pull.
• Individual entrepreneurs and legal entities see different document sets and limits. We scope the connector per entity type so an ИП account and an LLC account are each handled correctly.
• When the mobile front end changes, the app route can shift. The replay harness re-validates captured flows on a schedule so drift is caught and patched before it surfaces downstream.

Cost and the delivery cycle

Source-code delivery starts at $300, and you pay it only after the integration is in your hands and working to your satisfaction — runnable code, the spec, tests and docs for the surfaces above. If you would rather not run anything, the alternative is our hosted endpoints: you call them and pay per call, with no upfront fee. Most builds of this size land inside a one-to-two-week cycle. Tell us the app and what you need from its data, and we handle the access and compliance side with you — start at /contact.html.

Interface evidence

Screenshots from the Play listing, used to map the surfaces above. Click to enlarge.

How this was checked

Mapped on 2026-06-07 against the app's Play listing, Ozon Bank's business help and 1C:DirectBank documentation, the NSPK Faster Payments participant registry, and the Bank of Russia's open API announcements. Sources opened:

• Ozon Bank — 1C:DirectBank integration docs
• Ozon Bank business help — business account
• NSPK — Ozon Bank as an SBP participant
• Bank of Russia — Open API standards update

OpenBanking Studio integration desk · mapping reviewed June 2026.

Comparable apps in the same space

Other Russian business-banking apps a unified integration would sit alongside; named for ecosystem context, not ranking.

• Tinkoff Business (T-Bank) — accounts, statements and acquiring for entrepreneurs, with its own developer-facing exchange.
• Tochka — entrepreneur-focused bank with rich account automation and document flows.
• Modulbank — SME accounts bundled with accounting, payroll and lending data.
• SberBusiness — Sberbank's corporate channel covering accounts, payments and statements at scale.
• Alfa-Bank Business — corporate accounts and payment operations for legal entities.
• VTB Business — current accounts, transfers and statement data for companies.
• Delo Bank — small-business accounts with online operations and reporting.
• YooMoney for Business — payment acceptance and settlement records oriented to online sellers.

Questions integrators ask about this one

Can the 1C:DirectBank channel be used as the data source instead of scraping the app?

Often, yes. Ozon Bank publishes a 1C:DirectBank integration for business clients, which exchanges signed payment documents and statement requests over a documented channel. Where your account is enabled for it, we build against that rather than the mobile front end, because it is more stable and already designed for machine exchange.

How do you capture SBP and QR payment events for an Ozon Bank business account?

Ozon Bank is a registered participant in the Bank of Russia Faster Payments System (SBP) per the NSPK participant registry. Incoming SBP and QR settlements surface in the account statement and operations feed. We model those as a normalized transaction event with the SBP reference, amount, counterparty and timestamp, so a back office can reconcile them as they post.

Does the Daily Income savings account expose its accrued interest separately?

The app describes daily interest accrual on any balance for the Daily Income Account. In the statement surface that appears as periodic credit operations against the savings account. We map the account list, the daily accrual entries and the linked current account so the balance and the earned interest can be tracked as distinct fields.

What does Russia's open API timeline mean for this integration today?

The Bank of Russia has published Open API standards that are advisory today, with a stated plan to oblige major banks to use them from 2026. We treat the account holder's own authorization as the dependable basis now, and design the schema so it can switch onto a standardized open API surface later without reworking the consumer.