Shared return_url validation for PaymentIntent and SetupIntent confirmation.
Stripe refuses to confirm an intent whose enabled payment methods include
redirect-based ones (boleto, iDEAL, ...) unless the caller supplied a
return_url to send the customer back to. Accepting that confirmation would
let an integration ship a call that cannot succeed against the real API, with
a green suite the whole way.
What is and is not decided here
Only the case that is decidable from the request: automatic_payment_methods
present with enabled truthy and allow_redirects not "never". Stripe
defaults allow_redirects to "always", so an enabled block that omits it
requires the URL.
When automatic_payment_methods is absent entirely, Stripe falls back to the
payment methods enabled in the account's dashboard — state PaperTiger does not
model — so that case is deliberately allowed through rather than guessed at.
Summary
Functions
The operator-facing message. Stripe's own message names the specific resource,
so the caller passes "PaymentIntent" or "SetupIntent".
Returns :ok, or {:error, :return_url_required} when redirects are allowed
and neither the stored intent nor the confirm params carry a return_url.
Functions
The operator-facing message. Stripe's own message names the specific resource,
so the caller passes "PaymentIntent" or "SetupIntent".
Returns :ok, or {:error, :return_url_required} when redirects are allowed
and neither the stored intent nor the confirm params carry a return_url.
intent is the stored object; params are the confirm request's params, since
Stripe accepts return_url at either create or confirm time.