Integrations
Works with your point of sale.
ProxyPay does not replace the system you already ring sales on. A connector is the piece that links it to your register flow.
What this means for your store
Your point-of-sale system keeps doing what it does today: ringing items, tracking inventory, closing out the till. A connector sits beside it and links it to the ProxyPay payment request that the register issues and the customer's wallet verifies. Nothing about your existing system is replaced.
A connector is written against a contract that is published and typed, with a test kit that checks it. That means a connector either passes those checks or it does not — there is no partial credit, and no connector goes live on the strength of a demo alone.
Every connector states what it can and cannot do from a fixed, closed list of capabilities, so you can see exactly what a given connector supports before you rely on it for a location.
The honest answer on "does it work with my system"
A connector is written against a published, typed contract and checked with a conformance test kit, so it either passes or it does not. We are not able to say a particular system is already supported, and we do not keep a count of integrations to quote.
For the person doing the integration
A connector is defined the same way for any external system: a closed list of capabilities it can be asked to perform, and a set of evidence kinds that back a "supported" claim for one of them. Declaring a capability "supported" without carrying the evidence for it is rejected before anything depends on it, and leaving a capability out entirely is a thrown error rather than a silent gap.
A connector also carries a plain self-description: what kind of external system it is, which provider it speaks for, and whether it is a deterministic fixture or an observation of a real system. A fixture connector cannot also claim to be telling the truth about a real provider — that is enforced, not left to a comment.
A connector is checked against a framework-free conformance kit before anything is built on top of it: does its self-description hold up, are its declared capabilities exactly the closed list (no more, no fewer), is every "supported" claim backed by evidence, and does it refuse an operation it has declared unsupported rather than quietly doing nothing. The reference connector in the register software today is a deterministic fixture, built and checked the same way a real one would be.
Capability examples, not a vendor list
A point-of-sale connector’s capability list covers things like reading what happened at the register and writing back that a tender completed. The list is closed and published so a reader never has to guess whether a capability was simply forgotten from a connector’s declaration.
The open payment request format any connector ultimately routes a sale through is published at /protocol. The rest of the API surface is covered on the for developers page.