Demo: real third-party capture (Plaid flow, sealed keys, S3, env wiring)

[kenahrens]

Problem

For the Speedscale mock demo, the banking services need to make real outbound calls to third parties so we can capture genuine responses and build responder mocks. As-is, services used dummy keys and the Plaid call fabricated an invalid token (access-sandbox-<accountNumber>) so it always returned 400 INVALID_ACCESS_TOKEN. Third-party credentials also weren't managed for GitOps.

Solution

• accounts-service — real Plaid sandbox flow. fetchPlaidBalance now acquires a real token via POST /sandbox/public_token/create (ins_109508, initial_products:["transactions"]) → POST /item/public_token/exchange (cached), then /accounts/balance/get. Returns a real 200 with live balance data.
• Drop fake hardcoded AWS creds from the accounts base deployment; statement export now reads creds from a secret.
• Wire all 6 services' third-party credentials from a banking-thirdparty-keys SealedSecret via per-service overlay env patches (transactions uses Spring PAYMENT_* relaxed-binding names; ai-service re-pointed off the mock ai-api-key).

⚠️ Demo/minikube-specific — NOT for merging to master as-is

• banking-thirdparty-keys-sealed.yaml is sealed to the local minikube sealed-secrets controller; decoy clusters can't decrypt it.
• kustomization.yaml pins accounts-service:demo-plaid, a locally-built image.

The genuinely upstreamable changes are the Plaid flow fix and the fake-AWS-cred removal; the sealed secret + image override are how this branch deploys on minikube via ArgoCD.

Verification

• Plaid: Plaid balance response: status=200 in logs; proxymock shows sandbox.plaid.com 200 (was 400). 12 accounts returned ("Plaid Checking", …).
• S3: app wrote statements/account-*.json to the real bucket.
• Captured as real 2xx: OXR, Stripe (201), PayPal (201), Plaid (200), SendGrid, Twilio, S3, Slack.

🤖 Generated with Claude Code