AstraPay: Financial Services Platform on Infrastream

End-to-End Architecture & Deployment Guide

1. Executive Summary

Field	Detail
Project	AstraPay Global
Client	FinCorp Global (Tier-1 Investment Bank)
Partner	Stellar Technologies
Platform	Infrastream
Objective	Deploy a cloud-native, high-throughput payment processing platform compliant with PCI DSS and GDPR. The system must feature real-time fraud detection using AI, an immutable event store for auditing, and a secure merchant dashboard.
Compute	Cloud Run (Microservices), Compute Engine (Kurrent DB Cluster)
Data	AlloyDB (Ledger), Kurrent DB (Event Sourcing), Cloud Storage (Reports)
Security	Identity-Aware Proxy (IAP), Multi-Factor Authentication (MFA), Secrets Manager
AI/ML	Gemini 3.0 Flash (Real-time Fraud Scoring)
Agentic	Native fraud-investigation Agent on Vertex AI Agent Engine, governed by Infrastream (least-privilege accessControl, managed identity)

---

2. Architecture Overview

This diagram illustrates the flow of a payment transaction and the relationship between Infrastream manifests and the deployed infrastructure.

---

3. The Project & Security Boundary

The project manifest defines the primary security boundary. Crucially, we enforce Strict Egress Controls at the project level, and centralize merchant/admin authentication through the IdentityProvider manifest (see Section 7).

Project Manifest

# FILE: ./astrapay-prod.yaml
apiVersion: lowops.manifests.v1
kind: Project
metadata:
  name: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  description: |
    Primary production environment for AstraPay Global.
    Handles high-throughput card processing and merchant settlements.
  region: us-central1
  # Google APIs (e.g., Gemini) are accessed via VPC-SC / Private Google Access
  # and do not need to be listed here. Only external endpoints require allowedEgress.
  allowedEgress:
    - api.stripe.com                    # Downstream processor
    - api.twilio.com                    # OTP Verification
  hibernation:
    hibernate: false # Financial systems run 24/7
  maintenance:
    start: 2025-02-15T02:00:00Z
    end: 2025-02-15T04:00:00Z

---

4. Data Layer (Stateful Resources)

AstraPay uses a dual-data strategy: AlloyDB for the transactional ledger (ACID) and Kurrent DB for the immutable audit trail (Event Sourcing).

Transactional Ledger (Database)

# FILE: ./database/ledger.yaml
apiVersion: lowops.manifests.v1
kind: Database
metadata:
  name: ledger
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  description: ACID-compliant ledger for processed transactions.
  alloydb:
    cpuCount: 4
    clusterSize: 2 # High-availability read replica
    configuration:
      maxConnections: 2000
    backupConfig:
      quantityBasedRetention: 30

Event Store (Virtual Machine Cluster)

# FILE: ./virtual-machine/event-store.yaml
apiVersion: lowops.manifests.v1
kind: VirtualMachine
metadata:
  name: event-store
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  description: 3-node HA cluster for immutable event sourcing.
  meshStrategy: SIDECAR
  stateful:
    enabled: true
    clusterSize: 3 # Quorum consistency
    allowTcp:
      - 1113 # gRPC API
      - 1112 # Internal Gossiping
    health:
      port: 2113
      protocol: tcp
      checkIntervalSec: 60
  ports:
    2113: http2 # UI and gRPC
  configuration:
    source: kurrent-db
    volumeMounts:
      /mnt/data:
        diskConfig:
          sizeGb: 500
          type: pd-ssd
        mountOptions: [rw, noatime, compress=zstd:1]
  machineType: n2-standard-4

---

5. Storage & Compliance

Security and long-term retention are handled via encrypted buckets and secret management.

Compliance Reports (Bucket)

# FILE: ./bucket/compliance-reports.yaml
apiVersion: lowops.manifests.v1
kind: Bucket
metadata:
  name: compliance-reports
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  storageClass: ARCHIVE
  public: false
  description: Secure bucket for MiFID II and PCI audit logs.
  processors:
    obscenityScanner: true # Scan merchant-uploaded assets

