Ponto Connect Laravel Sdk Laravel Package

Product Decisions This Supports

• Production go/no-go for bank connectivity. Ponto Connect (Isabel Group) requires live requests to be signed with a signature certificate in addition to mTLS transport certificates. Until v1.1.0 the SDK covered the sandbox happy path; the signing capability is the last hard prerequisite before a live launch. This release moves the package from "demo-grade" to "plausibly production-grade" and directly supports a build-on-SDK vs. build-in-house decision.
• Feature scoping and roadmap sequencing. Payment initiation (PIS) is effectively blocked in production without request signing; account information (AIS) and balance/transaction sync are constrained the same way. Any roadmap item that says "initiate payments" or "sync live accounts" now becomes schedulable rather than parked.
• Build vs. buy on the crypto layer. HTTP Signature canonicalization plus certificate handling is exactly the kind of work product teams under-estimate and get subtly wrong. Buying it inside the SDK removes a high-risk, low-differentiation workstream and replaces it with certificate provisioning plus configuration.
• Time-to-market re-estimation. Live-mode integration effort drops from "unknown, weeks of signature work, needs a crypto-literate engineer" to "obtain eIDAS certificates, wire config, validate against sandbox." That is a material change to launch-date confidence and to the cost-per-market estimate for European expansion.
• Compliance and security review evidence. A concrete, reviewable answer to "how are live requests signed?" for internal architecture review, DPO sign-off and partner/bank due diligence.
• Use cases unlocked: live account aggregation for treasury/cash-visibility dashboards, automated reconciliation feeds, and payment initiation for payout/collection flows — all gated on this release.

Explicitly not solved by this package (keep on our backlog): eIDAS certificate procurement and renewal (QWAC for transport, QSEALC for signing), private-key storage and rotation, nonce/replay and clock-skew handling, and signature failure observability. Those are ops/security deliverables we still own.

When to Consider This Package

Adopt when:

• We are a Laravel/PHP shop and Ponto Connect is the chosen (or a candidate) open-banking provider — this is a thin, Laravel-native wrapper, and the alternative is raw HTTP + hand-rolled signing.
• We need AIS and/or PIS in the Belgian/European market and are prepared to hold our own eIDAS certificates and PSD2 licence or licensed-partner arrangement.
• We want to validate the integration in Ponto's sandbox now and treat live signing as a config change later.
• The team accepts a small-vendor dependency for a bounded, well-isolated integration surface.

Look elsewhere when:

• We need a multi-provider abstraction (Tink, GoCardless, TrueLayer) rather than a single-provider binding — prefer an internal adapter interface regardless.
• We need broad ASPSP coverage, enterprise SLAs, or contractual support; this is a community package (single maintainer, v1.1.0, first external contributor in this release) with no support commitment.
• We need webhook/eventing-heavy flows, or PSD2-grade compliance guarantees the vendor, not the library, must provide.
• We are not on Laravel, or we need a package with a long production track record.

Adoption guardrails: pin the exact version, review the signing PR before trusting it with live credentials, run the full flow against the Ponto sandbox with signature verification enabled, and keep our own thin port/adapter so swapping providers stays a contained change.

How to Pitch It (Stakeholders)

For executives (one paragraph): The SDK we are evaluating for European bank connectivity just shipped live request signing — the final technical gate between a sandbox prototype and a production launch. That converts a previously unbounded "crypto integration" risk into a routine certificate-provisioning and configuration task, and it unblocks payment initiation and live account sync on the roadmap. Cost is low and the dependency is replaceable; the residual risk is vendor maturity (a young, small-maintainer package) plus our own certificate lifecycle obligations. Recommendation: proceed to a time-boxed sandbox integration, contingent on engineering review of the signing implementation and a documented certificate-management plan.

For engineering: Review the signing PR for canonicalization correctness and header coverage; load keys from a secrets manager, never from the repo; add integration tests against the Ponto sandbox with signing active; handle signature-rejection responses explicitly (401/403 paths) with actionable errors; confirm nonce/replay and clock-skew behaviour; ensure certificates and signatures never hit logs. Report back on test coverage in the signing path — it is the deciding factor for production trust.

Ask: time-boxed spike, a documented certificate lifecycle owner, and a decision checkpoint on whether to keep this package or wrap it behind our own provider interface.