Fintech Core is multi-tenant: each business is an isolated tenant identified by its API key. A business only ever sees and acts on its own data.

​
Businesses

A business has a name, a status (ACTIVE / DISABLED), and one or more named API keys, each stored only as a SHA-256 hash. Disabling a business immediately rejects all of its keys. Several keys per business is deliberate: it is what makes revocation usable. Killing a compromised “staging” key should not take “production app” down with it, and a key nobody can identify is a key nobody dares revoke — hence the name on each one. Revoking stamps a timestamp rather than deleting the row. Which key was live when a request was made is exactly what an incident asks, and the key prefix is what resolves a request-log line to the business that made it.

​
Scoping

The API key on a request resolves to exactly one business, whichever of that business’s keys was presented. Resources created through the API — payments, webhook endpoints — are tagged with that business’s id, and every read is filtered by it. Requesting another business’s resource returns 404, not the data.

​
Management

  • Admin provisions businesses (POST /api/v1/businesses) and can manage any business by id (PATCH /api/v1/businesses/{id}).
  • Businesses self-manage through /api/v1/me (view, rename, rotate their keys) — see Managing businesses.
  • Admins issue and revoke individual keys from the dashboard (POST /api/v1/admin/api-keys, POST /api/v1/admin/api-keys/{id}/revoke). Both are written to the audit trail inside the transaction that makes the change.
Satim merchant credentials are currently shared at the platform level, not per business — Fintech Core abstracts them away so businesses never handle them directly.