Portmone: utility, transfers — OpenData mapping & authorized payment-rail integration

Recurring utilities & Single Account ingestion

Screens that locate bills by address or contract bundle gas, water, light, sewage, and heating into one payment event. Field notes describe how meter periods, arrears flags, and rounding rules appear so data engineers can normalize them against municipal tariff tables.

Concrete use: property operators automate accrual postings per apartment block instead of reconciling PDF scans from each utility portal.

Card-to-card and QR transfer APIs (authorized flows)

We document sender PAN token references, recipient phone bindings, currency assumptions in UAH, and status transitions that resemble payment initiation reporting under Ukraine’s evolving Open Banking regulation—always paired with explicit user consent artifacts.

Concrete use: payroll teams validate that per diem pushes match shift schedules by comparing QR batch IDs with HRIS exports.

Merchant H2H JSON notification mirror

Official partner documentation specifies HTTPS host-to-host traffic, XML or JSON callbacks to a merchant-provided URL, and separate 3-D Secure endpoints. We draft listener stubs that validate signatures, idempotency keys, and failure codes so finance controllers see the same state machine the gateway emits.

Concrete use: SaaS billing teams reconcile hosted checkout sessions with internal invoice rows without polling end users.

Transport ticketing & entertainment catalog feeds

Kyiv ground and metro tickets, cinema, theater, concerts, and games each carry distinct merchant descriptors. Mapping those descriptors to ISO merchant categories prevents double counting when loyalty analysts join Portmone files with bank-issued card data.

Concrete use: city mobility studies compare Smart Card reload cadence against ride-hailing spend in the same household.

Insurance, education, and trade-network payments

Auxiliary services—insurance premiums, school fees, retail chain invoices—often include policy numbers or student identifiers in memo fields. Extraction playbooks show how to lift those tokens for CRM deduplication while redacting national ID fragments.

Concrete use: edtech finance teams prove tuition was paid on time for scholarship audits.

“Last operations” history as an operational data store

Because the product markets a running ledger of recent actions, analysts can treat it as an append-only feed analogous to account-information services, noting timestamps, channel icons, and reversal markers when disputes occur.

Concrete use: fraud desks replay short windows around suspicious login attempts without exporting an entire year of unrelated cinema tickets.

Finance-grade lineage

Each integration blueprint names the originating screen (utilities hub, transfers tab, Smart Card module), the identifier set (contract, phone, smart-card number), and the settlement rail (card network vs internal wallet balance). That lineage shortens SOC 2 evidence collection because auditors can trace a metric to a user-visible confirmation.

Dual-track delivery

Teams that already signed Portmone merchant agreements receive hardened webhook parsers and key rotation runbooks, while authorized aggregators focused on household visibility receive field dictionaries aligned with Ukrainian Open Banking consent language published by the National Bank of Ukraine.

Operational clarity

Instead of ad-hoc screenshots, engineers inherit OpenAPI sketches, fixture JSON, and negative tests for throttling, partial payments, and duplicate notifications—cutting mean time to detect integration drift after app updates.

Vendor-neutral storage

Normalized tables separate PII (phone, address lookups) from payment facts (amount, currency, merchant category), which keeps data minimization policies intact when the same warehouse also stores Privat24 or monobank exports.

Scenario A — Multi-unit housing statements

Business context: A Kyiv facility manager pays utilities for forty flats and must prove each transfer to owners’ associations.

Data involved: Contract numbers, meter periods, UAH amounts, timestamps from the utilities grid, plus optional address lookup keys.

OpenData mapping: Rows resemble account-information service extracts because each payment references a stable provider + personal account tuple, letting you join external tariff APIs published as open data by regulators.

Scenario B — Field staff per diem via phone transfers

Business context: Logistics supervisors push UAH advances to drivers’ phones between bank cutoffs.

Data involved: Phone-based card routes, QR fallback codes, reversal flags inside last operations.

