Operating a Partner's real deployment

The reference topology is deployed in a GCP project controlled by the Partner and uses:

• GKE Autopilot;
• highly available Cloud SQL PostgreSQL;
• Pub/Sub;
• Cloud Tasks and Scheduler;
• Secret Manager;
• Artifact Registry;
• Cloud Storage;
• Cloud Logging, Monitoring and Trace.

The Control Plane, the Data Plane and the Partner's signing service stay within its environment.

It allows running long-running APIs, workers and observers with independent scaling without directly managing nodes.

It also keeps a reasonable path to other managed Kubernetes offerings. GCP is the first supported topology, but the functional architecture does not depend on Belo or on a single Partner.

The self-hosted profile is designed to operate autonomously within the Partner's environment.

charts are Helm charts: declarative packages that describe how to deploy and configure services on Kubernetes. ChatterPay publishes container images and Helm charts as versioned, signed OCI artifacts identified by digest in an authorized registry. Contracts, manifests, infrastructure modules, SBOM and runbooks accompany the same versioned release.

The Partner's CI/CD or GitOps pipeline authenticates against that registry, verifies the signature and digest, and copies the approved artifacts to its own Artifact Registry. From there it applies its configuration and deploys the Helm chart on its GKE cluster, first in staging and then in the real environment the Partner approves. The delivery mechanism is an automatable flow between registries and pipelines; the release does not depend on manually exchanging a ZIP file.

An outage of ChatterPay's corporate services must not stop authentication, operations, signing, observation or reconciliation for the Partner's deployment.

Enablement happens through a capability manifest.

The manifest identifies an exact combination of:

• deployment;
• environment;
• network;
• asset;
• capability;
• execution mode;
• fee policy;
• contracts;
• signing provider;
• RPCs;
• external providers;
• limits;
• test evidence.

A capability goes through sandbox, conformance testing, staging and canary before becoming active. A canary is an initial, bounded real enablement for selected accounts, with low limits and reinforced observation; depending on its results, the rollout is expanded, paused or reverted.

The architecture uses differentiated targets.

As an initial reference:

• B2B API, workers and webhooks: 99.9%;
• observers and Control Plane: 99.5%;
• sandbox: best effort.

RPO (Recovery Point Objective) is the maximum acceptable data loss, measured as the time between the last recoverable state and an interruption. RTO (Recovery Time Objective) is the target time to restore service after that interruption.

Critical transactional state has a target regional RPO of up to five minutes and an initial regional RTO of up to eight hours, subject to real restoration and disaster-recovery testing.

Blockchain or provider timings are measured separately from the platform's own availability.

The platform separates:

• technical observability;
• the operation's durable timeline;
• audit of administrative and financial actions.

OpenTelemetry correlates the API, messages, workers, providers and webhooks. PostgreSQL keeps each operation's history and an append-only audit trail.

Logs are structured and redacted. They do not contain keys, tokens, KYC files or secrets.

ChatterPay publishes immutable, signed bundles with images, contracts, manifests, SBOM, test results and migration plans.

The Partner imports those artifacts into its own registry, verifies signatures and digests, tests them in staging, and approves the promotion.

The real environment uses the same tested artifact, identified by digest. A new ChatterPay release does not get enabled automatically.