We are building our own payment gateway. Merchants integrate via our API to accept payments and execute payouts across a dozen regions – cards, mobile money, UPI, Interac, local bank transfers. Fourteen provider integrations are live and new ones are added every month. The product is young but real: money moves through it daily, and much of the roadmap ahead is still undefined, reconciliation, chargebacks, merchant-facing analytics, new regions. Most decisions here are made upstream, not from a finished design: how money moves, what happens when a provider fails mid-transaction, who is allowed to see what.<\/p>\n
Requirements:
3+ years as a BA, Product Analyst or Product Owner in fintech, billing, e-commerce or another domain where money is counted and reconciled.
Ownership Mindset: You bring a recommended option with reasoning, flag what you assumed and what you traded away, and know which decisions are yours and which belong to someone else.
Requirements Writing: Specs with clear scope, acceptance criteria and explicit non-goals – not a list of wishes. User stories, use cases, process modelling.
API Literacy: Comfortable with OpenAPI specs, JSON payloads, REST semantics, webhooks and asynchronous callbacks. You don't write code, but you can reason about idempotency and state transitions.
Data Skills: SQL at a level that lets you check how a rule behaves on real data before writing it into a spec, and read your own metrics after release.
Async System Logic: Understanding that transaction states, retries and reconciliation must be specified rather than assumed.
Rapid Prototyping: Able to put together a clickable or visual prototype quickly – including with AI tools – to agree a flow with the business and hand a designer something concrete rather than a description.
Documentation Tooling: Confluence and Jira – specs, epic decomposition, decision log.
Language: English B1+ (provider documentation, specs and part of the backlog are in English).<\/p>\n
Responsibilities:
Product work
Own Features End to End: Take a business need – merchants can't withdraw their own balance, fees are opaque, a region needs a new provider – and drive it to release. Define the outcome, the scope, and what's explicitly out of scope for the first phase.
Scope to a Minimal Complete Scenario: Identify the smallest business flow that works end to end and delivers value – including its provider dependencies, finance dependencies, and the operational procedures that have to exist for it to run in production.
Close Questions, Escalate Risks: Propose a reasoned option rather than a list of alternatives. Document assumptions and trade-offs, resolve questions within agreed authority, and escalate material risks early rather than late.
Prioritise: Argue why this feature before that one, using actual data – transaction volumes, failure rates, support load, provider costs.
Work With Stakeholders: Translate between finance, business development and engineering. Each describes the same problem in a different language.<\/p>\n
Analysis work:
Model Money Flows: Specify holds, settlements, refunds, fees and ledger entries. Define what happens on cancel, reject, timeout and provider failure – which balance moves, when, and by how much.
Specify Reconciliation: Define how discrepancies are detected, investigated and corrected – what the system flags, what the operator sees, which adjustments are allowed and who may make them.
Write Specs That Hold Together: Complete rules, no internal contradictions, explicit non-goals. A spec is done when an engineer can build from it without guessing and a tester can verify against it without asking.
Decompose Epics Into a Critical Path: Split a feature into backend, frontend and admin work, mark blocking dependencies, flag external blockers before the team starts.
Define Access and Permissions: Specify role-based access, tenant isolation, and exactly what each actor sees and can do – merchant, finance operator, admin.
Work With Provider Documentation: Read integration docs from payment providers and turn them into requirements the team can build against.<\/p>\n
Will be a plus::
PSP & Acquiring Background: 3DS protocols, chargebacks, settlement reconciliation, provider cascades, routing rules.
Greenfield Experience: Building a product area from scratch, where the process doesn't exist yet and has to be designed alongside the feature.
Regulatory Awareness: PCI DSS, AML, sanctions screening – understanding why certain data can't be logged or exported.
Competitive Analysis: Benchmarking a product against market players and turning gaps into a roadmap.<\/p>\n","protected":false},"excerpt":{"rendered":"
We are building our own payment gateway. Merchants integrate via…<\/p>\n","protected":false},"author":13678,"featured_media":0,"parent":0,"comment_status":"open","ping_status":"closed","template":"","meta":{"_mo_disable_npp":"","rwu_salary_min":0,"rwu_salary_max":0,"rwu_salary_currency":"","rwu_salary_period":"","rwu_english_level":"B1","rwu_experience_months":36,"rwu_candidate_countries":"\u0412\u0435\u0441\u044c \u0441\u0432\u0456\u0442","rwu_company_type":"\u041f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0456\u044f","rwu_industry":"fintech","rwu_part_time":false,"rwu_source_views":105,"rwu_source_applications":29,"rwu_source_category":"Business Analyst","rwu_source_name":"Djinni.co","rwu_source_url":"https:\/\/djinni.co\/jobs\/853902-business-analyst-associate-product-manager\/"},"job_category":[62],"job_type":[54],"class_list":["post-4096113","job","type-job","status-publish","hentry","job_category-kerivnitstvo-ta-menedzhment","job_type-povna-zainiatist"],"yoast_head":"\n