Integrations

A card programme is never only a card programme. This page covers the two kinds of connection banks ask about: third-party services that sit beside the card, and machine consumers that read the platform on a developer's behalf.

What exists in the platform today

Before the patterns, the state. Three things are visible in the published specifications:

• saveCardBnplPermission — a per-card permission flag for buy-now-pay-later. It is a switch, not an integration: it says a card may be used with BNPL, and nothing on this platform talks to a provider.
• executeCampaignTransaction and the campaign query operations — a small internal campaign engine, three operations in total.
• Instalments — 23 operations. In the Turkish market this is the BNPL product, modelled as taksit. It is native, mature, and it is the thing to look at before integrating an external provider.

Everything below describes how an integration would work, not one that is running.

Buy now, pay later

Two shapes, and the choice determines who holds the credit risk.

Provider-funded. Tabby, Tamara or Klarna underwrite the instalment plan. The card authorises normally; the provider settles with the merchant and collects from the cardholder. The platform's role is small — the BNPL permission flag decides whether the card is eligible, and the transaction arrives as an ordinary authorisation.

Issuer-funded. The bank underwrites, and the plan lives on the card. This is what the instalments capability already does: split a purchase or a cash advance across a schedule, track it, settle it early or cancel it. No external provider is involved and no integration is needed.

For a UAE launch the second is the shorter path, because it exists. The first needs a provider agreement, a settlement flow and a dispute path that the instalments operations do not cover — a chargeback against a provider-funded plan is not a chargeback against a card transaction.

Loyalty

The platform carries reward types, earned points and campaign periods on transactions, and a small campaign engine. That is enough to record loyalty and not enough to run a programme.

Two integration shapes:

• Federated — the bank's existing loyalty platform owns the programme. The card platform emits transactions; the loyalty platform decides what they earn. This needs an event feed, which is the open question on the monitoring page.
• Native — campaigns are configured in the platform's own engine. Three operations, suited to simple period-based campaigns rather than to a tiered programme with partner redemption.

How to integrate anything else

The pattern is the same whatever the system, and it is worth stating once:

1. Authenticate as a client, not as a user. Client credentials, one client per integration per environment, so a compromised credential is revocable without taking down the others.
2. Call synchronously, reconcile asynchronously. Every mutation returns a reference. Store it. Reconciliation against the end-of-day position is what catches the calls that succeeded on one side and not the other, and the end of day guide covers the position it reconciles to.
3. Never retry a mutation blind. There is no idempotency key on these operations. Retrying a limit increase applies it twice. Reverse with the returned reference and issue a new call instead.
4. Fail closed on the card. If your service cannot answer, the safe default is to decline rather than to authorise — for a card platform, availability is not worth more than correctness.

Exposing the platform to AI agents

Integration teams increasingly read documentation through a chat application or an editor rather than a browser, and their agents call APIs directly. Two surfaces exist for that, and they are deliberately different.

Read the documentation. Every public page on this portal has a markdown twin at the same address with .md appended, and /llms.txt indexes them. That is enough for a chat application to answer a question about the platform accurately, with a citation, and without scraping rendered HTML.

Reach the model. The MCP service exposes the compiled catalogue as tools — search operations, read one, list a capability, look up a term, fetch a specification. It is hosted, so there is nothing to install: an agent in Claude Code, Claude Desktop, Cursor or VS Code is pointed at a URL and can use it while writing your integration.

Two boundaries hold on both surfaces, and neither is negotiable:

• The MCP service is read-only about documentation, and sandbox-only about anything else. The same frozen set of one environment that governs the portal's own try-it panel governs it. An agent cannot be pointed at production, whatever it is asked to do.
• Gated pages stay gated on the web. A chat application fetching a .md twin gets what a signed-out reader gets. Field tables, validations, error codes and test data need an approved session, and there is no URL that hands them out without one.

The MCP service is a different thing and it is worth being precise about it: it is a hosted endpoint with no login, and it serves the public catalogue — the same thing this site publishes to everyone, and the same thing the tools page hands out as files. It is not subject to the web gate because there is nothing behind it that the gate protects. What approval unlocks is the gated detail and the sandbox, and the server has neither.