Laravel SISP 0.6.4 makes payment states explicit

Payments do not break only when the gateway goes down.

They break when a transaction sits pending too long, when a retry can be called without a signature, when the sum of the items does not match the total, when an invoice groups lines the wrong way, or when the published package points to a file that does not exist.

That is what I treated as Laravel SISP 0.6.4.

Technically, there was a 0.6.3 the day before. In practice, 0.6.3 and 0.6.4 belong to the same move: clean the package’s operational floor so a Laravel application can integrate SISP with fewer surprises in production.

First, take noise out of the package

0.6.3 fixed things that look small until they block someone.

The package had misaligned Node metadata and pointed at a missing entrypoint. That does not change the payment flow, but it changes the trust of anyone who installs, audits, or automates the package. A wrong package manifest is a broken promise in miniature.

I also fixed the serialized fingerprint in the callback and stabilized the generation of merchant identifiers. Those two live on the floor of the integration. Nobody buys the package because they exist. But when they fail, everything above them becomes suspect.

That was the first part of the release: remove noise so the package’s real behavior is easier to trust.

Then, protect the money

0.6.4 tightened rules at the points where too much tolerance turns into a financial bug.

The package now validates the payment item totals before going further. If the sum of the items does not close against the expected amount, that should surface early. The invoice, the reconciliation, and customer support all depend on this detail.

Refunds also became more explicit: the package requires full-amount reversals. That avoids a half-supported, half-imagined state where the application thinks it did one thing while the gateway may be representing another.

Retries now require signed requests. Routes that change state got configurable middleware. That is the kind of change that should not become a pretty headline, but should exist in any package that touches money.

The core point: pending is not final

The most important feature of 0.6.4 is the reconciliation of pending payments.

In SISP, as in any real gateway, the final answer does not always arrive the moment the application wants it. The callback can be late. The response can come in incomplete. The transaction can exist while not yet being ready to be treated as success or failure.

Before, this kind of intermediate state was easy to leave as an operational problem. Now the package has a documented status query and a reconciliation path for pending payments.

That shifts the posture of the integration. Instead of pretending every payment ends on the first round-trip, the package assumes intermediate states exist and need to become explicit decisions.

The counterargument

Yes, this looks like a small release.

There is no flashy new API. There is no new frontend. There is no new flow to sell in the README.

But that is the point. A payment integration does not gain maturity just by adding surface. It gains maturity when it removes ambiguity from the places where production tends to send the bill: callbacks, retries, totals, invoices, refunds, and pending states.

Laravel SISP 0.6.4 is that kind of release.

Less promise. More contract.

In payments, the best release turns ambiguous states into explicit decisions.