How Syper Works

The Syper model: accounts operate, products provide capabilities, integrations connect.

DraftDescribes the intended design. Not yet available — names, fields and behaviour may change.

Syper separates three questions. Keeping them separate is what lets the same payment capability work for a person on a phone, a business back office, and an autonomous robot.

Who? — Accounts: The party that owns and operates the financial relationship: a person, a business, or an agent acting on someone's behalf.
What? — Products: The financial capability being used: payments, cards, treasury, credit, investments, savings, identity.
Where and how? — Integrations: The channel the request arrives through: an app, an AI agent, a robot, a POS terminal, USSD, NFC, a financial rail.

One request, three layers

A robot paying a charging station illustrates the model:

Account — the robot operates an Agent Account owned by a business, with a spending limit.
Product — the charge is a Payment.
Integration — the robot reaches Syper over NFC at the terminal and receives confirmation via a Webhook on the operator’s backend.

Change any one layer and the others stay the same: a person paying the same station by QR uses a Personal Account and the same payment product.

Cross-cutting rules

Every request, regardless of layer, is subject to the same platform rules:

It is authenticated with credentials bound to an environment.
It is authorized against the permissions of the credential and the account.
Writes are idempotent and failures return structured errors.