Platform
Webhooks, events and fraud
What the platform can tell you without being asked, and what it cannot yet.
This page describes a subject the platform has an answer for and this portal cannot yet state. What is written below is the shape of the answer, not a commitment about this installation.
- Whether an outbound webhook mechanism exists at all, or whether every integration polls.
- The topic names, payload schemas and ordering guarantees for the event feed.
- When the dispute integration service will be published, since fraud lives inside it.
- Whether fraud decisions are exposed to a bank in real time or only in reporting.
Everything documented on this portal is a request you make. This page is about the other direction — the platform telling you something happened — and most of it does not exist yet.
Webhooks
No outbound webhook is published. Nothing in the seven specifications registers a callback URL, and no operation describes a delivery retry, a signature or a replay window.
That means every integration built against this platform today is a polling integration. If your design assumes a callback when a card is issued, a limit is breached or a dispute changes state, that assumption needs revisiting before build starts, not during it.
If webhooks arrive, these are the things to agree before they do, because they are the ones that are expensive to retrofit:
| Question | Why it decides the design |
|---|---|
| Signing | Without it, a receiver cannot tell your platform from anyone who learned the URL |
| Retry and backoff | Determines whether your endpoint must be idempotent, which it will be |
| Ordering | Whether "card blocked" can arrive before "card issued" |
| Replay window | Whether a receiver that was down for an hour can recover, or has to reconcile |
Events
The platform's services consume events over Kafka, RabbitMQ, NATS or HTTP polling, through one interface with the transport chosen by configuration. That is internal plumbing, and it is documented on the monitoring page.
What is not published is the topic catalogue: which events a bank could subscribe to, under what names, carrying what. Listing plausible topic names here would hand you a subscription contract that nothing upholds, so this page names the absence instead.
Until then, the reconciliation path is the substitute. The end-of-day guide describes the position everything settles to, and reconciling against it is how an integration currently discovers what happened while it was not looking.
Fraud
Nine fraud operations exist. All nine are inside the dispute integration service, and that service is not published — its own documentation describes a different API entirely, so none of its 115 operations is reachable from this portal.
What is in there:
- Mastercard FDA fraud states and issuer fraud lists
- Fraud record creation against a transaction
- The Visa and Mastercom dispute families the fraud flow feeds into
Publishing it is a documentation problem rather than an engineering one. The endpoints work; what is missing is a document that describes them, so nothing on this portal can honestly tell you what to send.
For a UAE launch there is a second question behind the first. Fifteen of the dispute operations are BKM HIYS — the Turkish interbank dispute scheme — and they have no Jaywan equivalent yet. The Visa and Mastercom families carry over unchanged; the domestic scheme path does not.