PayOps

Research & Development

Your PSPs. One payment integration.

PayOps is being built to bring your existing payment providers behind one API, helping simplify integration, payment operations and recovery.

PayOps integration hub connecting a merchant application with payment providers

01 / The problem

Multiple providers bring multiple integration challenges.

Each provider has its own APIs, payment states, errors and webhook behavior. Managing these differences can add development, maintenance and operational work.

01

Different APIs

01

Different APIs

02

Fragmented payment operations

02

Fragmented payment operations

03

Uncertain payment outcomes

03

Uncertain payment outcomes

02 / How it works

One integration layer. Provider-specific connections.

Our design combines a unified merchant-facing API with dedicated provider connectors.

Merchant application

PayOps

Provider connectors

PSPs and acquirers

Provider A

Provider B

03 / Bring Your Own PSP

Keep your provider relationships.

You keep your existing PSP and acquiring contracts, provider accounts and settlement relationships. PayOps is designed to coordinate those connections through a common integration layer.

PayOps does not hold merchant funds.

Keys, contracts and provider accounts

04 / Development goals

What we are building.

Development goal

Unified payment lifecycle

A common API design for payment creation, status, capture, refund and void.

Development goal

Unified payment lifecycle

A common API design for payment creation, status, capture, refund and void.

Development goal

Controlled provider selection

Selection based on account eligibility, supported capabilities and configured rules.

Development goal

Controlled provider selection

Selection based on account eligibility, supported capabilities and configured rules.

Development goal

Payment outcome recovery

Checking uncertain outcomes before deciding whether a new attempt is safe.

Development goal

Payment outcome recovery

Checking uncertain outcomes before deciding whether a new attempt is safe.

Development goal

Reliable merchant events

Durable webhook delivery and recovery after interruptions.

Development goal

Reliable merchant events

Durable webhook delivery and recovery after interruptions.

A magnifying glass and hourglass illustrating payment outcome verification

05 / Reliability

When the outcome is unclear, verify first.

A timeout does not always mean a payment failed. Our recovery approach prioritizes confirming the provider outcome before retrying or switching providers, helping avoid duplicate payment execution.

Timeout

Provider inquiry

Decision based on outcome

06 / Who it is for

Built with payment and engineering teams in mind.

For teams maintaining multiple provider connections, investigating payment outcomes and managing payment operations across different systems.

07 / Provider approach

Dedicated connectors. A common merchant interface.

Initial technical research covers Nexi XPay and Redsys. Provider-specific behavior belongs in the connector layer, while the merchant interface is designed to remain consistent.

08 / Research & Development

Currently in research and development.

Technical analysis and architecture work are shaping PayOps. Implementation and provider testing are the next stages of development.

Working with multiple payment providers?

We’d like to hear about your integration and payment operations challenges.

PayOps

Research & Development