Encryption Keys (Secret)

# FILE: ./secret/pii-key.yaml
apiVersion: lowops.manifests.v1
kind: Secret
metadata:
  name: pii-key
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  description: Primary AES-256 key for field-level encryption.

---

6. Microservices (Deployment Configs)

Services are optimized for gRPC and integrated with Gemini AI for real-time risk analysis.

Payment Gateway (Command Service)

# FILE: ./deployment-config/payment-auth.yaml
apiVersion: lowops.manifests.v1
kind: DeploymentConfig
metadata:
  name: payment-auth
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  version: "1.0.0"
  description: Processes authorizations and writes events to Kurrent DB.
  container:
    env:
      - name: APP_CONFIG
        value: |
          {
            "eventstore": { "url": "kurrentdb+discover://event-store.payments.production.acme-corp.internal:2113?tls=true" },
            "auth": { "mode": "OIDC", "issuer": "https://api.astrapay.com/idp" }
          }
  health:
    liveness:
      port: 8080
      protocol: http2
      path: /healthz
  scaling:
    min: 4
  ports:
    8080: http2

AI Fraud Engine (Gemini 3.0 Flash)

# FILE: ./deployment-config/fraud-engine.yaml
apiVersion: lowops.manifests.v1
kind: DeploymentConfig
metadata:
  name: fraud-engine
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  version: "1.0.0"
  description: Real-time fraud scoring using Gemini 3.0 Flash.
  container:
    env:
      - name: APP_CONFIG
        value: |
          {
            "genai": {
              "projectId": "astrapay-prod-x7y8z9",
              "location": "us-central1",
              "model": "gemini-3.0-flash",
              "risk_threshold": 0.85
            }
          }
  health:
    liveness:
      port: 8080
      protocol: http
      path: /healthz
  scaling:
    min: 2

Merchant Portal (Web UI)

# FILE: ./deployment-config/merchant-portal.yaml
apiVersion: lowops.manifests.v1
kind: DeploymentConfig
metadata:
  name: merchant-portal
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  version: "1.0.0"
  description: Flutter-based merchant dashboard with dynamic configuration.
  health:
    liveness:
      port: 8080
      protocol: http
      path: /
  volumes:
    /usr/share/nginx/html/config:
      files:
        app_config.json:
          content: '{"title": "AstraPay Portal", "features": ["risk-scores"]}'
  ports:
    8080: http

---

7. Native Agentic — Fraud Investigation Agent

AstraPay is natively agentic. The fraud-engine above handles real-time scoring on the transaction hot path; a governed AI Agent handles the deeper investigation work — correlating the ledger, event store, and compliance reports into a case file and recommending disposition. It runs on Vertex AI Agent Engine and is governed by Infrastream exactly like every other resource: its capabilities are declared in a typed manifest, reviewed in a PR, and enforced by the engine. See The Agentic Development Platform and Agentic Governance.

Note: The agentic layer is early and under active development (ADK-only runtime; re-test per environment before production). Treat this section as a reference pattern.

Agent Manifest

# FILE: ./agent/fraud-investigator.yaml
apiVersion: lowops.manifests.v1
kind: Agent
metadata:
  name: fraud-investigator
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  description: >
    Investigates flagged transactions end-to-end: correlates ledger
    records with compliance history to build a case file and recommend
    disposition. Real-time scoring stays on the fraud-engine hot path.
  target: AGENT_ENGINE
  project: astrapay-prod
  buildDefinition: fraud-investigator-build   # BuildDefinition (type: AGENT) that packages this agent
  accessControl:
    database:
      secretSource:
        envVar: DATABASE_LEDGER_CONNECTION_STRING
      schema: astrapay-prod
      name: ledger
      privileges: [SELECT]        # Read-only — least privilege
    secrets:
      case-management-api-key:
        envVar: CASE_MGMT_API_KEY

