Filament Flow Laravel Package

Product Decisions This Supports

• Build vs. buy for Flow.cl (Chile) payments: the package covers the full one-off payment loop — credentials management, HMAC-SHA256 signing of the s parameter, create / createEmail / getStatus / refund, and a hosted checkout redirect view — so the default decision shifts from "build a gateway wrapper" to "buy and integrate," roughly days instead of weeks of engineering.
• Payments roadmap scoping: supports a Chile launch with one-time charges, refunds from the admin panel, and status polling. It explicitly does not cover subscriptions/plans, marketplace/split payouts, invoicing, or multi-currency — those remain separate roadmap items with separate build/buy calls.
• PCI and compliance posture: the url?token= hosted redirect keeps card data out of our systems, which lowers PCI scope and security review burden — a product-level constraint worth codifying in the architecture decision record.
• Support operations: refunds exposed through a Filament settings/gateway surface let CS handle reversals in-app rather than via the Flow dashboard, which affects tooling and permissions design.
• Market/GTM readiness: ES/EN translations align with a Chilean customer base served by a possibly English-speaking internal team; no localization work needed for launch.
• Platform baseline decision: pins us to Filament 4.x/5.x and Laravel 11–13, so adoption is coupled to an upgrade decision — relevant if we are still on Filament 3 or Laravel 10.

When to Consider This Package

Adopt when all of the following hold:

• Customers pay in CLP through Flow.cl and a hosted checkout redirect is acceptable.
• The app is on Laravel 11–13 with Filament 4.x/5.x, and the admin panel is the natural home for gateway credentials.
• The payment surface is one-off charges plus refunds plus status checks — enough for checkout, order confirmation, and CS-initiated reversals.
• You want credentials and signing handled by maintained code rather than env vars and hand-rolled HMAC logic.
• You are comfortable at v1.0.0 maturity and can absorb the integration risk of a young, single-purpose package.

Look elsewhere (or plan to build the missing pieces) when:

• You need webhook/callback confirmation — the release notes list only getStatus, so production reconciliation likely requires either polling you build yourself or a confirmation endpoint outside this package.
• You need subscriptions, recurring billing, payment links, invoices, or Flow's marketplace/payout APIs.
• You need multi-gateway abstraction (Flow + Stripe + Transbank behind one interface) — an Omnipay-style or custom adapter layer is a better fit.
• You are outside Chile, or still on Filament 3 / Laravel ≤10.
• You need partial refunds, settlement/reconciliation reporting, idempotency guarantees, or audit logging for financial operations — verify these before committing.
• You require vendor SLA, security disclosure process, or a proven maintenance track record; at 1.0.0 that history does not yet exist.

Mitigation for the unknowns: wrap FlowGateway behind your own internal payment interface so webhooks, idempotency, and logging can be added without rewriting call sites, and confirm sandbox/test-mode support before sprint planning.

How to Pitch It (Stakeholders)

For executives: This is a small, focused integration that gets us accepting payments in Chile faster and keeps card data out of our systems entirely — customers pay on Flow's hosted page, so our compliance and PCI exposure stays minimal. There is no license cost, and the work is measured in days rather than weeks. The trade-off is maturity: it is a brand-new 1.0.0 release, so we should treat it as a starting point and insulate ourselves from it architecturally.

For engineering: It removes the tedious, error-prone parts — HMAC-SHA256 signing of Flow's s parameter, credential storage and a settings UI in Filament, the redirect view, and typed gateway methods for create, create-email, status, and refund. It targets Laravel 11–13 and Filament 4/5, so check our upgrade position first. Gaps to own ourselves: webhook/callback handling, idempotency, and audit logging for refunds. Wrap the gateway in our own interface and we can add those — or swap vendors — without touching product code.