TransactKit-Pro security and deployment

Implemented protections

• Stripe-hosted Checkout and Customer Portal keep raw card data out of the application.
• The configuration API returns only secret-presence booleans.
• Webhook signatures are verified over the unchanged raw body before persistence.
• Unique event claims deduplicate terminal delivery while preserving retryable failures.
• Checkout recovery requires local UUID metadata and matching business reference.
• Portal return and Checkout success/cancel URLs come from server configuration.
• H2 console access is disabled and Stripe failures map to controlled Problem Details.

Authentication and authorization remain with the host

All application endpoints are reachable unless the integrating application or deployment boundary protects them. A valid Stripe ID is not proof of ownership.

• Authenticate callers and authorize every Customer, Checkout, Payment, Refund, Subscription, Portal, Invoice, Entitlement, and Usage operation.
• Bind local UUIDs, Stripe IDs, business references, and Meter Event identities to the authenticated account or tenant.
• Keep the webhook endpoint reachable by Stripe while relying on signature verification, not network location alone.

Production requirements

• Use persistent MySQL, least-privilege credentials, encrypted backups, and tested restores.
• Use HTTPS, deployment-managed Stripe secrets, and separate test/live environments.
• Monitor webhook failures, Stripe authentication and rate-limit errors, database health, and graceful shutdown.
• Restrict logs so they never contain secrets, signature headers, raw webhook bodies, or sensitive payment fields.
• Block or omit /api-test/** and protect Actuator endpoints.
• Validate every used Stripe workflow in a sandbox and production-like environment before launch.

Security and reliability limits

• No authentication, authorization, tenant model, rate limiter, audit log, or application permissions are included.
• Hosted Stripe surfaces reduce direct card-data handling but do not guarantee PCI compliance for the complete product or deployment.
• Customer creation, Portal Session creation, and subscription mutations have no application idempotency key.
• There is no durable queue, global reconciliation endpoint, distributed lock, or event-ordering engine.
• The host decides how subscription and Entitlement state grants access.