OpenFinance mapping: Treat the feed like a lightweight payment initiation log—each entry stores an intent (push), execution channel, and settlement state comparable to PISP confirmation payloads under NBU Open Banking guidance.

Scenario C — Merchant SaaS with Portmone checkout

Business context: An ISV already on the partner program wants deterministic mirrors of asynchronous approvals.

Data involved: JSON notifications, bill identifiers, error codes from host-to-host docs, 3DS challenge results.

OpenData mapping: Webhooks become the system of record that data lakes ingest hourly, while CRM retains only non-sensitive order metadata.

Scenario D — Municipal mobility stipends

Business context: Employers subsidize Kyiv Smart Card reloads for night-shift nurses.

Data involved: Smart-card numbers, number of trips purchased, purchase timestamps, card template used for funding.

OpenData mapping: Join trip bundles with HR roster IDs (hashed) to prove eligibility without exposing full card PANs.

Scenario E — Micro-business fiscal calendar

Business context: Accountants consolidate budget payments for private entrepreneurs across Portmone and bank portals.

Data involved: Payment purpose codes, SSC receipts, military duty lines, single tax confirmations.

OpenFinance mapping: Align memo fields with chart-of-account dimensions mandated by Ukrainian tax reporting, then cross-check against official treasury confirmation numbers when those APIs are available.

Snippet 1 — Merchant notification listener (pseudocode)

// Pseudocode: verify Portmone-style async JSON callback
POST /hooks/portmone/payment
Content-Type: application/json
X-Signature: sha256=<HMAC_OF_RAW_BODY>

{
  "shopOrderNumber": "INV-204918",
  "billId": "pm-88321",
  "status": "ACCEPTED",
  "authCode": "493021",
  "amount": "1250.00",
  "currency": "UAH",
  "errorCode": "0"
}

// Handler steps:
// 1) Load merchant secret from KMS (never from git)
// 2) Recompute HMAC on raw bytes; constant-time compare
// 3) Upsert payment_fact by billId with status + authCode
// 4) If duplicate billId with same status → 200 OK idempotent exit
// 5) On mismatch → 401 and alert SIEM channel

Snippet 2 — Authorized “last operations” pull (illustrative REST)

// Illustrative internal API after lawful aggregation
GET /internal/v1/portmone/operations?from=2026-03-01&to=2026-03-31&category=utilities
Authorization: Bearer <USER_CONSENT_TOKEN>

200 OK
{
  "items": [
    {
      "operation_id": "op_918273",
      "posted_at": "2026-03-12T09:41:11+02:00",
      "amount": "842.35",
      "currency": "UAH",
      "counterparty": "Kyivteploenergo",
      "contract": "001234567890",
      "channel": "mastercard_token",
      "status": "settled"
    }
  ],
  "next_cursor": "eyJpIjoxMjB9"
}

Snippet 3 — Session refresh with step-up handling

// Pseudocode: refresh user-authorized session
POST /auth/portmone/refresh
{
  "refresh_token": "prt_***",
  "device_binding": "fp_sha256:ab12...",
  "mfa_hint": "sms_last4:4821"
}

403 MFA_REQUIRED
{ "challenge_id": "ch_991", "methods": ["otp_sms","push"] }

// Client completes OTP, then:
POST /auth/portmone/mfa
{ "challenge_id": "ch_991", "otp": "482193" }

200 OK
{ "access_token": "...", "expires_in": 900 }

Ukraine regulatory stack

The Law of Ukraine on Payment Services and National Bank of Ukraine implementing acts govern payment service providers, strong customer authentication, cybersecurity expectations for payment-market participants, and the national Open Banking framework that defines how banks and third parties exchange account data with consent.

Portmone publicly cites PCI DSS audit coverage for its consumer-facing security story; merchant integrations additionally require TLS 1.2, encrypted cardholder data via client-side encryption helpers, and tightly scoped credentials issued after contractual onboarding.

