Release: v1.0.1-alpha-37

process-webhook threw an :internal-error for any Stripe event whose type is not one of the four generic payment_intent.* mappings — including checkout.session.completed (the primary paid-flow event), checkout.session.expired, and charge.dispute.created. In the billing webhook handler that throw is uncaught and returns HTTP 500, so a freshly-connected Stripe endpoint 500s on every delivery Stripe fires by default, and Stripe then retries for days.

process-webhook now returns a result with :event-type nil and the full payload for any unmapped-but-parseable event instead of throwing, so the handler acknowledges with 200 and the billing layer routes or ignores by payload type. Only the four payment_intent.* types still resolve to a framework event-type (BOU-147).

create-checkout-session POSTed whatever stripe-checkout-params produced. A broken upstream return-URL config (e.g. an unset PUBLIC_BASE_URL) reached Stripe two ways: an empty string when the :redirect-url fallback was also blank (400 parameter_invalid_empty, BOU-148), or a scheme-less relative path like /web/license/payment/return?… when the configured URL was left relative (400 url_invalid, BOU-149).

The adapter now validates the resolved success_url/cancel_url before the Stripe call: anything that is not an absolute http(s) URL throws a :config-error ex-info naming the offending param, its value, and the fix (provide an absolute return URL / set PUBLIC_BASE_URL in acc/prod). The misconfiguration is now actionable instead of surfacing as an opaque provider error.

All libraries bumped to v1.0.1-alpha-37 to maintain lockstep versioning — boundary-payments is realigned from its standalone alpha-36 release back onto the suite version.

Re-run the installer to pick up the latest release:

No migration required. Backward compatible.