Every permission the agent holds is visible in this diff. It has read-only access to the ledger and cannot decrypt raw PII (the pii-key is deliberately not granted), cannot write to the ledger, and cannot reach any egress endpoint outside the project's allowedEgress. Beyond what is declared here, the engine automatically provisions the agent's runtime identity — scoped IAM grants and proactively refreshed tokens — so no team hand-rolls credential plumbing. When the agent must act as a specific risk officer (e.g. to file a case in an external system on their behalf), it uses 3-legged consent scoped to that one action rather than a shared credential.

Note: buildDefinition references a BuildDefinition (type: AGENT) manifest, not shown here — see TradeStream's Native Agentic section for a worked example and its current limitations.

Agent Deployment Config

# FILE: ./agent/fraud-investigator-deployment.yaml
apiVersion: lowops.manifests.v1
kind: AgentDeploymentConfig
metadata:
  name: fraud-investigator
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  version: "1.0.0"

---

8. Load Balancing & Authentication (IAP)

Public Ingress (Gateway)

# FILE: ./public-ingress/merchant-gateway.yaml
apiVersion: lowops.manifests.v1
kind: PublicIngress
metadata:
  name: merchant-gateway
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  domain:
    name: api.astrapay.com
  iapPermissions:
    groups: [risk-officers, platform-engineers]  # References OrganizationUserGroup manifest names

Identity Provider (SSO)

# FILE: ./public-ingress/merchant-idp.yaml
apiVersion: lowops.manifests.v1
kind: IdentityProvider
metadata:
  name: merchant-idp
  public-ingress: merchant-gateway
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
spec:
  displayName: "AstraPay Merchant Login"
  logoUrl: "img/astrapay-logo.svg"
  mode: REDIRECT
  providers:
    google: true
    microsoft: true
    password: true

HTTP Route

Declaring the PublicIngress and IdentityProvider above provisions the login experience, but nothing is actually gated behind it until a route's own rule says so — this is the piece that puts merchant API traffic through IAP + the merchant-idp tenant:

# FILE: ./public-ingress/http-route/gateway-routes.yaml
apiVersion: lowops.manifests.v1
kind: HttpRoute
metadata:
  name: gateway-routes
  project: astrapay-prod
  environment: production
  organizational-unit: payments
  organization: acme-corp
  public-ingress: merchant-gateway
spec:
  description: Route for the merchant-facing payments API
  rules:
    - matches:
        - prefixMatch: /
      authentication:
        - type: IDENTITY_PROVIDER
          tenants:
            - merchant-idp
      action:
        destinations:
          - deploymentConfig: merchant-portal
            port: 8080

---

9. Recommended Organization

While the Infrastream Engine is path-agnostic and resolves resources using metadata, following a logical directory structure is a best practice for team collaboration and security auditing (e.g., for GitHub CODEOWNERS).

# Logical organization for the AstraPay manifests
payments/
└── production/
    └── project/astrapay-prod/
        ├── astrapay-prod.yaml
        ├── database/ledger.yaml
        ├── virtual-machine/event-store.yaml
...
        ├── bucket/compliance-reports.yaml
        ├── secret/pii-key.yaml
        ├── deployment-config/
        │   ├── payment-auth.yaml
        │   ├── fraud-engine.yaml
        │   └── merchant-portal.yaml
        ├── agent/
        │   ├── fraud-investigator.yaml
        │   └── fraud-investigator-deployment.yaml
        └── public-ingress/
            ├── merchant-gateway.yaml
            ├── merchant-idp.yaml
            └── http-route/gateway-routes.yaml

---

10. Business Value

Metric	Impact
Regulatory Readiness	PCI DSS and GDPR compliance via automated encryption and MFA.
Fraud Prevention	Real-time AI scoring reduces risk with Gemini 3.0 Flash.
Governed Agentic AI	Native fraud-investigation Agent with read-only, PII-restricted access — every permission declared and auditable.
Audit Fidelity	100% immutable event store ensures forensic-level traceability.
Operational Speed	Provisioning a complete FinTech stack in minutes, not months.
Cost Control	Granular billing and isolation for payment processing units.