Cross-border privacy overlays

Teams storing Ukrainian household data inside EU analytics tenants must still honor GDPR articles on lawful basis, data minimization, and breach notification timelines even when the primary processor is Ukrainian.

Our deliverables include processing records that list lawful bases, retention windows for phone-derived transfer indexes, and pseudonymization recipes before data crosses regions.

Privat24

PrivatBank’s super-app stores card-to-IBAN transfers, international rails, and utility templates. Teams that split bills between Portmone and Privat24 often need unified Ukrainian Open Banking consent flows so accountants can deduplicate the same electricity contract paid from two wallets.

PUMB Online Bank 24/7

First Ukrainian Bank’s mobile stack bundles transfers, Western Union family rails, and cashback programs. Its data model complements Portmone when enterprises standardize on PUMB corporate cards but employees still use Portmone for municipal school meals.

monobank

The unicorn-style digital bank issues virtual cards quickly and pushes scheduled utilities. Analysts comparing monobank’s retail momentum with Portmone’s biller catalog frequently request cross-wallet spend classification so marketing teams avoid double-counting telecom refills.

EasyPay

EasyPay’s instant internet payments include card top-ups for other brands. Merchants studying interchange-minimization strategies evaluate how EasyPay receipts align with Portmone host-to-host JSON for the same acquiring chain.

Sense SuperApp

Sense blends banking, utilities, and lifestyle perks such as Mastercard-driven gamification. Households that experiment with Sense’s fee-free utilities still keep Portmone for niche billers, which makes multi-app statement stitching a recurring integration ask.

Raiffeisen Online

Raiffeisen Bank Ukraine’s online channels emphasize FX, deposits, and Apple Pay-ready cards. Treasury groups pair Raiffeisen liquidity with Portmone’s faster phone transfers when field teams lack IBAN details.

Oschad 24/7

Oschadbank’s mobile footprint reaches state-sector salary cards and social payouts. Public-sector contractors sometimes pay suppliers via Portmone while salaries land on Oschad cards, driving demand for joined-up audit trails.

NovaPay

Nova Poshta’s payment layer handles logistics-linked settlements. E-commerce sellers reconciling COD remittances alongside Portmone checkout sessions want consistent merchant descriptors across both apps.

What we deliver

• OpenAPI sketches for merchant listeners and internal aggregation services.
• Protocol and authorization flow reports with sequence diagrams for OTP, push, and device-binding steps.
• Runnable Python or Node.js samples for webhook verification, cursor pagination, and error taxonomies.
• Automated pytest / Jest suites with replayable JSON fixtures.
• Operator documentation describing how to request Portmone transaction history API integration scopes from business stakeholders lawfully.

About our studio

We are an engineering-led studio that pairs mobile app interface analysis with authorized API work across fintech and retail. Practitioners on the team have shipped PCI-scoped gateways, PSD2-style consent UX in EU, and Ukraine-specific payment projects where NBU regulations intersect with everyday wallet behavior.

We document reverse-engineered flows only where customers supply contracts proving legitimacy, preferring official host-to-host JSON channels whenever Portmone already exposes them to partners.

Contact

Share the target app name (Portmone: utility, transfers), desired datasets, and evidence of user or merchant authorization. We respond with a scoped statement of work and sample milestones.

Open the contact page

Engagement workflow

1. Discovery call covering utilities, transfers, transport, merchant checkout, and compliance boundaries.
2. Interface documentation sprint with daily diffs against docs.portmone.com.ua releases.
3. Implementation sprint for collectors, transformers, and webhook hardening.
4. Validation window with shadow traffic on sanitized fixtures.
5. Handover of runbooks, DPIA annexes, and operator training for Ukrainian Open Banking consent capture.

FAQ

Do you replace Portmone’s official partner onboarding?

Can you scrape data without user consent?

How do you stay current?