# `PaperTiger.ReturnUrlHelper`
[🔗](https://github.com/neilberkman/paper_tiger/blob/v1.5.1/lib/paper_tiger/return_url_helper.ex#L1)

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.

# `error_message`

```elixir
@spec error_message(String.t()) :: String.t()
```

The operator-facing message. Stripe's own message names the specific resource,
so the caller passes `"PaymentIntent"` or `"SetupIntent"`.

# `validate`

```elixir
@spec validate(map(), map()) :: :ok | {:error, :return_url_required}
```

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.

---

*Consult [api-reference.md](api-reference.md) for complete listing*