Architecture designed to operate other people’s money.

A modular core over a common data model, explicit contracts outwards and towards the local adaptation layer, and controls that are part of the flow. What follows is how the platform is built.

Architecture

Integra is organized in modules that share a data model and an event bus. Each module exposes its API and its events; the local adaptation layer connects through defined contracts and does not touch the core.

Core	Common data model: customers, accounts, operations, transactions, files, reconciliation periods.
Modules	Domain services with their own API and event catalogue, over the same model.
Event bus	Every state change is published once and consumed by the interface, webhooks and adapters.
Integration points	Contracts towards the PSP’s adapters: submission, state query, statement import.
Interface	Web application for operations and administration over the same APIs.
Deployment	Separate test and production environments; configuration per environment.

APIs

REST over HTTPS with JSON. A consistent model across the platform.

Authentication	API keys per environment with scopes (read, write, admin). Rotation without downtime.
Idempotency	Idempotency-Key header on every write. Retrying never duplicates.
States	received → validated → processing → confirmed \| rejected \| returned. The same for operations and transactions.
Errors	Code, message and per-field detail. Validation errors before any resource moves.
Pagination	Cursor-based, with filters by date, state, customer and reference.
Versioning	Version in the path (/v1). Breaking changes only in new versions, with coexistence.

Create a payment operationIllustrative · request

POST /v1/operations
Authorization: Bearer sk_test_••••••••
Idempotency-Key: cust-7781-payroll-2026-09

{
  "customer_id": "cus_01J9K2",
  "type": "payout",
  "currency": "COP",
  "items": [
    { "beneficiary": { "id_type": "CC", "id": "1020304050" },
      "destination": { "rail": "psp-local:bank-transfer", "account": "4581••••••" },
      "amount": 1850000, "reference": "Servicios septiembre" }
  ],
  "workflow": "two-step-approval"
}

ResponseIllustrative · response

{
  "id": "op_01J9K3Q8X2",
  "state": "received",
  "workflow": { "name": "two-step-approval", "step": "validation" },
  "items": { "total": 1, "valid": 0, "rejected": 0 },
  "created_at": "2026-09-15T14:02:11-05:00"
}

Webhooks

Events signed with HMAC and timestamp, delivered with retries and logging. The PSP and its customers subscribe by event type.

Signature	X-Integra-Signature header with timestamp and HMAC over the body.
Delivery	Retries with backoff on non-2xx responses; every attempt is logged.
Order	Unique identifier and timestamp per event; consumers are designed idempotent.
Resend	From the interface or via API.

Event: transaction confirmedIllustrative · event

POST https://psp.example/webhooks/integra
X-Integra-Signature: t=1758037331,v1=6d1f…

{
  "id": "evt_01J9K5",
  "type": "transaction.confirmed",
  "data": {
    "transaction_id": "txn_01J9K4",
    "operation_id": "op_01J9K3Q8X2",
    "rail": "psp-local:bank-transfer",
    "rail_reference": "…",
    "amount": 1850000, "currency": "COP"
  }
}

Security

Encryption

TLS in transit; encryption at rest for credentials, account data and personal data.

Access

Role- and action-based permissions; segregation of duties; strong authentication in the interface.

Credentials

Scoped keys per environment and integration; rotation without downtime.

Integrity

Idempotency, per-record validation and signed events.

Audit

Immutable log of human and system actions with before and after.

Data

Beneficiary data processed only to execute the instruction that originated it.

Security

Scalability

The platform processes per event and per batch. Queues absorb peaks, per-record validation isolates errors and asynchronous processing keeps the API fast while execution proceeds.

Per-record validation: one rejection does not stop the batch.
Asynchronous processing: the API responds immediately; execution and confirmation arrive as events.
Cursor queries to reconcile large volumes without downloading everything.
Configurable limits and windows per customer, per rail and per environment.

Integration Framework

The point where the platform ends and the PSP’s local connectivity begins. Small, explicit contracts to submit instructions, query states and import statements; everything rail-specific lives in the PSP’s adapter.

See the integration framework

Observability

States queryable via interface and API for every operation, transaction, file and period.
Log of webhook deliveries and adapter calls, with visible retries.
Operational metrics: volumes, time per stage, rejections by cause, open differences.
Configurable threshold alerts (for example, rejections above the expected level on a rail).

We do not publish certifications, availability figures or volumes we cannot support with evidence. The parameters that apply to each PSP are defined in writing before production.

Build and operate your PSP on Integra.

Tell us what you operate today and which rails you need to connect. We will show you the platform on your case.

Request a demo See the architecture